How the two-layer picture formed.

Late 2024 was a moment when three protocols looked plausibly competitive. Anthropic's Model Context Protocol had shipped the previous November. Google announced Agent-to-Agent (A2A) in April 2025 as a peer-level protocol for agents delegating to other agents. IBM's Agent Communication Protocol (ACP) arrived that same spring targeting local and edge deployments where a heavier remote-procedure model felt like overkill. Every vendor roadmap deck had a slide arguing three protocols would coexist because they addressed different scopes.

The interop problem deep-dive walks the design pressures that made three protocols look reasonable at the time. What actually happened is that two of them merged. In July 2025 IBM contributed ACP to the Linux Foundation, and by autumn its capabilities had been folded into the A2A specification as an "adjacent-agent" mode. The ACP and what happened essay is the post-mortem — the short version is that ACP's differentiator was a lighter transport for co-located agents, and A2A absorbed that use case by adding a stdio-adjacent binding rather than forcing every deployment through remote HTTP.

MCP took a different consolidation path. Rather than merging with A2A, it drew a bright line: MCP addresses how one agent's model calls a tool. It stayed narrow. The 2025-11-25 spec is the version that most 2026 hosts and servers target, and it froze the surface enough that ecosystem code stopped churning. By early 2026 the field talked about MCP and A2A the way it once talked about HTTP and TCP — different jobs, stacked, both required in a full deployment, neither trying to eat the other.

The current roadmap makes the split explicit. A Q3 2026 joint interop specification, co-authored by the MCP and A2A maintainer groups, defines how a task delegated over A2A can carry an MCP tool-manifest reference so the receiving agent uses the same tools with the same auth. That document is the strongest signal that the two-layer picture is not just descriptive — the maintainers plan to make the composition first-class.

MCP as the tool layer.

MCP's job in the two-layer picture is narrow and specific: an agent's model needs to invoke a tool, and MCP is the wire shape for that invocation. The MCP architecture deep-dive walks the JSON-RPC lifecycle, the client-server-host participant model, and the initialize handshake in detail. For the two-layer picture the important observation is that MCP's participants are asymmetric on purpose — the host runs a client, the tool runs a server, and there is no expectation that servers talk to other servers. That asymmetry is what makes MCP the "below" layer: it terminates at the leaves of the agent graph, where the actual work with the outside world happens.

The ecosystem shape reinforces this. The MCP registry and distribution essay documents the public registry that indexes thousands of small, single-purpose servers — filesystem, Postgres, Slack, Snowflake. The median server exposes a handful of tools and nothing else. That is what the "M" in the stack looks like in a real deployment: your host connects to eight or ten MCP servers, each doing one thing well, each probably written by someone other than your team. MCP is not a general-purpose messaging protocol pressed into the tool role; it is the tool role, made explicit.

A2A as the agent layer.

A2A's job is delegation between peers. Where MCP models a model reaching for a tool, A2A models an agent reaching for another agent — one that has its own reasoning loop, its own tool layer, its own opinions about how to accomplish a task. The A2A v1 deep-dive walks the specification in detail; the shape of the protocol matters for the two-layer picture in three specific ways.

First, a task has a lifecycle. A2A tasks move through nine states — submitted, working, input-required, auth-required, completed, canceled, failed, rejected, and unknown — and either side can observe the transitions. That lifecycle exists because delegation is asynchronous by nature: the delegator sends work, the delegatee does it over seconds or minutes, and both need a shared vocabulary for progress and interruption. MCP has no equivalent because tool calls in MCP are request-response.

Second, discovery is a first-class surface. The agent cards and discovery essay covers the JSON documents an A2A agent publishes to describe what it can do, what auth it accepts, and what streaming modes it supports. Agent cards are the "what can you delegate to me" contract, and they carry the metadata a delegator needs before it commits to a task. MCP's tools/list is the tool-layer analog, but agent cards live at the peer level and are richer — they describe an agent, not a call.

Third, A2A treats streaming and back-pressure as normal. A delegated task can stream intermediate outputs, request additional input mid-run, and hand off authentication to the delegator's user. Those flows exist because a peer agent's work is not atomic — it is a small workflow the delegatee runs on the delegator's behalf. A2A is the "above" layer because it terminates at the top of the agent graph, at the boundary between agents that decide, not between an agent and a tool.

Where the picture breaks.

