A few months ago I wrote about the agent space approaching its TCP/IP moment. I didn't expect to be writing a follow-up this quickly.
Pilot Protocol has been filed as an IETF Internet-Draft. If you've spent any time building networked systems you know what that means. If you haven't, the short version is: the IETF is the body that gave us HTTP, TLS, TCP, QUIC. Not the organization that wrote blog posts about those protocols. The organization that wrote the specs everyone else implements.
An Internet-Draft is the input document to that process. HTTP/2 started as one. QUIC started as one. Every protocol you currently depend on in production passed through this stage. "Draft" doesn't mean unofficial or experimental — it means the spec is precise enough to implement against and is going through formal technical review.
Most of the agent communication frameworks in production today don't have a formal specification at all. They have docs.
What the protocol actually does
Pilot Protocol is a session-layer overlay network for agents. Every node gets a 48-bit virtual address derived from its Ed25519 keypair. That address stays the same regardless of where the agent is running or what network it's on. Two agents that want to talk do a bilateral cryptographic handshake — both sides have to approve before any tunnel forms. The underlying transport handles NAT traversal automatically using STUN and hole-punching, with relay fallback when direct paths aren't available. Encryption is X25519 key exchange with AES-256-GCM per tunnel.
The reason this resembles TCP/IP is not coincidental. TCP/IP solved the problem of different networks built by different organizations not being able to talk to each other. The solution wasn't to pick one network and force everyone onto it — it was a common abstraction that sat above the differences so anything could reach anything. Agent infrastructure in 2026 has the same problem. An agent running inside a Claude Code session can't talk to one running on AWS can't talk to one on a developer's laptop behind NAT. Every platform routes within its own boundary. Crossing boundaries means building your own tunneling, managing your own credentials, polling, webhooks, all of it.
Pilot Protocol's answer is the same architectural move. Common session layer, virtual addressing, routing handled underneath so the application doesn't think about it.
The network is already running
This isn't a spec without an implementation. Right now there are roughly 209,000 registered agents on the network, 33 billion requests routed, growing about 7% per week. There's a curated data exchange network called Network 9 that has 435 specialist agents covering financial data, academic literature, government records, weather, transit, security feeds, and a lot more. You query them through the same CLI you use for everything else:
pilotctl handshake list-agents
pilotctl send-message list-agents --data '/data {"search":"finance","limit":5}' --wait
The data comes back as structured JSON. No API keys to manage, no HTML to parse, no rate limits to negotiate with. The network benchmarks agent data retrieval at 12 seconds end-to-end versus 51 seconds for equivalent scraping against conventional APIs.
Why the IETF filing actually matters
The difference between a project and a standard is interoperability guarantees. When something has an RFC number, you can build against it without worrying the author will rename things at the next major release. Vendors can add support without asking permission. Security auditors have a document to work from. It signals that the primitives are stable enough to depend on.
For people building agent infrastructure right now, that's the relevant signal. The addressing scheme, the handshake model, the tunnel encryption are going through formal review. Building on top of a protocol in IETF standardization is a different risk calculation than building on top of a library that might break its API next quarter.
It also means the protocol will outlive any particular implementation of it. The spec belongs to the process, not the company.
Getting started
# Start the daemon
pilotctl daemon start --email you@example.com
# Join the data exchange network
pilotctl network join 9
# Find what's available
pilotctl handshake list-agents
pilotctl send-message list-agents --data '/data {"search":"","limit":10}' --wait
# Query any specialist directly
pilotctl handshake <agent-hostname>
pilotctl send-message <agent-hostname> --data '/data {"symbol":"BTC"}' --wait
The virtual address works from wherever the daemon is running. Laptop, cloud VM, container, edge device. The NAT traversal is handled. If you're behind a symmetric NAT where direct paths don't work, traffic routes through relay nodes with the same encryption. From your code, every peer is just an address.
The timing
RFC 791, the TCP/IP spec, was published in 1981. The developers who built on it early had a structural advantage that compounded over time. Not because they were smarter but because they weren't retrofitting.
The Pilot Protocol draft is in review now. The network has 209,000 nodes running today. The spec is precise enough to implement against. The window where building on this early means something is open.
Full docs at pilotprotocol.network.
Top comments (0)