A2A vs. MCP: The Coordination Layer You Haven't Needed Yet

23 min read

A2A vs. MCP: The Coordination Layer You Haven't Needed Yet

· 23 min read
An editorial illustration on warm cream paper showing a three-step ascending staircase drawn in black ink. The lowest step holds four small identical agent figures crowded inside one shared rounded box labelled IN-PROCESS. The middle step shows a single agent reaching down through a pipe to a row of tool icons (a database, a gear, and a plug) labelled MCP. The top step shows two agents standing in their own separate fenced enclosures, shaking hands across a dashed boundary line, labelled A2A, used as a metaphor for the coordination ladder from many agents in one process, to one agent with its tools, to two separately-owned agents coordinating across a boundary.

You already solved tool access. Every agent you run reaches its database, its payment API, and its internal services through the Model Context Protocol. By early 2026, that choice had stopped being controversial. MCP crossed roughly 97 million monthly SDK downloads. All five of Anthropic, OpenAI, Google, Microsoft, and AWS had adopted it within thirteen months of its November 2024 launch (Digital Applied, 2026). So the next question showed up right on schedule: if MCP gives an agent its hands, what lets two agents work together? The answer everyone points at is A2A, and the pitch is loud. The protocol went from 50 to more than 150 supporting organizations in a single year (Linux Foundation, 2026).

Here’s what the ranking articles get wrong. They line MCP and A2A up in a feature table and tick boxes down two columns. They conclude that you should use both. That framing skips the only question that decides anything: which layer does your problem actually live at? Most teams reaching for A2A right now don’t have a coordination problem. They have an orchestration problem wearing a coordination costume.

I’ll show you the ladder I use. I run five Claude Code subagents that fan out to review a pull request. They all talk to a single code-intelligence daemon on one machine, over one shared MCP daemon behind many subagents. Zero A2A calls. Not because A2A is bad, but because every one of those agents shares a process boundary and a trust domain. A network coordination protocol between them would buy nothing but latency and failure surface. Below a real boundary, you don’t need A2A. This post is about where that boundary sits.

Key Takeaways

  • MCP and A2A are complementary layers, not rivals. MCP is agent-to-tool; A2A is agent-to-agent (Zuplo, 2026). The “vs” in the title is bait: the real answer is “and, at different layers.”
  • The maturity gap is the argument. MCP is mature (≈97M monthly downloads, 10,000+ public servers, universal framework support). A2A is nascent (150+ orgs, 22k GitHub stars, but you should expect to build the integration yourself) (Digital Applied; Linux Foundation, 2026).
  • Walk the ladder (in-process, then MCP, then A2A) and stop at the first rung that fits. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and premature complexity is a named cause (Gartner, 2025).
  • A2A earns its complexity only across a real boundary: separate vendors, separate organizations, or separately-owned agents with their own trust domains. Below that line, in-process orchestration or plain MCP wins.
  • The expensive failures are coordination defects, not model limits. A Berkeley study grouped 14 multi-agent failure modes into three coordination categories, and reported production failure rates run 41–87% (MAST, 2025; Maxim AI, 2026).

MCP gives an agent hands; A2A lets a team of agents coordinate

These are complementary layers, not competitors. MCP answers one question: how does an agent reach a tool, whether a database, a Stripe call, or an internal API? A2A answers a different one: how one autonomous agent discovers another, delegates a task, and coordinates over a long-running exchange (Zuplo, 2026). In 2026, MCP had been adopted by all five of Anthropic, OpenAI, Google, Microsoft, and AWS within about thirteen months of launch (Digital Applied, 2026). That kind of five-vendor convergence is rare, and it tells you MCP won the tool layer outright.

The reference architecture people actually ship makes the split obvious. An orchestrator uses A2A to delegate to specialist agents; each specialist uses MCP to reach its own tools. One layer sits on top of the other. So the “vs” framing is a category error. You don’t pick MCP or A2A any more than you pick TCP or HTTP. One runs on the other, at a different altitude.

The practical upshot: if you already run MCP, you have not started on A2A. You have finished the layer below it. Whether you ever climb higher depends entirely on what your agents’ relationship looks like.

