What an Agent Network Protocol (ANP) Has to Specify: Addressing, Discovery, Trust, Transport

You've got three agents that need to talk to each other across machines. Different clouds, maybe different vendors, no shared infrastructure to speak of. Before a single message moves, you have to answer four questions: how do they address each other, how do they find each other, how do they know they can trust each other, and how does a message actually get delivered?

Those four questions are what an agent network protocol (ANP) has to specify. Not the agent's logic, not the prompts, not the tool calls — the networking contract between agents. If you've been reading about agent-to-agent communication lately, you've seen the name: Agent Network Protocol (ANP) is an open-source spec that wants to be, in its own words, "the HTTP of the agentic web." This post breaks down what a protocol like that actually has to define, and where the spec ends and the implementation begins.

What an Agent Network Protocol (ANP) Has to Specify

Strip away the marketing and every agent communication protocol ends up specifying the same four layers:

1. Addressing — what an agent is called, and whether that name survives the machine underneath it.
2. Discovery — how one agent learns that another exists and how to reach it.
3. Trust — how two agents establish that they're actually talking to who they think they are.
4. Transport — the wire format, the delivery semantics, and what happens when the network is lossy.

Everything else — message schemas, capability negotiation, conversation state — sits on top of those four. Get one of them wrong and the protocol fails in ways that are painful to debug: agents that can't find each other, handshakes that silently fail, messages that vanish behind NAT.

Addressing: A Name That Survives the Machine

The first thing an agent network protocol has to nail is identity. A human conversation works because "call Alice" resolves regardless of which phone she's holding. Agents need the same property: an agent ID that resolves no matter where the process is running.

This sounds trivial until you've lived the failure mode. You build an agent, give it an endpoint, and every time the container restarts, the IP changes. Every time you move it to another cloud, the hostname changes. If the address is tied to the infrastructure, the network breaks on every deploy. The classic symptom is the webhook URL that stops working after a restart — the endpoint was an accident of the machine, not a property of the agent.

A proper agent network protocol defines an identity layer that is decoupled from the transport endpoint. ANP does this with its own identifier scheme for agents in its distributed network. Overlay networks push the same idea further: each agent gets a permanent virtual address that survives restarts, IP changes, and moving across clouds — the address belongs to the agent, not the box it happens to be running on.

Discovery: How Agents Find Each Other

Identity is half the problem; the other half is that an agent has to learn the identity of the agents it needs to talk to. That's discovery, and it's the bootstrap problem of any network: how does the first message find its target when neither side knows the other exists?

Two mechanisms show up over and over. The first is a rendezvous point: a registry or nameserver that agents register with, and that answers "who is agent X, and where is it reachable?" The second is capability metadata: agents advertise what they can do, so discovery becomes a search ("find an agent that does X") rather than a phone book lookup ("find agent X").

ANP's design centers on a distributed agent network where agents join and become findable by their identifiers. An overlay network gives you the same property as a service: a rendezvous registry plus a nameserver, so you can find agents and capabilities by name or tag instead of hardcoding endpoints. For an agent, discovery isn't a luxury — it's what turns a collection of isolated processes into something that behaves like a network.

Trust: Explicit, Mutual, and Decoupled from Membership

This is the layer most agent protocols get wrong, because it's the one that's actually about people's expectations. Joining a network and being trusted to receive messages are not the same thing. In a VPN, "joined" means "trusted" — one credential gets you into everything. For agents, that conflation is dangerous: you want to talk to some agents on the network, not all of them, and you want the decision to be explicit and revocable.

An agent network protocol has to specify how trust is established. The pattern that survives contact with reality is the mutual handshake: agent A requests a connection with agent B, B explicitly approves (or rejects), and only then does traffic flow. Both sides opt in. Trust is per-pair, not per-network, and it can be revoked by either side.

ANP, true to its HTTP heritage, leans on web-standard auth (signatures, credentials) at the message level. What an overlay network adds is trust as a lifecycle with real commands. pilotctl handshake <peer> sends the request, pilotctl approve <id> accepts one, pilotctl pending shows what's waiting on you. The protocol guarantees the identity (the registry signs the bidirectional trust record once both sides approve), and the agent keeps control of who it talks to.

Transport: Delivery Semantics Under the Message Format

The transport layer is where a protocol's philosophy shows. ANP made a deliberate, pragmatic choice: it rides on HTTP and formats messages as JSON-LD. That's the "HTTP of the agentic web" bet — reuse the most ubiquitous protocol on the planet, and any agent that can speak HTTP can join. It's a reasonable call, and it means ANP agents work behind the same infrastructure the web already runs on.

But HTTP request/response has a mismatch with how agents actually live. Agents are long-lived. They sit behind NAT, on laptops, in home labs, in clouds that don't give them public IPs. A call-style protocol that requires the agent to be reachable at a stable public URL breaks the moment the agent is behind a router. That's exactly the problem that pushed agent infrastructure toward persistent tunnels: instead of asking "how do I make my agent reachable at a URL," you ask "how do I keep a tunnel open that carries messages to me wherever I am."

This is the part of the spec that most protocols deliberately leave to implementations. An overlay network fills it in with encrypted UDP tunnels (X25519 key exchange, AES-GCM encryption), STUN-based hole punching with relay fallback so agents behind NAT are reachable, and userspace reliability on top of UDP. The agent keeps its permanent address; the overlay handles the unglamorous work of making that address reachable from anywhere.

Where an Overlay Network Implements the Spec for You

Here's the honest framing: a protocol spec tells you the vocabulary — the identifiers, the message formats, the handshake rules. Something still has to run the addressing, discovery, trust, and transport. For ANP, the reference implementation is the AgentConnect SDK. For the overlay approach, the implementation is the network itself.

An overlay network for agents — Pilot Protocol is the open-source example, implemented in Go with zero external dependencies — takes those four layers and makes them commands:

pilotctl handshake <peer>              # request a trusted connection
pilotctl approve <id>                  # accept an inbound handshake
pilotctl send-message <peer> '...'     # message over the encrypted tunnel
pilotctl find <hostname>               # resolve an agent by name

No public IPs, no port forwarding, no webhook URL to keep alive. Addressing comes from the permanent virtual address, discovery from the rendezvous registry, trust from the mutual handshake, transport from the encrypted tunnels and NAT traversal. An agent network protocol gives you the contract; the overlay network is what makes the contract true on the actual internet.

FAQ

Is ANP an alternative to MCP? Not really — they operate at different layers. ANP is a communication protocol between agents; MCP is a tool protocol between an agent and a tool server. A system can use both.

Do agents need a protocol at all, or can they just call APIs? Direct API calls work until you need stable identity, discovery, or reachability behind NAT. Those needs are what a protocol layer exists for.

What's the fastest way to try an agent overlay network? Install the CLI and talk to another agent:

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl handshake <peer>

Which layer should I evaluate first? Trust. Addressing and transport can be patched later; a trust model you can't live with means rebuilding the network.

---

If you're spec-shopping for agent communication, read the four layers first: addressing, discovery, trust, transport. ANP is a serious attempt to standardize the vocabulary over HTTP. Just remember the spec is the contract, not the plumbing — an overlay network is what delivers the contract on the real internet.