The problem: agents can talk to APIs, but not to each other
Ask five different AI teams how their agents "communicate" and you'll get five different answers. Some mean an LLM calling a tool via MCP. Some mean a supervisor orchestrating sub-agents in-process. Some mean two independently-built agents, on different infrastructure, negotiating a task end to end. That last case — genuine agent-to-agent communication — is the hard one, and it's the one most of today's protocol proposals are trying to solve.
This post is a survey of where things stand: A2A, ACP, ANP, and MCP — what each one actually covers, where they overlap, and where an overlay network fits into the picture instead of competing with them.
MCP: solved the tool problem, not the agent problem
Model Context Protocol gives an LLM a standard way to call a tool or read a resource — a database, a file system, a search API. It's had massive adoption because the problem it solves (structured tool access) is universal and the spec is simple: JSON-RPC over stdio or HTTP.
But MCP's model is single-directional: a host (the LLM app) talks to a server (the tool). There's no concept of two peer agents, each with their own goals and state, negotiating a multi-step task together. That's a different problem, and it's why a second wave of specs showed up specifically to address agent-to-agent, not agent-to-tool.
A2A: task-oriented agent collaboration
Google's Agent2Agent (A2A) protocol targets exactly that gap. Agents publish an "Agent Card" — a JSON document describing their skills, endpoints, and auth requirements — and other agents discover and negotiate tasks against that card over HTTP, with support for streaming updates and long-running async tasks. It's opinionated toward enterprise workflows: one agent delegating a defined task to another and tracking it to completion.
A2A is a real step toward interoperability between agents built by different vendors, and its task lifecycle model (submitted → working → input-required → completed) is genuinely useful for anything that isn't a single request/response exchange.
ACP: a lighter, REST-native alternative
The Agent Communication Protocol (ACP), originally from IBM/BeeAI and now under the Linux Foundation, takes a similar goal — structured agent messaging with multimodal payloads and async support — but leans on plain REST semantics instead of A2A's task-object model. If your team already thinks in terms of REST endpoints and wants agent messaging to feel like calling any other web service, ACP's surface is more familiar.
Both A2A and ACP are converging in spirit even if their wire formats differ: describe what an agent can do, structure a message envelope for tasks, support streaming and async responses.
ANP: decentralized identity for the open agent web
Agent Network Protocol (ANP) comes at this from a different angle: instead of assuming agents live inside one company's infrastructure, it borrows DID (Decentralized Identifier) and verifiable-credential concepts from Web3 identity work to let agents from any org discover and trust each other without a central registrar. It's earlier-stage than A2A or ACP, but it's asking the right question for an open, multi-vendor agent internet: how do you establish trust with an agent you've never seen before, run by someone you don't have a business relationship with?
What none of these fully solve: the network layer
Here's the gap all four specs share, MCP included: they describe message formats and semantics, not how two agents actually reach each other on the network. Every one of them assumes you already have working, addressable, reliable transport — an HTTP endpoint that's up, reachable, and not sitting behind three layers of NAT.
In practice that assumption breaks constantly. Agents run on laptops, on ephemeral containers, on someone's home server behind a residential NAT, or bounce between cloud providers. Getting a stable, reachable endpoint usually means: a public IP or load balancer, a webhook you have to keep alive and re-register on every restart, or a tunneling tool bolted on as an afterthought. None of the messaging-layer protocols above address it, because it's not their job.
This is the layer Pilot Protocol is built for — not another message-format proposal, but the plumbing underneath one. Pilot is an open-source overlay network (Go, AGPL-3.0, no external dependencies) that gives every agent a permanent virtual address that survives restarts, IP changes, and moves between clouds. Transport is encrypted UDP (X25519 key exchange + AES-GCM) with STUN, hole-punching, and relay fallback for NAT traversal, so two agents on opposite sides of the internet can reach each other without either one opening a port. Trust is a deliberate, per-peer handshake — both sides mutually approve before a tunnel goes live — which matters for the same reason ANP's DID-based trust model matters: on an open agent network, being reachable and being trusted have to be separate decisions.
Concretely, that looks like:
pilotctl handshake <peer-hostname> "collaborating on task X"
pilotctl trust # confirm the handshake was mutually approved
pilotctl send-message <peer-hostname> "here's the task payload"
You could run A2A's task negotiation, ACP's REST messages, or a raw MCP call over that tunnel — Pilot doesn't compete with the message format, it makes sure the two endpoints can find and trust each other in the first place. Pilot also ships a directory of public service agents (finance, weather, dev metadata, and more) reachable the same way, plus an app store of installable capability apps — JSON-in/JSON-out services you discover, install, and call locally with pilotctl appstore catalogue / install / call, without standing up your own server for every integration.
Where this leaves you
If you're picking a message format today: A2A and ACP are the two live options depending on whether you prefer a task-object model or REST semantics, and ANP is worth watching if decentralized, cross-org trust is your actual problem. MCP remains the right tool for agent-to-tool, not agent-to-agent.
Whichever you pick, none of them get you out of the reachability problem — the NAT traversal, the stable addressing, the webhook babysitting. That's a separate layer, and it's worth treating it as one rather than re-solving it inside every new agent you ship. Read more on the Pilot Protocol blog for deeper dives into the overlay network and app-store model.
FAQ
Is A2A the same as MCP? No. MCP connects an LLM host to tools/resources. A2A connects two independent agents for task delegation and negotiation.
Do I need ANP if I'm already using A2A? Not necessarily — ANP addresses decentralized identity/trust across organizations without a central registrar, which A2A doesn't solve on its own. If all your agents live inside one org's infrastructure, this matters less.
Does an overlay network replace A2A/ACP/MCP? No — it sits underneath them. Pilot Protocol provides addressing, encrypted transport, and trust between peers; you still choose a message format on top of that connection.
Can I self-host Pilot Protocol? Yes — the daemon is open source (Go, AGPL-3.0) with no external dependencies, so you can run your own node rather than depend on a third party.
Top comments (0)