Citation capsule: MCP and A2A are complementary layers, not competing standards. MCP standardizes agent-to-tool access; A2A standardizes agent-to-agent coordination (Zuplo, 2026). MCP reached five-vendor adoption (Anthropic, OpenAI, Google, Microsoft, and AWS) within roughly thirteen months of its November 2024 launch. That is why it won the tool layer outright (Digital Applied, 2026).

Why is the maturity gap the whole argument?

MCP is mature infrastructure; A2A is a nascent standard you will partly build yourself. In 2026, MCP sat at roughly 97 million monthly SDK downloads and more than 10,000 active public servers. Its framework support was universal, spanning LangChain, CrewAI, the OpenAI SDK, and Claude Desktop (Digital Applied, 2026). A2A had 150+ supporting organizations and more than 22,000 GitHub stars, with SDKs in five languages. But its native framework support is patchy (Linux Foundation, 2026).

That patchiness matters more than the logo count. CrewAI ships A2A natively; LangGraph and AutoGen leave it to community integrations you maintain (gurusup, 2026). Five SDK languages is real, but an SDK is not turnkey framework support. The honest summary of A2A in 2026 is the one the practitioners keep repeating: expect to build the integration yourself. Compare that to MCP, where you add a server block and the client just works.

None of this says A2A is a bad bet. It says A2A is an early bet, and early bets carry a tax the mature layer doesn’t. Adopting MCP costs you a config block. Adopting A2A in 2026 costs you integration code you own and a spec that’s still moving. Keep that asymmetry in mind; it’s the reason the decision tree starts at the cheapest rung, not the trendiest one.

Citation capsule: In 2026, MCP reached roughly 97 million monthly SDK downloads and 10,000+ active public servers, with universal framework support. A2A had 150+ organizations, 22,000+ GitHub stars, and SDKs in five languages, but uneven native support: CrewAI ships it, while LangGraph and AutoGen do not (Digital Applied; Linux Foundation, 2026). Adopting MCP costs a config block; adopting A2A costs integration code you maintain.

What is the decision tree for coordinating agents?

Walk the ladder from cheapest to most complex, and stop at the first rung that solves your problem. In 2026, Gartner predicted that more than 40% of agentic AI projects would be canceled by the end of 2027, citing escalating cost and unclear value (Gartner, 2025). Premature complexity is the failure mode that number is describing. The ladder is how you avoid it.

There are three rungs. Rung one is in-process orchestration: subagents in one process, one machine, one trust domain, sharing state directly. Rung two is MCP: an agent needs external tools or data. Rung three is A2A: autonomous agents with independent ownership have to coordinate across a boundary. The gates between them are simple yes/no questions. The whole point is to fail a gate as early as you can, which is how you learn you don’t need the next rung.

Notice what the gates test. It is not “how many agents do you have.” A fleet of ten subagents on one machine still fails gate one and stays in-process. The trigger is the boundary: separate owners, separate trust domains, or separate deployment lifecycles. If none of those is true, you’re on the bottom two rungs no matter how sophisticated the workflow feels.

Citation capsule: The coordination ladder has three rungs (in-process orchestration, then MCP, then A2A), and you stop at the first that fits. The trigger for climbing is a real boundary (separate owners, trust domains, or deployment lifecycles), not the number of agents. Gartner predicted more than 40% of agentic AI projects would be canceled by the end of 2027, with premature complexity a named driver (Gartner, 2025).

When are in-process subagents enough? (That’s most of you)

If your agents share a process, a machine, and a trust boundary, you don’t need a network protocol between them. You need good orchestration. Anthropic’s own engineering write-up is blunt about the cost. Multi-agent systems fit poorly with tightly interdependent work like coding, where tasks rarely parallelize and agents can’t coordinate cleanly in real time. And multi-agent dispatch already burns around 15x the tokens of a chat interaction, versus roughly 4x for a single agent (Anthropic Engineering, 2025). Adding a wire protocol on top of that spends more and buys nothing your process boundary wasn’t already giving you for free.

This is the rung I actually live on. My five PR-review subagents share one machine and one code-intelligence daemon. They coordinate through the orchestrator and shared state, and there’s no agent-to-agent protocol anywhere in the topology. The interesting decision was never “MCP or A2A.” It was when to spawn a subagent versus stay in-context. And it was how to fan a feature build out across subagents without them stepping on each other. That’s an orchestration question, and orchestration is where the leverage is for most teams.

