Single-agent demos hit a ceiling around 2025. The next wave is systems of specialised agents that need to talk to each other — and three protocols are competing to define that layer. Here is how Google A2A, MCP-as-A2A, and OpenAI Swarm stack up.
Why A2A is now a protocol-level problem
An agent that only calls tools is a solved problem. An agent that delegates to another agent is not. The hard parts — identity, context handoff, error semantics, cancellation, cost accounting — do not exist in any tool-call spec. Teams building multi-agent systems today reinvent them, badly, on every project.
If you are new to the multi-agent shape of the problem, start with multi-agent orchestration patterns and come back.
The three contenders
Google A2A
Announced in early 2026, Google's A2A spec treats agents as first-class HTTP peers. Each agent exposes an /agent.json manifest describing its capabilities, authentication, and task lifecycle endpoints.
Strengths:
- Async-first. Tasks are long-running by default. Poll or webhook for completion.
- Explicit task state machine. Submitted → working → input-required → completed/failed.
- Streaming artefacts. Agents can stream partial results, not just final text.
Trade-offs:
- Heavier than MCP — every agent is an HTTP server.
- Spec surface is large; interop between half-implementations is messy.
MCP as an A2A bridge
MCP was designed for tools, not peers, but in practice teams use it for A2A. A "router agent" exposes other agents as MCP tools. The caller sees one server; internally it dispatches to specialised sub-agents.
Strengths:
- Zero new protocol. If you already run MCP, you already run A2A.
- Composability. Sub-agents can themselves be MCP tools.
- Tooling parity. Every MCP client works out of the box.
Trade-offs:
- No native task lifecycle — you have to model it on top.
- Synchronous-feeling API; long tasks need custom streaming.
OpenAI Swarm
Swarm is less a protocol, more a handoff pattern shipped by OpenAI. One agent can transfer the conversation to another by returning a handoff object. Conversation history carries across.
Strengths:
- Tiny surface. A handoff is a function return value.
- Pragmatic. Works well for linear "triage → specialist" flows.
Trade-offs:
- Shared conversation state couples all agents tightly.
- No authentication, no distribution. It is a single-process library, not a network protocol.
Side-by-side
| Dimension | Google A2A | MCP-as-A2A | OpenAI Swarm |
|---|---|---|---|
| Transport | HTTP + SSE | JSON-RPC (stdio/HTTP) | in-process |
| Identity | per-agent, pluggable | inherited from MCP | none |
| Task state | explicit state machine | caller-managed | implicit |
| Streaming | native | extension | text only |
| Cross-org use | designed for it | possible | no |
| Ecosystem | Google-led | 1000+ MCP servers | OpenAI-only |
| Maturity (Apr 2026) | early adopters | production-tested | demo-grade |
When to pick which
Pick Google A2A if:
- You need cross-organisation agent collaboration (vendor agents talking to client agents).
- Tasks run for minutes to hours.
- You already operate HTTP services and want observability parity.
Pick MCP-as-A2A if:
- Your agents live in the same trust boundary.
- You want to reuse the MCP ecosystem (existing tools become "sub-agents").
- You prefer one protocol over two.
Pick OpenAI Swarm if:
- Prototype or internal-only.
- Linear handoffs (triage, escalation).
- You accept OpenAI lock-in.
The handoff problem is the real problem
Whichever protocol you pick, the hard part is context handoff: what state travels between agents, what stays behind, who owns mutation. A2A protocols all punt on this — they give you the wire format, not the semantics.
In practice you end up with three handoff styles:
- Full context. Receiving agent gets the entire conversation. Expensive in tokens, but simple.
- Summary handoff. Origin agent produces a summary for the next. Cheaper, but lossy — and the summariser becomes a failure point.
- Shared memory. Both agents read/write a shared store. Decouples state from the wire protocol. Best for long flows.
Shared memory pairs well with persistent agent memory and cross-session agent memory.
What will probably happen
Expect consolidation by late 2027. MCP is likely to absorb A2A use cases through an optional extension (draft proposals already exist). Google A2A will remain for cross-org flows where HTTP-native semantics matter. Swarm will stay a pattern, not a protocol.
If you are architecting now, build on MCP with a clean internal abstraction for handoff semantics — you will port it cheaply when the dust settles.