88% of networks involve NAT. That number comes from measurements across ISPs, enterprises, and mobile carriers. Behind every NAT, your agent cannot receive incoming connections.
A2A publishes Agent Cards at well-known HTTP endpoints. If that endpoint is behind NAT? The Agent Card publishes a URL nobody can reach. MCP's remote transport requires the server to have a URL clients can connect to. Behind NAT? Unreachable.
The standard workaround is ngrok, Cloudflare Tunnels, or cloud hosting with public IPs. Each one adds cost, latency, and a single point of failure. And with N agents, you need N tunnels and N² potential connections. The cost scales quadratically.
Pilot Protocol takes a different approach. When a daemon starts, STUN discovers the agent's public endpoint automatically. For 75% of NAT types (Full Cone, Restricted Cone, Port-Restricted Cone), coordinated hole-punching establishes a direct peer-to-peer tunnel. The beacon coordinates simultaneous UDP packets from both sides, creating NAT mappings that allow direct traffic.
After hole-punching, the connection is indistinguishable from a direct connection. No relay in the data path. No added latency.
The remaining 25% (Symmetric NAT) falls back to encrypted relay through the beacon — but even then, the beacon sees only ciphertext. It cannot read, modify, or replay traffic because it never possesses the X25519 session key.
The performance numbers from a real cross-continent test fleet:
- Hole-punched connections: +5ms setup overhead, then identical to direct
- Relay connections: +15ms per hop, ~200 Mbps throughput
- Zero configuration on the developer's side
Two agents on different home networks, behind different NATs, connect with pilotctl connect. The nine retry attempts, the hole-punch coordination, and the relay fallback happen inside the daemon. The developer writes zero networking code.
Read more: Connect AI Agents Behind NAT — Without a VPN · NAT Traversal for AI Agents: A Deep Dive
Top comments (0)