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 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 originally introduced by Anthropic that standardizes how an AI host discovers and uses tools, resources, and prompt templates exposed by separate servers. It solves bespoke integration sprawl by giving each server one common interface, while leaving model orchestration, permissions, and user approval to the host.
An AI agent is an application that lets an LLM choose and execute validated tools in a bounded loop, carrying observations and state forward until it reaches a goal or needs approval. A single LLM call produces one response or tool-call proposal and stops; it does not itself provide the loop, live-system access, memory, or side effects.
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.
No. Agent-to-agent authentication identifies the calling agent, but it does not establish that the original user authorized the requested action. Preventing a confused deputy requires verified identity propagation, explicit delegation, and authorization at every hop.