Why A2A's Direct Messaging Is the Wrong Default for Multi-Agent Systems

MCP now clears 97 million monthly SDK downloads, runs across 10,000 active servers, and ships natively in ChatGPT, Claude, Cursor, Gemini, and Microsoft Copilot. The tooling layer for AI agents is, for practical purposes, settled. The coordination layer is not - and the emerging consensus is papering over a real architectural argument.

The consensus position goes like this: MCP handles the vertical connection between a model and its tools; A2A handles the horizontal coordination between multiple agents. Use both, layer them, done. It's a clean story. It also leads a lot of teams toward the wrong default.

My claim is this: for the majority of multi-agent systems, A2A's direct-messaging model is the wrong primitive to reach for first. The teams that are actually succeeding in production are mostly doing something simpler - and they're reaching for A2A only at specific boundaries where it genuinely earns its place.

The problem with direct agent-to-agent messaging

Direct messaging sounds natural. Agents are like people; people send messages to each other. But if you design agent systems around direct messaging between endpoints, every agent becomes partially responsible for transport behavior, delivery guarantees, retry logic, concurrency control, traffic shaping, observability, and failure recovery. That is a poor abstraction - it pushes infrastructure concerns into the application layer and then pretends interoperability has been solved because messages have a shared format.

That's not hypothetical. HTTP's stateless nature fundamentally conflicts with the reality of AI agent interactions. Consider a supply chain optimization that unfolds over hours or days, with multiple agents contributing analysis, awaiting approvals, and coordinating with external systems. HTTP connections timeout, clients disconnect, and the state is lost. There is no inherent mechanism for durable state management, resumable conversations, or persistent messaging. Developers must construct elaborate state management systems - typically involving databases and custom correlation logic - just to handle basic conversation continuity that message-oriented protocols provide natively.

Without built-in orchestration primitives, developers must build custom workflow engines, control planes, or state machines - solutions that add complexity, introduce new failure modes, and aren't interoperable across environments. A2A becomes a thin protocol layer requiring heavy infrastructure scaffolding to be usable at scale.

This is not a knock on A2A's engineering quality. It's a consequence of its design choice. The protocol standardizes the message envelope. It does not standardize the infrastructure that makes message-passing reliable - and that infrastructure is exactly what kills you in production.

What actually works: shared state over direct messages

In graph-based frameworks like LangGraph, all agents read from and write to a single, shared state object or "blackboard." This ensures no agent is operating on outdated or asymmetric information. That pattern - shared state, not direct messages - is what most production multi-agent systems are running today, and it handles coordination without any of the delivery-guarantee problems.

Most multi-agent coordination does not require direct agent communication at all. For the majority of multi-agent systems, MCP by itself is sufficient. Agents coordinate through shared state rather than direct messages.

The failure mode when you ignore this is specific and unpleasant. A developer uses MCP to perfectly connect a research agent to a PostgreSQL database. But when the research agent hands data to a writer agent via A2A, the developer lets them communicate in conversational English. The writer agent misinterprets the unstructured text and hallucinates missing facts. It happens because developers treat A2A communication like human-to-agent communication.

There's also a subtler problem at the infrastructure level. State-plane divergence: during multi-agent task coordination, agents maintain inconsistent local views of shared context. Without a shared filesystem or state-synchronization protocol, agents embed full task specifications in messages rather than referencing canonical files, creating divergent copies that drift within minutes. This is a direct consequence of message-based coordination: the message carries messages, not state.

The comparison table nobody is making

The standard MCP-vs-A2A writeup treats these as complementary layers and stops there. The more useful framing is: what coordination pattern fits your actual system topology?

The practical guidance here is concrete: implement MCP first for tool and data integration - it's more mature, has broader support, and the local complexity is lower. Use a single-framework approach (LangGraph, CrewAI, or AutoGen) while your team learns multi-agent patterns. Add A2A at the boundaries where you need to integrate external agents or cross organizational lines.