The data backs the pattern. In 2026, orchestration (hub-and-spoke, an orchestrator dispatching to specialists) made up roughly 70% of production multi-agent deployments, while peer-collaboration and free-for-all group-chat patterns largely failed to survive production (niteagent, 2026). Peer collaboration is exactly the pattern A2A is built to standardize. When the pattern itself is the one that keeps dying in production, adopting the protocol that formalizes it is a strange first move.

Citation capsule: When agents share a process, machine, and trust domain, they need orchestration, not a coordination protocol. Multi-agent dispatch costs about 15x the tokens of a chat interaction, versus roughly 4x for a single agent. Anthropic also notes multi-agent fits poorly with tightly interdependent work like coding, where tasks rarely parallelize (Anthropic Engineering, 2025). Orchestration made up around 70% of production multi-agent deployments in 2026 (niteagent, 2026).

When is MCP alone the whole answer?

A large share of “multi-agent” designs are really one agent with good tools. If the second “agent” is deterministic, stateless, or just a capability, expose it as an MCP tool, not an A2A peer. This matters because the market is crowded with relabeling. In 2026, only 17% of organizations had actually deployed AI agents, even as more than 60% said they intended to within two years (MarTech, on Gartner data, 2025). The gap between intention and deployment is where relabeling thrives. A chatbot gets renamed an “agent,” and “coordination” turns out to be a plain function call.

So run the test before you climb: is this second thing actually an agent, or a tool? An agent reasons, plans, and decides under uncertainty. A tool takes an input and returns an output. If the thing you want to “coordinate with” always does the same thing given the same input, it’s a tool. The higher-value investment is to design MCP tools tool-shape, not API-mirror, because the tool description is the prompt the agent routes on. Get the tool surface right and a surprising number of your “coordination” problems evaporate, because they were never coordination problems.

Citation capsule: Most “second agents” are really tools. If the component is deterministic or stateless, expose it via MCP rather than treating it as an A2A peer. Only 17% of organizations had deployed AI agents in 2026 even as more than 60% intended to within two years (MarTech, on Gartner data, 2025). That gap is where a tool gets relabeled an agent and a function call gets relabeled coordination.

When does A2A genuinely earn its complexity?

A2A is worth it exactly when the coordination crosses a real boundary: separate vendors, separate organizations, or separately-owned agents with their own tools and trust domains. That’s where a standardized discovery-and-delegation protocol beats a bespoke API, because neither side controls the other’s code. The enterprise guidance in circulation lands in the same place. Use MCP for all tool access, and add A2A only for cross-vendor or cross-org agent coordination. The smaller-team version is even simpler: MCP first, then reach for A2A once you genuinely operate more than one independently-owned AI system.

The protocol’s own history explains why it’s positioned this way. A2A launched in April 2025. Google donated it to the Linux Foundation on June 23, 2025 (Google Developers Blog, 2025), and the competing Agent Communication Protocol merged into it that August (Zuplo, 2026). By April 2026 it had crossed 150+ organizations, with early vertical production use in supply chain, financial services, insurance, and IT operations (Linux Foundation, 2026). Look at those verticals. They’re all cases where agents owned by different parties have to interoperate: a supplier’s agent and a buyer’s agent, an insurer’s and a broker’s. That’s the boundary the protocol was designed for, and it’s the boundary that should trigger your adoption.

Citation capsule: A2A earns its complexity across vendor, organization, or ownership boundaries. There, a standardized discovery-and-delegation protocol beats a bespoke API, because neither side controls the other’s code. A2A grew from 50+ to 150+ organizations in its first year, with early production use in supply chain, financial services, insurance, and IT operations (Linux Foundation, 2026). Every one is a case of separately-owned agents interoperating.

What does adopting a nascent protocol too early cost you?

The expensive failures in multi-agent systems are coordination defects, not model limits. The MAST study out of Berkeley collected 1,600+ annotated traces across 7 popular multi-agent frameworks. It grouped 14 distinct failure modes into three categories: system-design issues, inter-agent misalignment, and task verification (Cemri et al., MAST, arXiv 2503.13657, 2025). Reported production failure rates for multi-agent LLM systems run 41–87%, and the root causes cluster on coordination, not on the base model (Maxim AI, 2026). Adding a coordination protocol before you have the boundaries to justify it doesn’t reduce those failure surfaces. It multiplies them.

