MCP vs A2A: which layer each protocol owns

Ask which of MCP and A2A is going to win and you've already misread the map. They aren't competitors. They're adjacent layers of the same stack, they now live under the same foundation roof, and the companies backing one overwhelmingly back the other. What's worth understanding is exactly where the seam between them sits — because that seam is where architectures go wrong.

The one-line version: MCP connects an agent to tools. A2A connects an agent to other agents. Google said it plainly at A2A's launch — the protocol "complements Anthropic's Model Context Protocol" (launch post, April 2025) — and eighteen months of adoption has kept the boundary where they drew it.

The two protocols, side by side

Where the seam actually sits

The clean test: does the thing on the other end have its own agency?

A database, a calendar, a payment API, a browser — these are capabilities. They don't decide, they respond. That's MCP's side: the agent holds the loop, calls the tool, gets a structured result back in-context, and keeps reasoning. The tool never says "I'll get back to you Thursday."

Another agent — a supplier's ordering agent, a colleague's research agent, a vendor's support agent — has its own model, its own tools, its own owner, and its own opinion about how to do the job. You don't call it; you delegate to it. It might come back in four seconds or four days, might ask a clarifying question mid-task, might decline. A2A's task lifecycle (including its input-required state — a task parked, waiting on a human) exists precisely because delegation isn't a function call (spec).

The architectural mistake both directions: wrapping a genuinely autonomous agent as an MCP "tool" flattens its negotiation into a blocking call and loses the long-running task state. Wrapping a dumb API as an A2A "agent" adds ceremony to what should be a millisecond round-trip. When a system feels over-engineered or weirdly brittle at this layer, someone usually put the seam in the wrong place.

How the race actually ended

Both protocols won their layers, and faster than standards usually do.

MCP's 2025: OpenAI adopted it in March, Google's Demis Hassabis announced Gemini support in April, Microsoft built it into Windows 11 at Build, and in December Anthropic donated it to the new Agentic AI Foundation, co-founded with Block and OpenAI. When your fiercest competitors adopt your protocol and then co-found its foundation, the layer is settled.

A2A's path was different but rhymes: 50+ launch partners, a Linux Foundation donation within three months, v1.0 in March 2026, and the quiet kill shot — IBM's rival ACP protocol ceased development and merged into A2A in August 2025. Layers this young rarely get a clean consolidation; this one did.

Two traps for anyone reading older coverage. "A2A v1.0 released April 2026" circulates widely — that date is the Linux Foundation's one-year press release, not the release tag (v1.0.0 landed March 12, 2026; GitHub is authoritative). And "ACP" now usually refers to Zed's Agent Client Protocol — an unrelated editor-to-coding-agent protocol that claimed the acronym after IBM's died.

What this means if you're building

Start with MCP; you'll need it almost immediately, and it's the safer dependency — broader deployment, an official registry, and the most neutral governance in the stack. Add A2A when a second independent agent genuinely enters the picture, not before; most single-product architectures never need it, and premature A2A is the most common form of the seam mistake. And keep the layers honest in your own design docs: "tool" and "agent" are architectural claims, not vibes.

Both entries on the tracker carry current status calls and every source above — they get re-checked as the specs move.