MCP, A2A, ACP: the agent-protocol landscape

Pieter Bruegel the Elder, The Tower of Babel (1563) — many builders, mutually unintelligible tongues. Public domain.

Three acronyms, one real winner so far

If you have been near an AI conference talk in the last year you have heard that there are three agent protocols you need to know: MCP, A2A, and ACP. The talk usually presents them as a tidy stack — MCP for talking to tools, A2A for talking to other agents, ACP for lightweight messaging — and then moves on to a slide about how this unlocks the multi-agent future. The tidy version is wrong in one important way that the slide never mentions: by the time most people learned the three acronyms, one of them had already been folded into another. That detail is the whole story of where this landscape is going, so I want to start there and work backwards.

The honest map in May 2026 is this. MCP won the agent-to-tool layer outright and is not seriously contested. A2A is the leading candidate for the agent-to-agent layer and has real momentum but no decisive victory yet. ACP was a third entrant that aimed at lightweight agent messaging and, in August 2025, merged into A2A under the Linux Foundation. So the "three protocols" framing is really "one settled protocol, one contested layer, and one cautionary tale about how fast this consolidates." That shape is worth understanding before you let any vendor sell you on adopting all three.

MCP: agent to tool

I covered this one in depth in the post on what MCP actually is, so the short version here. Anthropic's Model Context Protocol, announced November 2024, standardises how a single agent connects to tools and data. It is JSON-RPC 2.0 over stdio or HTTP, exposing three primitives — tools, resources, prompts. It solved the M×N integration problem by making it M+N, and it won decisively: 97 million monthly SDK downloads by March 2026, adopted by Anthropic, OpenAI, Google, Microsoft, and AWS, and donated to the Linux Foundation's Agentic AI Foundation in December 2025.

The relevant point for this post is the scope. MCP draws a tight boundary: one agent, its tools, its data. It says nothing about a second agent. The moment your architecture has two autonomous agents that need to coordinate — delegate a task, hand off a result, negotiate who does what — MCP has nothing to say, by design. That gap is the entire reason the other protocols exist.

A2A: agent to agent

Google announced the Agent2Agent protocol (A2A) on April 9, 2025 at Google Cloud Next, and contributed it to the Linux Foundation in June 2025 under Apache 2.0. Where MCP connects an agent down to its tools, A2A connects an agent sideways to its peers — agents built by different vendors, in different frameworks, that need to discover each other and divide work.

A2A's design rests on three concepts: Agent Cards, a machine-readable advertisement of what an agent can do and how to reach it; Tasks, the unit of work that gets exchanged and tracked through a lifecycle; and a transport built on the same boring, proven plumbing as MCP — HTTP, server-sent events, JSON-RPC 2.0. The Agent Card is the interesting primitive, because it is the discovery mechanism: an agent publishes a card, other agents read it, and coordination becomes possible without either side hard-coding the other's existence. If that sounds structurally similar to how MCP lets a client ask a server "what do you have?", it is. Both protocols solve a discovery-and-description problem; they just point in different directions.

A2A has real adoption. The Linux Foundation reported that by its first anniversary the project had more than 150 supporting organizations, including Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, and — notably — IBM, which had backed a competing protocol. That last defection matters, and it is the bridge to the third acronym.

ACP: the one that already lost

IBM Research launched the Agent Communication Protocol (ACP) in early 2025 to power its BeeAI platform, an open-source system for discovering and running agents across frameworks. ACP made a defensible design bet that differed from A2A: it was REST-based and deliberately lightweight, with agents packaged with their capability descriptions at build time so there was no runtime discovery dependency, and a MIME-type-based message structure rather than predefined formats. For a certain class of simpler agent-invocation use cases, that minimalism was genuinely appealing — less ceremony than A2A's task lifecycle, easier to stand up.

It did not matter. In August 2025, ACP merged into A2A under the Linux Foundation's LF AI & Data umbrella, and the BeeAI platform that had run on ACP switched to A2A. The technical merits of REST-versus-task-lifecycle were never the deciding factor. The deciding factor was that A2A had Google's launch momentum and 150 organisations, and a lightweight protocol with a smaller backer in the same niche is a feature request, not a competitor. ACP's good ideas did not die — some of them inform A2A's evolution — but ACP as a separate thing you would adopt is gone, roughly six months after it appeared. That speed is the most instructive thing in this entire landscape.

flowchart TD
    subgraph tool["Agent → Tool layer (settled)"]
        MCP["MCP<br/>Anthropic, Nov 2024<br/>tools / resources / prompts"]
    end
    subgraph agent["Agent → Agent layer (consolidating)"]
        A2A["A2A<br/>Google, Apr 2025<br/>Agent Cards / Tasks"]
        ACP["ACP<br/>IBM, early 2025<br/>REST, lightweight"]
        ACP -- "merged Aug 2025" --> A2A
    end
    MCP -. "complementary,<br/>not competing" .- A2A