There’s a softer cost too, and it’s the one I’d watch for on a team. Call it architecture cosplay: adopting A2A to look like a distributed agent system while having none of the actual boundary problems it solves. The tell is that the “150 organizations” number gets cited as a buy signal. The number that matters is production retention: who keeps A2A running after the first real operational incident, not who added it to a slide. And the spec is still consolidating. ACP folding into A2A in August 2025 was healthy for the ecosystem. But if you’d built on ACP in early 2025, you paid a migration tax for betting on the wrong protocol early. Nascent standards move. That movement is a cost you inherit the moment you adopt.

Citation capsule: Multi-agent failures are coordination defects, not model limits. The MAST study collected 1,600+ traces across 7 frameworks, grouping 14 failure modes into three categories: system-design issues, inter-agent misalignment, and task verification (Cemri et al., arXiv 2503.13657, 2025). Reported multi-agent production failure rates run 41–87% (Maxim AI, 2026). Adopting a coordination protocol before you have a boundary to justify it multiplies those surfaces rather than reducing them.

FAQ

Do I need A2A if I already use MCP?

Usually not yet. MCP handles tool access; A2A handles agent-to-agent coordination, so finishing MCP doesn’t start you on A2A. It completes the layer below it (Zuplo, 2026). Add A2A only when your agents cross a vendor, organization, or ownership boundary. Below that line, in-process orchestration or plain MCP is the cheaper, more reliable answer.

Is A2A production-ready in 2026?

It’s a governed Linux Foundation standard with 150+ supporting organizations, 22,000+ GitHub stars, and SDKs in five languages (Linux Foundation, 2026). But framework support is uneven: CrewAI ships it natively, while LangGraph and AutoGen leave it to community integrations. So expect to build and maintain the integration yourself rather than flipping a switch.

What happened to ACP?

The Agent Communication Protocol merged into A2A under the Linux Foundation on August 29, 2025, and its repository was archived (Zuplo, 2026). It’s a useful data point for anyone weighing early adoption. The agent-protocol space is still consolidating, and betting on a specific standard in 2025 sometimes meant paying a migration tax when the ecosystem converged.

When do in-process subagents beat A2A?

Whenever your agents share a process, a machine, and a trust domain. Orchestration made up roughly 70% of production multi-agent deployments in 2026, while peer-collaboration patterns largely failed production (niteagent, 2026). A wire protocol between co-located agents adds latency, cost (around 15x chat-interaction tokens), and failure surface with no boundary to justify it.

Conclusion

MCP and A2A were never rivals. They’re layers: MCP is your agent’s hands, A2A is how separately-owned agents shake hands, and one runs on top of the other. MCP is mature and cheap to adopt; A2A is nascent and, in 2026, something you largely build yourself. So walk the ladder and stop at the first rung that fits your problem. Most teams share a process and a trust domain across their agents. So the honest answer is in-process orchestration, not a network protocol adopted to look distributed. A2A earns its place only when coordination crosses a vendor, org, or ownership boundary. The cost of jumping there early is measured in coordination-failure surface and ecosystem-churn tax, not in features you’re missing.

Before you add A2A, draw your own boundary map. If every agent shares a process and a trust domain, spend the effort on designing MCP tools tool-shape, not API-mirror and on the graph-shaped surface agents actually need instead. And when a pipeline does need to route work (a cheap model here, a stronger one there), that’s still orchestration, not coordination. Downshift the model per call inside a pipeline before you reach for a protocol between agents. The boundary is the trigger. Until you have one, the coordination layer is a layer you haven’t needed yet.

Sources

Share this post

If it was useful, pass it along.

What the link looks like when shared.
X LinkedIn Bluesky

Search posts, projects, resume, and site pages.

Jump to

  1. Home Engineering notes from the agent era
  2. Resume Work history, skills, and contact
  3. Projects Selected work and experiments
  4. About Who I am and how I work
  5. Contact Email, LinkedIn, and GitHub