MCP vs A2A vs ACP vs ANP: the agent protocol stack
Four agent protocols arrived in barely a year — and most takes get them wrong. They aren't competitors; they're layers. Here's how MCP, A2A, ACP, and ANP fit together.
What you'll learn
- Why MCP is vertical (agent to tools) and A2A, ACP, ANP are horizontal (agent to agent)
- What each protocol is, who built it, the transport it uses, and the problem it solves
- How the four stack together — and where the ecosystem is already converging
Before you start
You built an agent. Thanks to MCP, it can reach your database, your APIs, your files. Then a real requirement lands: it needs to hand a task to a different agent — one built by another team, in another framework, maybe at another company. MCP can’t do that. That’s a different protocol’s job.
In barely a year the agent world produced four interoperability protocols, and the internet filled with “MCP vs A2A” hot takes that miss the whole point. They are not competitors. They solve different problems at different layers. Get that one idea and the confusion evaporates.
The one mental model: vertical vs horizontal
There are exactly two directions an agent needs to talk.
- Down, to its tools — databases, APIs, code, files. This is vertical integration, and it’s what MCP does.
- Across, to other agents — delegating work to peers. This is horizontal integration, and it’s what A2A, ACP, and ANP do (three flavours, different scopes).
MCP — the tool layer (the vertical one)
The Model Context Protocol, from Anthropic (November 2024), is a standard way to connect a single agent to external tools, data sources, and prompts. It speaks JSON-RPC over a client-server link: your agent runs an MCP client, each tool exposes an MCP server, and any client can use any server. It’s often called “the USB-C of AI” — one socket, any tool. (The MCP lesson covers it in depth.)
Crucially, MCP says nothing about agents talking to each other. That’s the gap the other three fill.
The agent-to-agent layer — three scopes
All three move work between agents. They differ in how open the world is they’re built for — from inside one enterprise to the open internet.
A2A — Agent2Agent (the enterprise collaborator)
Google’s A2A (April 2025), since donated to the Linux Foundation, lets agents built by different vendors discover each other and delegate tasks. Each agent publishes an Agent Card — a JSON file advertising its capabilities — so a “client” agent can find a “remote” agent and hand it a task, tracked through a lifecycle (pending, in-progress, completed, failed). It runs on HTTP, Server-Sent Events, and JSON-RPC. The agents stay opaque — they collaborate without exposing their internal tools or reasoning. Over 50 vendors (Salesforce, SAP, ServiceNow, MongoDB, and more) backed it on day one, and it’s explicitly designed to complement MCP, not replace it.
ACP — Agent Communication Protocol (the REST-first broker)
IBM Research’s ACP (built around the BeeAI framework, now under the Linux Foundation) takes a REST-first approach: agents expose plain HTTP endpoints and exchange MIME-typed multipart messages, supporting both synchronous and asynchronous calls. It’s deliberately lightweight and runtime-independent, and works local-first — handy when your agents live on the same machine or private network. The headline news: ACP is merging with A2A under the Linux Foundation (2025), so the two enterprise tracks are becoming one.
ANP — Agent Network Protocol (the open, decentralized one)
ANP is the community-built, fully decentralized protocol — its stated
goal is to be “the HTTP of the agentic web.” There’s no central directory.
Agents identify themselves with W3C Decentralized Identifiers (the did:wba
method, which uses ordinary web infrastructure like HTTPS and DNS rather than a
blockchain) and describe themselves in JSON-LD using schema.org vocabulary,
so any agent can find, authenticate, and securely talk to any other across
organizational boundaries — no shared platform required.
Side by side
| Protocol | Built by | Layer | Transport | Identity / discovery | Best for |
|---|---|---|---|---|---|
| MCP | Anthropic | Agent → tools | JSON-RPC, client-server | per-server config | giving one agent tools & data |
| A2A | Google → Linux Foundation | Agent → agent | HTTP, SSE, JSON-RPC | Agent Cards | cross-vendor enterprise agents |
| ACP | IBM / BeeAI | Agent → agent | REST, MIME messages | REST endpoints | local-first, runtime-agnostic |
| ANP | open community | Agent → agent | HTTP, JSON-LD | W3C DIDs (did:wba) | the open, decentralized agent web |
The trap to avoid
The mistake almost everyone makes is treating these as a single bake-off and asking “which one wins?” None of them wins, because they’re not in the same race. The real questions are: Does my agent need tools, other agents, or both? and How open is the world those other agents live in? Answer those and the protocol picks itself.
In one breath
- The four protocols aren’t competitors — they’re layers; “MCP vs A2A” is like “USB vs Wi-Fi.”
- MCP is vertical: one agent down to its tools (databases, APIs, files), over JSON-RPC.
- A2A, ACP, ANP are horizontal: agent-to-agent, differing by how open the world is — A2A (cross-vendor enterprise, Agent Cards), ACP (REST-first, local-first; merging into A2A), ANP (fully decentralized, W3C DIDs, the “HTTP of the agentic web”).
- Adopt in order: MCP for tools → A2A/ACP when agents must collaborate → watch ANP for the open internet; MCP + A2A are the emerging dominant pair.
- Don’t ask “which wins” — ask does my agent need tools, other agents, or both, and how open is their world? and the protocol picks itself.
Quick check
Quick check
Next
You now have the map: MCP plugs in tools, A2A/ACP plug in enterprise agents, ANP plugs into the open agent web. Next, see these ideas in motion in MCP and the agentic design patterns that use them.
Practice this in an interview
All questionsMCP is an open protocol from Anthropic that standardizes how LLM applications discover and connect to external tools, data sources, and prompts through a common client-server interface. It replaces bespoke per-integration glue with a single protocol, so any MCP-compatible host can use any MCP server, and has been adopted across the broader ecosystem.
An agent is an LLM placed in a loop where it reasons, chooses and calls tools or actions, observes the results, and repeats until a goal is met, rather than producing one response and stopping. The key differences are autonomy, tool use, memory and state, and multi-step control flow driven by the model's own decisions.
Use multiple agents when a task decomposes into distinct specialties or parallel subtasks that exceed one agent's context or reliability; avoid it when a single agent suffices, since multi-agent systems add coordination overhead, latency, cost, and error propagation. A supervisor architecture has an orchestrator routing work to specialized sub-agents, while a swarm lets peer agents hand off control to one another without a central coordinator.
A confused deputy occurs when an agent uses its elevated permissions to perform an action on behalf of a less-privileged caller that the caller could not do directly, leading to privilege escalation. The root cause is that a trusted agent acts on natural-language requests, including from other agents, without verifying the originator's authority, so robust systems propagate identity and scope on every hop and enforce access control on agent-to-agent calls.