MCP vs A2A vs ACP vs ANP: the agent protocol stack

Every few months a new acronym lands in the agent world and someone declares a war that does not exist. MCP versus A2A. A2A versus ACP. The framing is almost always wrong, because it assumes these protocols are fighting over the same territory. They are not. They are four pieces of one stack, and the fastest way to understand them is to stop asking “which one wins?” and start asking “which problem does each one solve?”

There are exactly two problems. An agent needs to reach things that are not agents — a database, a file system, a search index, a calendar. And an agent needs to reach other agents — to delegate a task it cannot do alone. The first problem is vertical. The second is horizontal. MCP owns the vertical. A2A, ACP, and ANP carve up the horizontal, and the only thing that separates those three is a single dial: how open is the world they assume?

The two axes

Hold that distinction firmly, because it is the whole article.

Vertical means an agent reaching down to its tools and context. One agent, many tools. This is the integration problem that every framework reinvented badly until late 2024 — every tool a bespoke adapter, every model a different calling convention. MCP standardizes it.

Horizontal means an agent reaching across to a peer. The hard parts here are not “how do I call a function” but “how do I find you, how do I know what you can do, how do I hand you a task and track it, and how do I trust you if we have never met?” Those questions get harder the more open the world gets — and that openness gradient is exactly what A2A, ACP, and ANP are spread across.

MCP: the vertical, and the one everyone already knows

The Model Context Protocol arrived from Anthropic in November 2024 and solved a problem so mundane that its absence had been quietly taxing every agent project for years: connecting a model to a tool was always custom work.

MCP is a client-server protocol built on JSON-RPC. Your agent is the client. Each tool, data source, or prompt library lives behind a server that speaks MCP. The server advertises what it offers — a set of tools the agent can call, resources it can read, prompts it can fill in — and the agent calls them through one uniform interface. Swap the database server for a different one and the agent code does not change. Add a new tool and every MCP-speaking agent can use it immediately.

The analogy that stuck is “USB-C for AI.” Before USB-C, every device had its own connector and you carried a drawer of adapters. After it, one port serves them all. MCP is that port for the agent-to-tool boundary. It says nothing about how two agents talk to each other — that is simply not its job. It is the vertical leg of the stack, and it is the most widely adopted of the four by a wide margin.

A2A: the enterprise horizontal

If MCP connects an agent to its tools, Google’s Agent2Agent protocol connects an agent to its colleagues. Announced in April 2025 and donated to the Linux Foundation in June 2025, A2A answers the horizontal questions head-on, for a world that is open but governed — a world of enterprises whose agents come from many different vendors but who still operate inside contracts, identity systems, and a measure of mutual trust.

Three ideas carry it.

Discovery via Agent Cards. Every A2A agent publishes a JSON file — an Agent Card — that declares who it is and what it can do: its skills, its endpoints, its authentication requirements. A peer fetches the card and now knows how to engage. This is the horizontal analogue of MCP’s tool advertisement, but one level up: it describes a whole agent’s capabilities, not a single function.

Delegation with a lifecycle. A2A is built around tasks, not one-shot calls. One agent hands another a task, and that task moves through explicit states — pending, in-progress, completed, failed. Because real agent work is long-running and sometimes streams partial results, the transport is HTTP plus Server-Sent Events plus JSON-RPC 2.0: request over HTTP, stream updates back over SSE, structure the payloads as JSON-RPC.

Opacity. This is the subtle, important one. An A2A agent stays a black box. It exposes what it can do, never how it does it — no internal prompts, no tool list, no model weights, no private state. Two competitors can collaborate precisely because neither has to reveal its implementation. Opacity is what makes cross-vendor cooperation commercially safe.

The momentum is real: 50-plus launch partners including Salesforce, SAP, ServiceNow, and MongoDB, and an explicit, stated stance that A2A is complementary to MCP rather than a replacement. That positioning is not diplomacy — it is the architecture. A2A is horizontal; MCP is vertical; they were designed to sit in the same system.

ACP: the same lane, converging

The Agent Communication Protocol came out of IBM Research and its BeeAI framework, also under the Linux Foundation, and it lives in the same enterprise horizontal lane as A2A — with a different design accent.

Where A2A leans on JSON-RPC, ACP is REST-first over plain HTTP, which makes it feel familiar to anyone who has ever built a web service. Messages are MIME-typed multipart payloads, so a single message can carry text, an image, and a structured blob together, each part labeled with its content type. It supports both synchronous and asynchronous interaction, aims to be lightweight and runtime-independent, and is explicitly local-first: an ACP agent can run and be discovered without phoning home to any cloud.

But here is the fact that resolves the “A2A vs ACP” question outright. In August 2025, the two projects announced they are merging under the Linux Foundation. The enterprise lane is consolidating rather than fragmenting. So when you weigh ACP against A2A today, you are not really choosing between two futures — you are watching two designs fold into one governed standard for enterprise agent collaboration. The practical takeaway: bet on the A2A/ACP convergence as a single thing, not as a fork.

ANP: the horizontal taken to its limit

Push the openness dial all the way to the right and you arrive at the Agent Network Protocol — an open-source community project with an unapologetic ambition: to be “the HTTP of the agentic web.”

A2A and ACP assume a governed world. Even across vendors, there is usually a contract, a shared identity provider, some directory you can consult. ANP throws that assumption away. It targets a fully decentralized world where two agents from organizations that have never met, with no central authority between them, still need to find each other, prove who they are, and cooperate. That is a strictly harder problem, and it forces strictly heavier machinery.

For identity, ANP uses W3C Decentralized Identifiers — specifically the did:wba method, which is web-based: it resolves identity over ordinary HTTPS and DNS rather than a blockchain. An agent controls its own identifier and can prove ownership cryptographically, with no registrar to ask permission from. For describing capabilities, ANP uses JSON-LD with schema.org vocabulary, so an agent’s self-description is machine-readable semantically — a stranger’s agent can parse not just the shape of the data but its meaning. Put together, this yields trustless, cross-organization discovery and authentication with no central directory at all.

That decentralization is the reason ANP sits furthest out on the adoption curve. The open agentic web it is built for does not fully exist yet, so ANP is more frontier than default. But it is the natural endpoint of the horizontal axis: when the world is maximally open, you need decentralized identity and semantic self-description, and ANP is the protocol reaching for exactly that.

The path most teams will actually walk

Lay the four on a timeline of adoption and a clean sequence appears, because each one becomes necessary only when the previous problem is solved.

You start with MCP, because before an agent can collaborate it has to be useful, and usefulness means tools. Wire your agent to its database, its files, its prompt library. This is where almost everyone begins, and for many systems it is the only protocol they will need for a long time.

Then you reach A2A (and, as it converges, ACP) when one agent stops being enough — when a task naturally splits across specialists from different teams or vendors and they need to discover each other, delegate, and track work without exposing their internals. This is the enterprise collaboration layer, and it is the one maturing fastest right now.

Finally there is ANP, waiting at the open frontier for the day agents routinely transact with strangers across organizational lines on a public agentic web. That world is still arriving, so ANP is the protocol you watch rather than the one you ship — for now.

If you remember one sentence, make it this: MCP and A2A are emerging as the dominant complementary pair — vertical and horizontal, tools and teammates — and the other two are the same horizontal axis seen at different distances. ACP is folding into the enterprise end; ANP is staking out the open end. There is no war here. There is a stack, and these four acronyms are simply different floors of it.