← Blog
May 31, 2026 · 11 min

The agentic stack in 2026: one diagram, five layers, and the operator's mental model

We have spent a month writing one layer at a time. The reader who has been with us through the whole series has a deep picture of each protocol, each pattern, each discipline. The reader who shows up today and wants to know what the agentic stack actually looks like in mid-2026 has eighteen posts to wade through. This post is the synthesis we owed both of them. One diagram of the five layers as they actually compose in production, a sentence per layer on which question it answers, the canonical composition pattern that runs through every real agent system, where the cross-cutting concerns of evaluation and security sit, and the operator's mental model for navigating the whole thing.

The diagram

The five layers, bottom to top, the way they actually stack in any production agent system as of May 2026.

The agentic stack, mid-2026:

  ┌──────────────────────────────────────────────────────────────┐
  │  USER / PRINCIPAL / OPERATOR                                 │
  │  Real-world goal, real-world money, real-world consequences  │
  └────────────┬─────────────────────────────────────────────────┘
               │
  ┌────────────▼─────────────────────────────────────────────────┐
  │  AGENT (the LLM-powered process)                             │
  │  Decides, plans, dispatches, synthesises                     │
  └────────────┬─────────────────────────────────────────────────┘
               │
       ┌───────┴────────┬───────────────┬──────────────┐
       │                │               │              │
  ┌────▼────┐      ┌────▼────┐    ┌─────▼─────┐   ┌────▼────┐
  │   MCP   │      │   A2A   │    │    AP2    │   │ ERC-8004│
  │ tools / │      │ agent ↔ │    │ payment   │   │ identity│
  │  data   │      │ agent   │    │ author.   │   │ + rep.  │
  └────┬────┘      └────┬────┘    └─────┬─────┘   └────┬────┘
       │                │               │              │
       ▼                ▼               ▼              ▼
   GitHub, DB,    Other agents,    Card rails,    On-chain
   Notion,         marketplaces,    x402 / USDC,   registry
   Stripe,         delegated        bank rails    (Ethereum,
   filesystem      work flows                      Base, etc.)
       │                                              ▲
       │                                              │
       └──────────────────────────────────────────────┘
       (settlement of payment authorised via AP2 lands
        on x402 / card / bank, and the resulting validation
        receipt posts back to ERC-8004)

Five layers under the agent. Each one answers exactly one question. None of them overlap; none of them duplicate. The fact that you can fit them in a single ASCII diagram is the synthesis itself — eighteen months ago the same picture would have required a vendor matrix and a footnote about which integration adapter went where.

The one-sentence layer summary

Memorising the five layers means memorising which question each one answers. The format we have settled on internally:

MCP — "What tools does the agent have access to?" The vertical layer between the agent and any external capability — a database, a file system, an API, a SaaS service. Tools, resources, prompts on the server side; sampling, roots, elicitation on the client side. Stateless transport in the 2026-07-28 release. Covered in our MCP deep dive.

A2A — "Which other agents can the agent talk to, and how?" The horizontal layer between agents. Agent Cards at a well-known URL for discovery, eleven JSON-RPC methods, eight-state task lifecycle, three update mechanisms. Covered in our A2A walkthrough.

AP2 — "Did the human really authorise this purchase?" The authorization layer. Three signed Verifiable Credentials (Intent, Cart, Payment), four actors (User Agent, Merchant Agent, Credentials Provider, PSP), two flows (Human Present and Human Not Present). Covered in our AP2 post.

x402 — "How does the payment actually settle if it is crypto-native?" The settlement layer for stablecoin and on-chain payments. HTTP 402 revived, EIP-3009 / Permit2 / Solana SPL, facilitator-mediated. Covered in our x402 post.

ERC-8004 — "Who is this agent, and what is its track record?" The identity, reputation and validation layer. Three on-chain registries (Identity, Reputation, Validation). The registration file binds the agent's A2A endpoint, MCP server URL, x402 endpoint and wallets to a single chain-anchored identity. Covered in our ERC-8004 post.

The canonical composition pattern

The reason the diagram is worth memorising is that nearly every meaningful agent-to-agent interaction in production follows the same composition pattern. The pattern reads top to bottom through the layers, and every protocol gets used exactly once in its role.

Composition pattern, end to end:

  1. Agent A wants to hire an agent to do task X.
     │
  2. Agent A queries the ERC-8004 Identity Registry for
     candidates with skill X and minimum reputation score N.
     │
  3. For each candidate, Agent A fetches the
     /.well-known/agent-card.json (A2A Agent Card).
     │
  4. Agent A picks a candidate, sends an A2A SendMessage
     to the candidate's task endpoint.
     │
  5. Candidate responds with a Task in INPUT_REQUIRED state
     and an embedded AP2 Cart Mandate.
     │
  6. Agent A's principal (or its pre-authorised Intent Mandate)
     counter-signs the Cart Mandate.
     │
  7. The Credentials Provider signs the Payment Mandate;
     settlement goes via x402 on Base / Solana / Polygon
     (or via a card rail through a PSP).
     │
  8. Candidate transitions the Task to WORKING, does the work,
     transitions to COMPLETED with artifacts attached.
     │
  9. Agent A pulls the artifacts via A2A, posts a Validation
     Receipt back to ERC-8004 referencing the candidate's
     identity token. Reputation updates.

The whole flow uses every protocol exactly once, in the role each one was designed for. ERC-8004 for discovery and reputation update. A2A for the protocol-level conversation. AP2 for the authorization chain. x402 for settlement. MCP, throughout, for any tools the candidate's internal workflow needs (not shown in the flow because it is internal to the candidate's process).