The two-layer picture is honest for a specific deployment shape: multi-vendor, network-connected, agents composed of tools from many sources delegating to peer agents that live elsewhere. That shape is common in 2026, but it is not universal, and two families of deployments collapse the picture.

The first is the single-vendor stack. An all-Anthropic, all-Google, or all-OpenAI deployment can wire an agent-to-agent handoff over the vendor's own SDK primitives without touching A2A at all. The delegation is still real, but the vendor supplies a proprietary shape for it, and A2A is only needed at the perimeter where a different vendor's agent enters. Teams inside one vendor's ecosystem often ship for months before they need the "above" layer, and treating A2A as mandatory in that phase is over-engineering. Draw A2A in when a second vendor appears, and not before.

The second is the local or edge deployment. A single machine running an agent that reaches a co-located tool over stdio does not need HTTP, OAuth, or agent cards. This is the scenario ACP was pitched for; the reason ACP folded is that A2A and MCP together handle it, but only if you accept that both layers collapse into the same process boundary. A local agent talking to a local tool is MCP over stdio, no A2A required. A local agent handing off to another local agent is A2A over stdio, no MCP hop between them. Operationally you are running one process talking to another with framed messages between them.

A third, subtler break: when the "tool" is itself an agent with its own reasoning loop, deployed as an MCP server for convenience, the picture inverts. A retrieval-augmented question-answering service exposed via MCP is a common example — on the wire it is a tool, semantically it is a delegated agent. Teams shipping this shape get confused about which observability primitives apply, because MCP tooling assumes leaf calls and A2A tooling assumes peer coordination. Pick one framing and stay with it until the joint interop spec makes the choice cleaner.

Planning against the two-layer picture (or without it).

The planning rule that survives contact with real deployments is to draw the trust boundary first, then map protocols onto the boundary crossings. Two components inside the same trust domain — same team, same auth, same audit chain — may not need a protocol between them at all; a direct function call is often correct. Two components that cross a trust boundary need a protocol, and the choice between MCP and A2A follows from what is on either side. Model reaching for a leaf capability across the boundary: MCP. Agent reaching for a peer agent across the boundary: A2A. Both crossings, in different places: both protocols. The full picture looks like this.

┌─────────────────────────────────────────────────────────────┐
│ Team A trust domain                                         │
│                                                             │
│   User ──▶ Host (Claude Desktop)                            │
│              │                                              │
│              ├── Agent A (planner)                          │
│              │       │                                      │
│              │       ├─ MCP ──▶ fs-server (leaf tool)       │
│              │       ├─ MCP ──▶ db-server (leaf tool)       │
│              │       │                                      │
│              │       └─ A2A ══════════════════════════╗     │
│              │                                        ║     │
└───────────────────────────────────────────────────────║─────┘
                                                       ║
┌──────────────────────────────────────────────────────▼──────┐
│ Team B trust domain                                         │
│                                                             │
│   Agent B (research specialist)                             │
│       │                                                     │
│       ├─ MCP ──▶ arxiv-server (leaf tool)                   │
│       └─ MCP ──▶ web-search-server (leaf tool)              │
└─────────────────────────────────────────────────────────────┘

Two trust domains, five wire crossings. Every MCP arrow is an agent's model reaching for a leaf capability. The single A2A arrow is the boundary crossing between peer agents that each own their own tools. Both protocols are earning their keep because the deployment has both shapes. Replace Team B with a second agent inside Team A's domain and the A2A arrow disappears — the delegation becomes a function call, or a shared queue, or whatever primitive the same-team infrastructure already offers. The protocol is only necessary when the boundary is real.

And when the whole system fits on one machine, both layers collapse into the same channel. That deployment looks like this.

Local process boundary
┌──────────────────────────────────────┐
│  Host binary                         │
│    ├─ Agent (stdio) ─▶ fs-tool       │  (MCP over stdio)
│    └─ Agent (stdio) ─▶ sub-agent     │  (A2A over stdio)
└──────────────────────────────────────┘
Two protocols, one transport, one trust domain.

The framing you carry away: pick your protocols against the boundaries you actually have, not against the diagram you saw in a vendor deck. The two-layer picture is real, but it is descriptive of a multi-vendor networked deployment. Inside a single vendor, inside a single machine, inside a single trust domain, one of the two layers usually falls away — and that is not a failure of the picture, it is the picture being honest about scope. Build the layer you need. Add the other one when a boundary appears that demands it.