Where they overlap, and where the marketing lies

The clean story is "MCP for tools, A2A for agents, no overlap." Reality is messier in exactly the place you would expect. There is a real grey zone, because another agent is, from the calling agent's point of view, also a tool. You can absolutely wrap a remote agent behind an MCP tool interface and call it like any other tool, and people do. Conversely, A2A's task-exchange model can carry the kind of work you might otherwise structure as a tool call. The boundary between "this is a tool I invoke" and "this is a peer I delegate to" is a design decision, not a law of physics, and the protocols overlap precisely there.

The mainstream framing has mostly settled on treating them as complementary — MCP underneath for tools, A2A on top for agent coordination — and that is a reasonable default. But "complementary" is doing some load-bearing work for vendors who would like you to adopt their whole stack, and the overlap is real enough that in many systems you could pick one and never need the other.

Which brings me to the numbers, because this is where I get skeptical. The A2A marketing literature is full of productivity claims: systems using A2A can reduce inquiry-resolution time by 60%, improve developer productivity by up to 50%, lower IT costs by up to 30%. Treat every one of these the way you would treat a vendor benchmark for a database: as a number produced under conditions chosen to make it large. A protocol does not make a workflow 60% faster. A protocol is a wire format. What might make a workflow faster is a well-designed multi-agent system that happens to use the protocol — and whether that system is well-designed has approximately nothing to do with which JSON envelope its messages travel in. Attributing a workflow speedup to A2A is like attributing a fast website to HTTP. The HTTP is necessary and the HTTP is not why it is fast. These figures also collide with Gartner's finding that over 40% of agentic-AI projects will be cancelled by end of 2027 on cost and unclear value — which is hard to reconcile with an industry uniformly getting 60% faster, and easy to reconcile with an industry generating impressive numbers in slide decks.

We have seen this movie: SOAP, REST, and the consolidation phase

The thing this landscape most resembles is the web-services protocol wars of the 2000s. There was a heavyweight, committee-blessed, deeply-specified standard — SOAP, with WSDL and the whole WS-* family bolted on — and there was a lighter, more pragmatic alternative — REST, which was barely a specification at all, more an architectural style that rode on HTTP. For a few years it was genuinely unclear which would win, vendors backed both, and conference talks explained the tradeoffs with the same earnest tone today's talks use for MCP versus A2A. REST won the broad case largely because it was simpler and rode existing infrastructure, SOAP retreated to enterprise niches where its guarantees mattered, and the WS-* sprawl mostly evaporated.

The pattern that era teaches is the one playing out now: when a new integration problem appears, the first response is a burst of competing protocols, and the second response — usually within a couple of years — is brutal consolidation toward whichever option had the best combination of momentum, backing, and "rides on plumbing everyone already has." MCP, A2A, and the now-absorbed ACP all chose JSON-RPC or REST over HTTP for exactly that last reason; nobody wanted to re-fight the transport war. ACP's merger into A2A six months after launch is the consolidation phase arriving early, and there is no reason to expect it to be the last merger. The early-protocol-war phase rewards picking the one with momentum and ignoring the ones with better slide decks.

This connects to a point I keep coming back to in the post on AI IDEs being skins over the same models: the genuinely structural change in the LLM stack between 2024 and 2026 happened at the tool-and-coordination layer, not at the model or editor layer. Protocols are where that change is being negotiated, and protocols consolidate. Betting your architecture on the tidy three-protocol stack is betting against the most reliable pattern in the history of integration standards.

A short close

The agent-protocol landscape in May 2026 is one settled layer, one contested layer, and one fresh grave. MCP owns agent-to-tool and is not going anywhere. A2A is the front-runner for agent-to-agent, with real backing and a sensible design, but "front-runner" in a young protocol war is not the same as "winner," and the prudent move is to use it where you need agent coordination while keeping your own coupling to it thin. ACP is the reminder of why thin coupling matters: a reasonable protocol with good ideas and the wrong backer, absorbed within six months.

The deeper point is to keep the layers separate in your own head even when the marketing fuses them, and to discount every productivity percentage attached to a protocol name to roughly zero. A wire format does not make your agents smart, fast, or coordinated — and as the post on what "agentic" actually means argues, most of what gets sold as agent infrastructure is a prompt with a protocol logo next to it. The protocols are real and worth understanding. The story being told about them is mostly the consolidation phase wearing a growth-phase costume.