Five layers. What each one is, how it works, where IBM i sits in it, and what to do with that information.
The Silver Lake Series argues that IBM i operators hold a structural advantage at the orchestration layer of the agentic stack. This document is the technical foundation for that argument. It is a reference — not a narrative. Each layer has a definition, a mechanism, an IBM i relevance note, and a set of diagnostic questions. Read the Silver Lake installments for the story. Read this for the architecture underneath it.
The five layers build sequentially — each enables the next. Start with the overview to understand the full stack, then drill into the layers most relevant to where your organization is in its agentic journey. The IBM i tab in each layer section is where this document earns its keep.
Jump to any layer: Intelligence · Action · Governance · Orchestration · Economic
The agentic stack has five layers. They do not accrue value equally. The intelligence layer is commoditizing. The orchestration layer is where IBM i operators hold structural advantage. Everything else is either infrastructure or a consequence.
The intelligence layer is the large language model at the center of an agent deployment. It receives context, reasons through the problem, and generates structured output — whether that's a natural language response, a tool call, or a decision.
Three architectural innovations have resolved the constraints that bounded early monolithic LLMs and are driving rapid capability convergence across the market:
These methods are converging across labs and becoming commodities. The capability gap that justified premium model pricing is compressing toward zero. Claude, GPT-4o, Gemini, DeepSeek, Llama — switching costs are approaching zero.
A raw LLM is a completion engine — it takes input and generates output. An agent adds a loop. The model reasons about what to do, takes an action (usually a tool call), observes the result, and reasons again. This is the ReAct loop, which lives in Layer 2.
The intelligence layer's job is reasoning quality — understanding the task, selecting the right tool, interpreting results, handling errors. The quality of reasoning determines whether the agent can complete complex multi-step tasks without derailing.
For IBM i practitioners: the intelligence layer is the part of the system you have the least control over and the least competitive advantage in. This is a feature, not a bug. You don't need to build or fine-tune a model to extract value from agentic AI. You need the layers underneath it.
DB2 data is among the best RAG source material available in any enterprise. It is structured, complete, historically deep, and referentially consistent in ways that data warehouses and data lakes rarely achieve. The IBM i database is not a legacy data problem — it is a RAG asset waiting to be connected to an intelligence layer that can reason over it.
The IBM i operator's advantage at Layer 1 is not in the model — it's in the data the model can be given. RAG-augmented agents that can query DB2 in real time, retrieve relevant records, and reason over structured transactional data outperform the same model without that access.
The practical implication: before evaluating which LLM to use for a given IBM i agentic deployment, evaluate which DB2 tables contain the data the agent will need to reason over. The data architecture decision matters more than the model selection decision.
The action layer is where a model that reasons becomes a system that acts. Without it, an LLM is a sophisticated completion engine — it can describe what to do but cannot do it. The action layer gives the model tools it can call, actions it can take, and feedback that flows back into the next cycle.
Three components make the action layer reliable in production:
The action layer is standardizing rapidly. MCP is winning as the tool connectivity standard. A2A is emerging for agent coordination. Standardization here is good news for IBM i — it means IBM i data and programs exposed via MCP are immediately callable by any MCP-compatible agent, without custom integration work per model or per framework.
An MCP server exposes three types of capabilities: tools (functions the agent can call), resources (data the agent can read), and prompts (reusable instruction templates). A client — the AI agent — discovers available capabilities through a standard discovery protocol and calls them by name with structured parameters.
The agent harness — LangChain, LangGraph, or a custom implementation — manages the ReAct loop, routes tool calls to the appropriate MCP server, and handles retries, errors, and context management.
Mapepire is the MCP-compatible bridge to IBM i. It exposes DB2 queries and ILE service program calls as standard MCP tools. Once a DB2 table or RPG program is exposed via Mapepire, it is callable by any MCP-compatible agent — Claude, GPT-4o, or any open-weight model running locally.
Project Bob and Claude Code operate at the Layer 2 boundary — they read existing RPG and CL programs, document the business logic, identify which programs and data structures should be exposed as MCP tools, and in some cases generate the MCP tool definitions directly.
The combination of Mapepire (the runtime bridge) and Project Bob (the code comprehension and documentation layer) is what converts IBM i from a legacy system into an agentic-ready platform. Neither requires rewriting existing programs. Both work with what you already have.
Governance is a property of the architecture, not the model. Safety training shapes how a model behaves by default. It can be talked out of a preference. Code is harder to argue with.
The governance layer enforces what an agent is permitted to do, independent of the agent's own judgment. Four components compose a trustworthy governance runtime:
Governance is table stakes for enterprise deployment — necessary but not sufficient. It is the floor, not the moat. Every serious enterprise agent deployment will implement it. None will differentiate on it.
The primary attack vector for production AI agents is prompt injection: an attacker embeds malicious instructions inside content the agent reads — a document, an email, a web page — and the agent acts on them as if they were legitimate. In 2025, Microsoft 365 Copilot was exploited via crafted emails that triggered data exfiltration with no user interaction required.
The defense is not better safety training. The defense is deterministic governance enforced at the runtime layer. An agent that cannot access a resource regardless of what instructions it receives — because its permission list does not include that resource — cannot be tricked into accessing it through prompt injection. The attack surface is bounded by architecture, not by model behavior.
For IBM i deployments: the governance layer must be designed before agents are given write access to any production system. Read-only MCP tools can be deployed with lighter governance. Write access to DB2 tables, IFS files, or program execution requires explicit permission grants, pre-validation, and complete audit logging.
IBM i's object-level security, authority checking (*ALLOBJ restrictions, adopted authority, object-level *USE/*CHANGE/*ALL grants), and journal-based audit trail are Layer 3 infrastructure. These are deterministic controls that apply at the platform level, independent of the application — and independent of the agent. An agent running on IBM i cannot access an object the current user profile lacks authority to — regardless of what the agent was instructed to do.
The journal-based audit trail is particularly significant. Every DB2 write, every program call, every object access is journal-eligible and can be captured with timestamp, user profile, and full before/after record images. This is the audit logging that the governance runtime requires — and IBM i has had it for decades.
The work is surfacing these existing controls to the agentic layer — mapping IBM i user profiles and authority structures to the agent permission model, and ensuring journal capture is activated for every object the agent can reach. This is configuration work, not new infrastructure.
The orchestration layer is where the same model becomes either far more valuable or far more expensive depending on what's underneath it. It is the control plane: task routing, workflow sequencing, agent-to-agent coordination, error containment, human review insertion, and memory management.
More precisely: the orchestration layer is where domain knowledge gets encoded into agentic behavior. Where your data, your processes, and your business rules become structural. It cannot be replicated without the domain depth that underlies it — which is exactly why it resists commoditization.
The organizations that will extract durable value from agentic AI are not the ones with the newest models. They are the ones with the richest process architecture, the most reliable data, and the deepest domain knowledge encoded into orchestration logic. This is the IBM i operator's structural position.
The dominant orchestration pattern in production deployments is orchestrator-worker. A master agent receives a high-level task, decomposes it into subtasks, routes each subtask to a specialized worker agent (or tool call), collects and synthesizes results, and either completes the task or escalates to human review.
The human-in-loop insertion point is not a limitation — it is the crawl/walk/run discipline in architectural form. Start with human approval on every agent action. Remove approval gates incrementally as confidence and audit evidence accumulate. The orchestration layer controls which gates exist and when they open.
The IBM i operator's structural advantage is at this layer. RPG programs encode business rules — the conditions, exceptions, validation logic, and sequence dependencies that govern real business workflows. CL procedures encode process flow. DB2 trigger programs enforce data integrity rules at write time. Data queues manage asynchronous processing. IFS provides a persistent workspace for agent state.
None of this needs to be rebuilt. It needs to be connected. Project Bob surfaces and documents this existing logic. Mapepire makes it callable as MCP tools. The orchestration layer is not absent from IBM i environments — it's been running in production for decades. It just wasn't connected to an intelligence layer that could act on it.
The organizations building agentic infrastructure from scratch are spending months constructing what IBM i shops have had running in production for years. The process depth, the exception handling, the domain-specific validation logic — these are orchestration assets. The IBM i operator who recognizes this is structurally closer to a production agentic deployment than almost any peer starting from a greenfield stack.
The economic layer is where token cost, inference latency, per-outcome pricing, data sovereignty requirements, and failure costs intersect. It is a consequence layer — its efficiency is determined almost entirely by how well the four layers beneath it are built.
A well-scoped agent with clean orchestration logic, deterministic governance, and structured data surfaces costs a fraction of an ungoverned agent running against messy data with broad permissions and poor error handling. The economic layer does not have independent variables — it is the sum of all architectural decisions made in Layers 1 through 4.
The shift from per-seat to per-outcome pricing is the economic layer's defining structural change. Microsoft CEO Satya Nadella has stated the company is rethinking pricing entirely — no longer "per user" but "per agent." This shift changes the economic model for every organization deploying agentic AI.
Per-outcome pricing aligns cost with value creation — you pay when the agent produces a result, not for access to the capability. For IBM i operators, this creates a direct measurement opportunity: the agent's economic value is the outcome value minus the total cost (token + cleanup + latency + sovereignty) of producing it.
The implication: the metric that matters is not tokens consumed per agent run — it is outcomes produced per dollar spent. Poorly scoped agents that consume many tokens to produce unreliable results are economically worse than tightly scoped agents that consume fewer tokens and produce consistent, auditable results every time.
For organizations already running IBM i, the economic argument for keeping AI inference workloads on or adjacent to existing Power Systems infrastructure is significant. The same workload that requires substantial cloud compute spending often runs on Power hardware that is already capitalized. The marginal cost of adding agentic workloads to an existing Power Systems environment is substantially lower than the cost of running equivalent workloads on cloud inference.
PowerVS — IBM Power Virtual Server — extends this to a sovereign cloud model. Organizations that cannot send sensitive data to shared inference infrastructure can run models on PowerVS with data sovereignty guarantees. For regulated industries, the sovereignty premium is not optional — it is a compliance requirement. IBM i organizations already operating on Power have a direct path to sovereignty-compliant inference that x86-native organizations do not.
The data sovereignty argument also applies at the RAG layer. Organizations that keep their DB2 data on-platform and query it locally for RAG operations avoid the data egress and regulatory exposure that comes with sending sensitive records to third-party RAG services.
The action and orchestration layers are standardizing around a small set of open protocols. These are the ones IBM i practitioners need to understand.
The tools that connect IBM i infrastructure to the agentic stack. Each sits at a specific layer.