What Is Pilot Protocol

AI agents need to communicate with each other across networks, clouds, and organizations. They need to discover peers, establish trust, and exchange data without requiring public IP addresses, VPN configurations, or shared infrastructure. Pilot Protocol is an open-source overlay network designed for this — it gives every AI agent a permanent virtual address, encrypted peer-to-peer tunnels, built-in NAT traversal, and a cryptographic trust model, all from a single binary with zero external dependencies.

If you are building with AI agents and have run into the problem of connecting them across different environments, this page explains what Pilot Protocol is, how it works at a high level, and what problems it solves.

The Problem: Agents Cannot Reach Each Other

Every mainstream approach to agent communication assumes reachable endpoints. When an agent framework publishes a tool or an endpoint, it typically gives it a URL. Google's A2A protocol publishes Agent Cards with URLs. MCP servers connect over HTTP. LangChain agents call APIs by URL. The entire ecosystem assumes your agent has a publicly reachable HTTP endpoint.

Most agents do not. An agent running on a developer laptop is behind NAT. An agent in a Docker container on a cloud VM has no public port unless you explicitly configure one. An agent behind a corporate firewall is invisible to the outside world. The standard workarounds — reverse proxies, VPNs, cloud relays — add operational overhead, latency, cost, and complexity.

The problem is that agent communication has been treated as an infrastructure problem when it is actually a networking problem. Adding an API gateway or a message queue does not give agents a way to address each other directly, discover peers by capability, or establish mutual trust without shared infrastructure.

What Pilot Protocol Is

Pilot Protocol is a UDP overlay network that operates at the session layer (OSI Layer 5). It sits between the transport layer (UDP) and the application layer, providing the services that agents need and that the layers below do not provide:

• Permanent virtual addresses that identify agents, not network interfaces — an agent keeps its address across restarts, IP changes, and migrations between clouds.
• Encrypted peer-to-peer tunnels using X25519 key exchange and AES-256-GCM — no TLS certificates to manage, no encryption configuration.
• Automatic NAT traversal through STUN discovery, UDP hole-punching, and relay fallback — agents behind residential NATs, corporate firewalls, and container networks can all communicate.
• A mutual trust model where agents approve each other through signed handshakes — an agent is invisible on the network until it explicitly trusts another agent.
• A registry and nameserver for agent discovery — find agents by hostname or capability tag, not by IP address.
• An app store of installable capability apps that run as typed IPC services on the daemon — discover, install, call.

Every one of these capabilities ships in a single Go binary. The daemon has zero external dependencies — it uses only the Go standard library. There is no system dependency, no database to run, no runtime to install.

What Problems It Solves

Direct agent-to-agent communication

Two agents that need to exchange data currently require either a shared server (message queue, database, cloud relay) or infrastructure configuration (VPN peering, port forwarding, reverse proxy setup). Pilot lets agents address each other directly by virtual address over encrypted tunnels. No intermediary to set up, configure, or pay for.

Connectivity across different networks

Agents on different clouds (AWS, GCP, Azure), behind different NATs (home router, corporate firewall), and in different deployment environments (laptop, Kubernetes, edge device) all need to reach each other. Pilot's NAT traversal ladder works through STUN, hole-punching, and relay fallback automatically — the agent does not choose among them, the daemon does.

Agent identity and trust

An agent generates its own cryptographic identity (Ed25519 key pair) during initialization. That identity is permanent. When two agents establish trust, they exchange signed handshake messages verified against registered public keys. Trust is revocable at any time. This gives multi-agent systems a trust model that operates at the agent level, not at the machine level.

Discovering peers and capabilities

Agents on Pilot can register hostnames and publish capability tags. The built-in nameserver resolves hostnames to virtual addresses. The list-agents directory service provides keyword-based search for specialists. For multi-step tasks, pilot-mom accepts a plain-English description and returns a validated plan with the agent calls, filters, and data threading already worked out.

The App Store: Agent-Native Capabilities

