Every few months a new acronym shows up promising to be the way AI agents talk to each other. Right now the shortlist is MCP, A2A, ACP, and ANP — plus a growing set of overlay-network projects that skip the acronym war entirely and just give agents a network address. If you're building anything with more than one agent in it, you've probably already hit the question this post tries to answer: which agent to agent communication protocol should you actually build on, and for what?
This isn't a "protocol X wins" piece. Each of these solves a genuinely different part of the problem, and picking the wrong one for your use case is how you end up re-architecting six months in. Here's how they actually differ, where each one fits, and where a lower-level overlay network complements — rather than replaces — the protocol layer.
The problem, stated plainly
"Agent communication" quietly means at least three different things:
- Tool invocation — an agent calling a capability (a function, an API, a database) that isn't itself an agent.
- Task delegation — one agent asking another agent to do something and getting a structured result back.
- Transport — how the bytes actually get from one process to another, especially when agents live behind NAT, on different clouds, or restart with new IPs.
Most of the protocol confusion in this space comes from conflating these three layers. MCP solves (1). A2A and ACP mostly solve (2). Almost nothing popular solves (3) well — which is where overlay networks come in.
MCP (Model Context Protocol)
MCP, from Anthropic, standardizes how a model-backed agent discovers and calls tools: read a file, hit a REST endpoint, query a database. It's JSON-RPC under the hood, with a clean discovery mechanism (tools/list) so a client doesn't need hardcoded knowledge of what a server can do.
MCP is not really an agent-to-agent protocol — it's an agent-to-tool protocol. An MCP server is usually not itself an autonomous agent; it's a thin adapter exposing capabilities. That's precisely why it caught on so fast: the scope is narrow and the spec is easy to implement in an afternoon.
Where it falls short for true multi-agent systems: MCP doesn't define agent identity, doesn't handle long-running task lifecycles between peers, and assumes a fairly simple client-server shape rather than a mesh of equal peers negotiating work.
A2A (Agent2Agent Protocol)
Google's A2A protocol targets the gap MCP leaves: agent-to-agent task delegation. It defines "Agent Cards" (a JSON manifest describing an agent's capabilities and endpoint), a task lifecycle (submitted → working → completed/failed), and support for both synchronous and streaming responses.
A2A is a genuine peer protocol — either side can be the initiator — which is the right shape for delegation-heavy systems: a planning agent farming out subtasks to specialist agents, for example. The tradeoff is that A2A still assumes you can already reach the other agent over HTTP. It says nothing about NAT traversal, address stability, or how two agents that have never met establish that the other side is who it claims to be.
ACP (Agent Communication Protocol)
ACP, from the BeeAI/IBM ecosystem, sits close to A2A conceptually — structured multi-agent messaging with defined message types — but leans more toward being embeddable in existing agent frameworks and orchestration runtimes rather than standing alone as an open wire protocol. If you're already invested in a particular orchestration framework, ACP is often the path of least resistance rather than a hard technical differentiator.
ANP (Agent Network Protocol)
ANP is the most ambitious of the four on paper: it explicitly targets internet-scale agent discovery and interaction across organizational boundaries, layering identity (via DIDs) and a meta-protocol negotiation step on top of transport. It's promising precisely because it takes the "agents on the open internet, not just inside your VPC" framing seriously — but tooling and adoption are still early relative to MCP and A2A.
Where they actually converge — and the gap none of them fill
Look past the acronyms and MCP, A2A, ACP, and ANP are all application-layer protocols. They define message shapes, discovery formats, and task semantics. None of them solve the question underneath: how do two agents running on two different laptops, behind two different NATs, on two different cloud providers, actually open a connection to each other reliably, tomorrow, after both of them have restarted with new IP addresses?
In practice, most people paper over this with a central relay server, a message queue, or "just deploy both agents on the same VPC." Those work until they don't: they add a hop you don't control, or they don't work at all for agents that live on someone else's laptop.
This is the layer an overlay network is built for, and it's genuinely a different layer, not a competing standard. Pilot Protocol is one example: it gives every agent a permanent virtual address that survives restarts and IP changes, encrypted UDP tunnels between peers, and NAT traversal (STUN, hole-punching, relay fallback) so agents behind firewalls are still reachable. Trust is a separate, explicit step from connectivity — agents mutually approve a handshake before anything flows, rather than "on the network" implicitly meaning "trusted," the way it does on a typical VPN.
Put concretely: you can run A2A on top of an overlay network. The Agent Card still describes what an agent can do; A2A's task lifecycle still governs how work gets delegated and tracked. What changes is the address in that Agent Card — instead of a brittle IP:port pair that breaks the moment the agent's host changes networks, it points to a stable virtual address the overlay resolves for you.
Pilot Protocol also ships a directory of public service agents you can reach without standing up your own infrastructure at all — genuinely useful when you're prototyping a multi-agent workflow and don't want to run five backend services just to get live weather, finance, or dev-metadata into a demo:
pilotctl send-message list-agents --data '/data {"search":"weather"}' --wait
jq -r '.data' "$(ls -1t ~/.pilot/inbox/*.json | head -1)"
That's the phonebook. Once you know an agent's hostname, send-message again gets you the actual data, no separate API key or account required.
A practical decision guide
If you're deciding what to build on today:
- Wrapping an existing API or tool so an LLM agent can call it → MCP. It's the most mature, most widely supported option for this specific job.
- Building a system where multiple autonomous agents delegate tasks to each other → A2A (or ACP if you're already inside a framework that speaks it natively).
- Reaching agents across organizations on the open internet with identity guarantees baked in → keep an eye on ANP; it's targeting the right problem, tooling is just younger.
- Any of the above, but your agents live on different networks, restart, or move between clouds and you're tired of re-discovering IPs → put an overlay network underneath whichever application protocol you picked. It's not a replacement, it's the plumbing.
The honest takeaway
None of MCP, A2A, ACP, or ANP is "wrong," and none of them is really competing with the others as much as the naming suggests — they occupy different points on the stack, from tool-calling up through cross-organization discovery. The protocol war is mostly still being fought at the application layer. Underneath all of it sits a much older, more boring problem — two processes on two different networks finding and trusting each other — and that's the layer worth solving once, so it stops being a recurring yak-shave every time you add MCP, A2A, or anything else to a project with agents that don't all live in the same datacenter.
Top comments (0)