Where A2A genuinely earns its place

This is the steelman, and it's a real one. The problem A2A actually solves is not intra-system coordination. It's the N×M integration problem at organizational boundaries.

Before A2A, if your billing agent (built on LangGraph) needed to hand work to your vendor's compliance agent (built on CrewAI), you wrote custom integration code. Swap the vendor out, rewrite the integration. There was no standard way for agents to discover each other, negotiate capabilities, or hand off tasks. If you had a "research agent" and a "writing agent," coordinating them required gluing everything together in application code. Swap out one agent for another? Rewrite the orchestration layer.

Google introduced A2A in April 2025 as an open protocol for agent interoperability with support from more than 50 partners at launch. In June 2025, Google donated A2A to the Linux Foundation, where the project launched with founding support from AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.

A2A reached v1.0 in early 2026. As of mid-2026, 150+ organizations - including AWS, Microsoft, Salesforce, SAP, IBM, and ServiceNow - have adopted it in production.

That adoption curve is real, and it reflects a real problem being solved. The Agent Card - a JSON document each agent publishes describing its capabilities and auth requirements - is genuinely useful when you're integrating agents across organizational lines. Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements, analogous to a service descriptor in microservice architectures.

There's a real security dimension too. Trustwave SpiderLabs researchers demonstrated a significant attack class in 2025: a rogue agent presents an inflated Agent Card with a description crafted to manipulate the orchestrator's LLM-based selection logic. Because most orchestrators choose specialist agents by reasoning over card descriptions, injecting persuasive natural language into a card's description field can hijack task routing. This is a form of prompt injection operating at the infrastructure layer. That's a production-grade concern that should shape how teams adopt A2A - verify Agent Cards cryptographically, not just semantically.

But none of this means A2A should be your default coordination primitive inside a single team's system. It means A2A is the right tool when you're federating agents across a trust boundary you don't control.

The architecture debate is not academic. Getting this wrong means your team spends the next six months building the infrastructure scaffolding A2A deliberately left out - retry logic, durable state, session recovery - instead of building the agents themselves.

The right sequence: MCP for tool access, shared state inside your system boundary, A2A only where you're handing work across an organizational or vendor line you don't control. That's not a compromise position. It's what the production data actually shows.

Multi-agent coordination protocols: common questions

What is the difference between MCP and A2A?

MCP connects a single agent to external tools, databases, and APIs through a standardized server interface. A2A connects one agent to another agent - specifically for task delegation and capability discovery across different frameworks or organizations. They operate at different layers and are designed to be used together, not as alternatives.

When should I use A2A instead of shared-state coordination?

Use A2A when agents cross an organizational or vendor boundary you don't control - for example, your orchestrator delegating to a third-party compliance agent. For agents inside the same codebase or team, shared-state patterns (LangGraph's state object, a Redis blackboard) handle coordination without A2A's infrastructure overhead.

Does A2A replace MCP for multi-agent systems?

No. A2A handles peer coordination between agents; MCP handles each agent's connection to tools and data. A production multi-agent system typically uses MCP at the tool layer and A2A - if needed - at the cross-boundary delegation layer. Most single-team systems can run on MCP plus a framework-level state layer without A2A at all.

What are the main failure modes of direct agent-to-agent messaging?

The two most common are state-plane divergence (agents hold inconsistent local views of shared context because messages carry snapshots, not canonical state) and HTTP session loss on long-running tasks (connections timeout, state is lost, and recovery requires custom logic the protocol does not provide). Both are solvable - they just require infrastructure work A2A explicitly leaves to implementers.

Is A2A production-ready?

A2A reached v1.0 in early 2026 and is in production at 150+ organizations. The spec is stable enough to build on. The gaps are operational rather than protocol-level: durable state management, observability across agent hops, and cryptographic Agent Card verification are left to the implementer and require real engineering investment before a system is production-safe.