← All posts
·6 min read

MCP and A2A: The Two-Layer Protocol Stack Your Agent Architecture Actually Needs

MCPA2AAI Architecture

Two protocols quietly stopped being single-vendor experiments this year. Anthropic donated the Model Context Protocol to the newly formed Agentic AI Foundation, under the Linux Foundation, after MCP passed 10,000+ servers and roughly 97 million downloads — enough adoption that single-vendor governance stopped making sense. Google's Agent2Agent protocol has been under Linux Foundation governance since mid-2025, and IBM's competing Agent Communication Protocol folded into A2A rather than continue fragmenting the space. What's left is a genuine two-protocol stack, and the architectural mistake I keep seeing is treating them as interchangeable instead of asking which layer a given connection actually belongs to.

Vertical access and horizontal coordination are different problems

Your agentBooking agentpeer, another vendorSupport agentpeer, same orgA2A — horizontal, peer-to-peerAgent Cards advertise capability, coordination between agentsRetrieval indexsearch docsPayments APIissue refundCalendarcheck availabilityMCP — vertical, client-serverJSON-RPC over stdio, agent-to-tool and agent-to-data accessSame agent, two different protocols — reaching sideways to a peer is not the same problem as reaching down to a tool

MCP is a client-server protocol, JSON-RPC over stdio, built for one direction: an agent reaching down into a tool, a database, a retrieval index, an API it doesn't own the logic of. The relationship is asymmetric by design — the agent is the client, the tool is the server, and the tool has no opinion about who else is calling it. A2A is peer-to-peer, built for the opposite direction: an agent reaching sideways to another agent that has its own reasoning, its own state, and no obligation to expose an API — only a capability description, an Agent Card, that says what it can do and how to ask. Under Linux Foundation governance, both now evolve through an RFC process with a Technical Steering Committee that includes seats from Anthropic, Google, and OpenAI, which matters less for the protocol mechanics than for the signal it sends: neither one is going away or getting silently redesigned by whichever vendor controls it this quarter.

Where teams get this wrong

The mistake is treating "agent needs to talk to another agent" as just another MCP tool call — wrapping a peer agent behind a tool-shaped interface because MCP was already wired up and adding A2A felt like extra infrastructure. It works, technically, right up until the peer agent needs something MCP was never built to carry: multi-turn negotiation, partial results streamed back over the course of a long-running task, or a capability the calling agent didn't know existed until the Agent Card told it so. Forcing a peer relationship through a tool-shaped protocol gets you a brittle, one-shot integration where a genuinely conversational one was needed — because you can't easily negotiate with a database, and MCP was designed for talking to databases.

The opposite mistake is rarer but not rare: routing a straightforward tool call through A2A because "everything is an agent now." A payments API doesn't have intentions, doesn't need to advertise a capability card, and doesn't benefit from peer-to-peer semantics — it needs a client-server call with a clean, typed contract, which is exactly what MCP already does well.

The test that actually decides which layer to use

Ask whether the thing on the other end has its own reasoning loop or just exposes deterministic capability. A retrieval index, a payments API, a calendar system — none of them decide anything, they execute. That's MCP, every time. A booking agent from a different vendor, a specialized support agent in another part of your org, anything that might reasonably say "I can't do that, but I can do this instead" — that's a peer, and peers need A2A's negotiation model, not a tool call pretending to be one.

Two protocols, not a debate about which one wins

The framing I'd push back on is "MCP versus A2A," because it isn't a competition — it's a stack, the same way TCP and HTTP aren't competing for the same job. An agent architecture that only implements one of the two hasn't simplified anything; it's just forcing every relationship through the wrong shape for half its connections. The actual design decision isn't which protocol to adopt. It's drawing the line, per connection, between "this is a tool I'm calling" and "this is a peer I'm negotiating with" — and building both layers, because production agent systems need both kinds of edges.