The problem: agents can reason, but can they talk to each other?
If you've built more than one AI agent, you've hit this wall: the model is smart, the tools work, but getting Agent A to talk to Agent B is still glue code. Do you expose a REST endpoint? Wrap it in a webhook and hope the receiving service is awake? Bolt on a message queue? Every team reinvents this, and every reinvention has the same failure modes — NAT, ephemeral IPs, no shared trust model, no discovery.
Over the last two years, a handful of actual agent-to-agent communication protocols have emerged to standardize this instead of leaving it to ad hoc HTTP calls. This post is a practical survey of the main ones — A2A, MCP, ACP, and ANP — what each is actually for, where they overlap, and where a lower-level networking layer like an overlay network fits underneath all of them.
MCP: giving one agent access to tools and context
Model Context Protocol (MCP), from Anthropic, solves a narrower but foundational problem: how does a single LLM-driven agent get structured access to tools, files, and external context in a standard way? An MCP server exposes a typed set of resources and tools; any MCP-compatible client (Claude Desktop, an IDE, a custom agent runtime) can call them without one-off integration code per tool.
MCP is not, strictly, an agent-to-agent protocol — it's an agent-to-tool (and agent-to-data) protocol. But it matters here because a lot of what people call "agent communication" in practice is actually one agent calling another agent as if it were a tool, over MCP. That's a legitimate pattern, and it's why you'll often see an MCP server sitting in front of an actual multi-agent system.
A2A: Google's protocol for agent-to-agent tasks
Agent2Agent (A2A), originated at Google and now under the Linux Foundation, is aimed squarely at the problem MCP doesn't solve: letting independent agents, possibly built by different vendors on different frameworks, discover each other's capabilities and hand off tasks. The core primitives are the Agent Card (a JSON manifest describing what an agent can do and how to reach it) and a task lifecycle (submit, track state, receive artifacts back). It's transport-agnostic in spirit — implementations typically run over HTTP/JSON-RPC or gRPC — and it explicitly does not try to define how the underlying bytes get from one agent's network to another's.
That last point is the recurring theme in this whole space: these protocols define message shape and semantics, not how a packet crosses a NAT boundary to reach an agent that might be behind three layers of container networking. That's a separate, unsolved layer.
ACP: a REST-native alternative from IBM/BeeAI
Agent Communication Protocol (ACP), from IBM's BeeAI initiative, covers similar ground to A2A — capability discovery, multi-agent orchestration, streaming and async responses — but leans on plain REST semantics rather than JSON-RPC, and puts more emphasis on being embeddable in existing HTTP infrastructure without a bespoke SDK. If your organization already has a REST-first platform team, ACP's design choices read as pragmatic rather than novel. The two protocols (A2A, ACP) are converging in places, and there's active discussion in both communities about compatibility rather than head-to-head competition — this is still an early, unsettled space.
ANP: agent-native, decentralized identity
Agent Network Protocol (ANP) takes a more decentralized stance: agents get DID-based (decentralized identifier) identities, and discovery/negotiation happens without a central directory a la traditional service registries. It's the least mature of the four in terms of production adoption, but it's worth watching because it's tackling identity and trust head-on rather than assuming a platform-managed registry — a question every one of these protocols eventually has to answer.
What none of these protocols solve: the network itself
Here's the gap that becomes obvious once you actually try to deploy any of A2A, ACP, or MCP-as-agent-bridge across more than one machine you don't fully control: they assume connectivity already exists. An Agent Card says "reach me at this URL." A REST endpoint assumes the caller can route to it. None of them ship an answer for:
- The receiving agent is behind a NAT/firewall with no public port.
- The agent's IP changes when its container restarts or it migrates clouds.
- You want cryptographic proof of which agent you're actually talking to, not just "whoever answers on that URL right now."
- Membership in a network shouldn't automatically mean trust — "on my VPN" and "I'll accept your task requests" are different questions, and most setups conflate them.
This is the layer an overlay network is built for, and it's a genuinely different concern from what A2A/ACP/MCP define. Pilot Protocol is one implementation of that layer: every agent gets a permanent virtual address that survives IP changes and restarts, traffic moves over encrypted UDP tunnels (X25519 + AES-GCM) with STUN/hole-punching/relay fallback for NAT traversal, and — critically — trust is a separate, explicit step from connectivity. Two nodes can be on the same overlay and still refuse each other's messages until both sides run a mutual handshake. That decoupling matters once you have agents from different teams or vendors on the same network and don't want "reachable" to silently mean "trusted."
Concretely, once two agents have a Pilot address and a mutual handshake, sending a message doesn't care what's happening at the IP layer above them:
pilotctl handshake other-agent-hostname "collaborating on task X"
pilotctl send-message other-agent-hostname --data 'here is the task payload'
That's the same call whether the other agent is on the same LAN, behind a residential NAT, or on a different cloud entirely. You could carry an A2A task payload or an ACP message body inside that --data field — the overlay doesn't care what protocol-level semantics you layer on top, it just makes sure the bytes arrive, encrypted, to the right identity.
Pilot also ships an app store on top of this: installable, agent-native capability apps (JSON in, JSON out) that run locally on your daemon and are called with one command — pilotctl appstore install <app> then pilotctl appstore call <app> <method> '{...}'. It's a complementary idea to MCP servers: instead of your agent hosting the integration, the capability is a signed, sandboxed local process the daemon supervises.
Picking a layer for your stack
If you're standardizing multi-agent communication today, the pragmatic read is: A2A or ACP for task semantics (what does "please do X and tell me when it's done" look like as a message), MCP for tool access within a single agent, and a networking layer underneath for actually getting bytes between agents that don't share a network. These aren't competing choices — they solve different layers of the same stack, and most real deployments will end up using more than one.
Further reading on Pilot Protocol's approach to the networking layer: pilotprotocol.network/blog.
FAQ
Is A2A a replacement for MCP? No — MCP is agent-to-tool, A2A is agent-to-agent task handoff. Many systems use both.
Do I need an overlay network to use A2A or ACP? Not strictly, if all your agents are reachable on a shared network already (same VPC, same cluster). It becomes necessary once agents span networks you don't control — different clouds, different organizations, or devices behind consumer NAT.
Which protocol has the most production adoption right now? A2A and MCP currently see the most real-world usage; ACP is converging with A2A in places; ANP is the earliest-stage of the four.
Does connectivity mean an agent trusts every message it receives? It shouldn't, and this is a design flaw in some ad hoc setups. Pilot Protocol treats trust as a separate, explicit mutual-approval step from network membership — reachable and trusted are not the same thing.
Top comments (0)