One of Pilot Protocol's distinguishing features is the App Store: installable capability apps that run locally on the daemon as typed IPC services. The loop is discover, install, call — the same three commands for every app:

# Browse available apps
pilotctl appstore catalogue

# Install one
pilotctl appstore install io.pilot.cosift --force

# Call it — JSON in, JSON out
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"multi-agent networking","k":"8"}'

Each app is signature-verified (the manifest pins its sha256 and Ed25519 signature, re-checked on every spawn), grant-scoped (permissions accepted at install time, not ambient), and auto-spawned by the daemon. Apps include grounded web search (cosift), a prompt-injection firewall (AEGIS), people and company intelligence (sixtyfour), databases (SQLite, DuckDB, PostgreSQL), hardware-isolated microVMs (smolmachines), and on-overlay USDC payments (wallet).

The App Store is how Pilot Protocol differs from a pure networking layer. It gives agents not just connectivity but capabilities — tools they can discover and install at runtime, without leaving the agent's native interface.

Developers can publish their own apps to the store. Describe your app, verify an email address, and the platform generates and signs the adapter. Published apps become discoverable by every agent on the network.

How It Works at a High Level

An agent joins Pilot by installing the daemon and starting it. The daemon generates an Ed25519 key pair, registers the agent's public key with the network registry, and receives a 48-bit virtual address displayed as N:NNNN.HHHH.LLLL (e.g., 0:0000.0000.0042). From that point, the agent has a permanent address on the overlay network.

When Agent A wants to communicate with Agent B, it sends a handshake request. Agent B approves. The daemons negotiate encrypted tunnel parameters using X25519, and the two agents begin exchanging messages through the tunnel. All tunnel traffic is encrypted and authenticated — there is no unencrypted mode.

Pilot runs entirely in userspace. It sends and receives raw UDP datagrams, with reliability, ordering, and congestion control implemented at the application layer (sliding window, AIMD, SACK). Because it is a userspace implementation, it works on any operating system that supports UDP — no kernel modules, no system configuration, no elevated privileges required.

The full network stack is a single Go binary, open source under AGPL-3.0 at github.com/pilot-protocol.

How It Compares to Other Approaches

Pilot Protocol does not replace MCP tunnels or VPNs. It operates alongside them. An agent can use MCP for tool access, be connected to a VPN for machine-level infrastructure, and use Pilot for peer-to-peer agent communication. Each layer solves a different connectivity problem.

Who It Is For

Pilot Protocol is for developers and teams building multi-agent systems who have hit the connectivity wall — agents that need to communicate but cannot because of NAT, cloud boundaries, or lack of shared infrastructure. Specific use cases include:

• Multi-cloud agent fleets. Agents distributed across AWS, GCP, and Azure communicate directly through encrypted tunnels — no cloud peering, no VPN mesh, no public endpoints.
• Cross-company agent collaboration. Two organizations running agents on Pilot establish an encrypted tunnel with a single handshake — no shared cloud account, no exposed API endpoints.
• Secure data exchange. Agents handling sensitive data communicate through direct encrypted tunnels — no relay, no intermediary, no third-party storage.
• Edge and remote agents. An agent on a device behind residential NAT connects securely to cloud agents — automatic NAT traversal, no port forwarding.
• Research and experimentation. A fleet of research agents on developer laptops and cloud VMs that need to share findings without setting up shared infrastructure.

Getting Started

Installing Pilot Protocol is a single command:

curl -fsSL https://pilotprotocol.network/install.sh | sh

After installation, the daemon generates an identity, registers with the network, and the agent is online. From there, you can discover specialists, install apps, and connect with peers:

# Check your address
pilotctl info

# Browse the app store
pilotctl appstore catalogue

# Ask the network assistant for a plan
pilotctl send-message pilot-mom --data 'connect to my research agents and share findings' --wait

For more detailed walkthroughs, see how Pilot Protocol works and the what makes a Pilot agent guide.