A2A Is a Protocol, Not a Platform

A2A gets the communication contract right, but it stops at delegation. The post walks through the missing runtime fabric around discovery, coordination, authorization, recovery, and scaling, and argues that protocols do not operate themselves.

Quite often when I bring up agent-to-agent communication, the second answer I hear - right after "MCP solves that" (it doesn't) - is "Google built A2A for exactly this."

They did. And on paper, A2A gets a lot right. Agent Cards for capability discovery. A task lifecycle with proper state management. Structured message format with artifacts. SSE streaming. It's a well-designed specification for formalizing the delegation of work between agents.

So what happened?

Google announced A2A in April 2025 with over 150 organizations signed up. Adobe, S&P Global, Tyson Foods. The Linux Foundation gave it a home. A production-ready version was expected by end of 2025. It's now Q1 2026 and development has slowed significantly. Most of the ecosystem consolidated around MCP - which, as I argued last week, isn't even good at agent-to-agent.

The irony is thick. The protocol designed for agent-to-agent lost to the protocol designed for agent-to-tool. Not because A2A is worse - technically it's better at what it was built for. But MCP gave developers utility in ten minutes. Connect Claude to Jira, GitHub, Notion - done. A2A required building new infrastructure before you could do anything at all.

That infrastructure gap is the real story.

A2A standardizes the delegation between two agents. It intentionally does not provide the production infrastructure around that delegation. This isn't a flaw - it's a design choice. A2A is a protocol, not a platform. But teams evaluating it discover the gap fast.

Discovery. A2A defines Agent Cards - JSON documents describing what an agent can do. But there's no standard registry to find them. The spec does not define a standard API for curated registries. It's an open proposal under community discussion, not an implemented feature. So your agents have identity cards but no directory to look each other up in.

Coordination. A2A is point-to-point delegation. Agent A sends a task to Agent B, waits for a response. The moment a problem needs three agents working together, you're building orchestration logic - which agent to invoke when, what context each one needs, how to combine results, what to do when Agent B fails mid-chain. None of this is in scope for the protocol.

Authorization. A2A supports authentication - agents can declare supported schemes in their Agent Cards. But it does not prescribe a standard authorization model. Once an agent is authenticated, the remote agent decides what it's allowed to do. Security researchers have flagged this as "authorization creep" - agents accumulate the power to act across systems without explicit, delegated user authorization tied to specific actions.

Durability. A2A supports async tasks and push notifications, which helps with long-running operations. But once a task reaches a terminal state, it cannot be restarted. If an agent crashes mid-task, recovery is your problem.

Scalability. A2A's peer-to-peer HTTP connections create N-squared connectivity overhead as agent counts grow. Changing one agent can require adjustments in others, slowing deployments and increasing cascading failure risk.

None of this means A2A is bad. It means A2A is a communication standard, and communication standards don't deploy themselves. HTTP is a great protocol. You still need web servers, load balancers, CDNs, and monitoring to run a production website. A2A is the HTTP of agent delegation. Everything above it, below it, and between it is left as an exercise for the reader.

MCP tried to be everything and ended up fighting its own context window. A2A scoped itself correctly but left the hard parts to the user. Both are valuable. Neither is sufficient. And the layer that's actually missing - the production infrastructure that makes agent systems work - is what I'll keep exploring in this series.