If you understand this nine-step flow, you understand the agentic stack in 2026. Everything else is either a specialization (which model the candidate uses for which step) or a transverse concern (eval, observability, security) that wraps around the flow.

Where evaluation and security sit

The five protocol layers handle the operational mechanics. Two cross-cutting concerns wrap around every one of them.

Evaluation and observability sit transversally across all five protocols. The trace of an A2A call, the cost of an MCP tool invocation, the latency of an x402 settlement, the freshness of an AP2 mandate, the change in an ERC-8004 reputation score — all are observed signals the operator's dashboard surfaces. The post we published yesterday covers this; the short version is that every meaningful action across every layer is logged with W3C Trace Context propagation, and the operator's dashboard correlates them into one operational view.

Security and threat modelling also wrap every layer. Prompt injection threatens the agent's reasoning step regardless of which protocol it is consuming. Tool poisoning threatens the MCP layer. Mandate replay threatens AP2. Sybil attacks threaten ERC-8004's reputation graph. The threat-model post from two days ago lays out the eight live and four emerging attacks; the defences land at different layers depending on the attack class, but the threat model itself is a property of the whole stack, not any single protocol.

The transverse concerns:

   ┌─────────────────────────────────────────────────────┐
   │                EVALUATION + OBSERVABILITY           │
   │  (traces, cost, latency, drift on every layer)      │
   └─────────────────────────────────────────────────────┘
                          ▲
        ┌────────┬────────┼────────┬────────┐
        │        │        │        │        │
       MCP      A2A      AP2     x402   ERC-8004
        │        │        │        │        │
        └────────┴────────┼────────┴────────┘
                          ▼
   ┌─────────────────────────────────────────────────────┐
   │              SECURITY + THREAT MODEL                │
   │  (injection, poisoning, hijack, replay, Sybil)      │
   └─────────────────────────────────────────────────────┘

The operator's mental model

The mental model that lets an operator navigate the stack without getting lost in the protocol details is short:

Five layers, one diagram, one canonical flow. When something works, trace it through the diagram and you will find the layer that did the work. When something fails, trace it through the diagram and you will find the layer where the failure lives. The protocols are deliberately separated so that "which layer broke" is a question with a clear answer.

Each protocol owned by a neutral home. MCP under modelcontextprotocol.io with governance Working Groups. A2A under the Linux Foundation. AP2 under the FIDO Alliance. x402 under the Linux Foundation (since April 2026). ERC-8004 under the Ethereum Foundation. No single vendor owns the stack; no vendor's bankruptcy takes it down.

Composition is the value. Each protocol on its own is useful but limited. The stack is more than the sum of its parts because the composition pattern (the nine-step flow above) lets a counterparty who has never met your agent decide to transact with it in a single round trip. That round trip is the unit of agent commerce.

Evaluation and security are not layers; they are properties of the whole. They wrap the stack. An operator who skips them has a stack with no nervous system and no immune system.

Agent Builder is the control plane that operates the stack for you. Not a sixth protocol; not a replacement for the stack. The control plane that lets an operator configure agents that speak all five protocols, watch them through the transverse concerns, and not have to reinvent each composition pattern from scratch.

What is missing — the gaps to watch

The diagram is honest about what 2026 has settled. It is also honest about what 2026 has not yet settled. Three gaps worth tracking.

Semantic alignment across A2A. Two agents can complete an A2A conversation perfectly while disagreeing about what "delivered" or "approved" means. We flagged this in the A2A post; the field will need either a shared ontology layer or a per-domain semantic extension registry before agent commerce can scale across industries without per-pair bilateral term agreements.

Memory continuity across sessions. An agent that does great work in session N has no protocol-level way to bring that learning into session N+1 with the same counterparty. Graphiti, Mem0 and similar external memory stores fill the gap operationally; a protocol-level standard for portable agent memory has not landed. The work is happening in research; nothing is shipping in production yet.

Cross-chain mandate portability. An AP2 Cart Mandate signed for settlement on Base does not seamlessly convert to settlement on Solana if the counterparty's preferred rail differs. Cross-rail bridging at the AP2 layer is a v1.x discussion that has not yet produced an implementation.

None of these gaps is breaking the stack today. They are the things that will need to land in the next twelve to eighteen months for the stack to support the larger workloads operators will demand as the market grows.

How to use this diagram

Two practical uses.

Internal communication. When a teammate or a customer asks "what does the agentic stack look like," show them the diagram. The conversation that follows is the right conversation — about composition, about which layer owns what, about where their use case fits. The diagram is the artifact that ends the "is MCP a competitor to A2A" confusion in one minute.

Architecture review. When designing a new agent system, walk the canonical flow against the use case. Each step the use case skips is either a deliberate scope reduction (the agent does not need ERC-8004 because all counterparties are inside one organisation) or a missing piece (the agent has no way to take payments because AP2 was not implemented). The diagram is the checklist.

Closing

The agentic stack in mid-2026 is the first version of the agent-economy infrastructure that is legible enough to fit in one diagram and stable enough to build on with confidence. Each layer has a neutral home, a reference implementation, a working group, and a roadmap. The composition pattern is settled. The transverse concerns are well understood. The operator's mental model is short enough to memorise.

Eighteen months ago, none of this was true. Eighteen months from now, the gaps we flagged will probably have closed and a new set of higher-order patterns will be the thing to learn. For the next two quarters, this diagram is the map. Print it, hang it on the wall, refer to it when you design.

The next post in this series leaves the synthesis behind and goes back to the operator-facing concrete: ten niches where an individual operator can ship a real agent in a week, with TAM estimates, data requirements, and monetization patterns. The synthesis tells you what is possible; the niches list tells you what to do with it.