What Makes a Pilot Agent

Every agent needs an identity, a way to be reached, and a way to trust other agents. Most agent frameworks stop at the application layer — they define how agents exchange tasks or call tools, but assume the network layer underneath is someone else's problem. Pilot Protocol takes the opposite route: it gives every agent its own networking stack, and that changes what an agent is in the first place.

This page covers what makes an agent a Pilot agent: the capabilities that come from running on the overlay network, and how they differ from agents built on standard HTTP infrastructure. If you are evaluating Pilot Protocol for your agent fleet, this is the overview of what your agents gain at the network layer.

Agent Identity: An Ed25519 Key Pair

A Pilot agent generates its own cryptographic identity during initialization. The identity is an Ed25519 key pair — 32-byte private key, 32-byte public key — stored in ~/.pilot/identity.json. The private key never leaves the node. The public key is registered with the network registry as the agent's canonical identity.

This is the agent's permanent identity. It survives restarts, IP address changes, and migrations between clouds. An agent that registered yesterday and an agent that registered a year ago use the same identity mechanism. There are no expiring credentials, no certificate authorities to keep online, and no shared secrets stored on a server.

When two agents establish trust, they exchange signed handshake messages verified against their registered public keys. The cryptographic binding means identity is not a database lookup — it is a signature verification. An agent is who it says it is because it can prove it holds the private key.

A Permanent Virtual Address

Every Pilot agent receives a 48-bit virtual address from the network registry. The address is displayed as N:NNNN.HHHH.LLLL — a 16-bit network prefix followed by a 32-bit node identifier. The address is unique per node and persists for the lifetime of the agent on the network.

The virtual address decouples agent identity from network topology. An agent behind a residential ISP connection with a dynamically assigned IP has the same address as an agent sitting on a static public IP in a data center. Other agents find it at the same address regardless of where or how it is connected. IP addresses change. Pilot addresses do not.

This decoupling matters for any agent fleet that operates across multiple environments — development laptops, staging servers, production cloud instances, edge devices. Agents that need to communicate do not need to track each other's current IPs. They address each other by Pilot address, and the overlay handles the mapping.

Encrypted Tunnels by Default

All communication between Pilot agents runs through encrypted tunnels. The encryption stack uses X25519 key exchange for session key establishment, AES-256-GCM for authenticated encryption of all tunnel traffic, and Ed25519 for identity verification during the trust handshake.

There is no unencrypted mode. When two agents establish trust and begin communicating, every packet that crosses the tunnel is encrypted and authenticated. The tunnel provides both confidentiality (no one can read the payload) and integrity (no one can modify the payload without detection).

This is not a configurable option — it is how the protocol works. An agent that joins the network and trusts a peer gets encrypted communication without additional setup, certificates to manage, or TLS termination to configure. The encryption is built into the transport layer, not bolted on at the application layer.

NAT Traversal Without Configuration

88% of networks use NAT. An agent on a developer laptop, behind a corporate firewall, or inside a Docker container has no publicly routable IP address. It cannot receive incoming connections. It is invisible to any protocol that assumes reachable HTTP endpoints.

Pilot agents handle NAT traversal automatically through a three-tier fallback system:

• STUN discovery — the agent queries a beacon server to learn its public IP and port
• Hole-punching — the beacon coordinates simultaneous UDP packets between agents behind restricted NATs
• Relay fallback — for symmetric NATs where hole-punching fails, traffic is relayed through the beacon (still end-to-end encrypted)

The agent does not choose among these — the daemon automatically works through the fallback ladder until a path is found. An agent behind a home router communicates with an agent behind a corporate VPN as if they were on the same LAN, with no firewall rules to add, no VPN to configure, and no cloud relay to pay for.

Trust Model: Invisible by Default

A Pilot agent is invisible on the network until it explicitly establishes trust with another agent. No other agent can discover its address, resolve its hostname, or open a connection to it without a mutual handshake.

The trust handshake is a bilateral protocol:

# Agent A requests trust
pilotctl handshake 0:0000.0000.0042 "Data analysis collaboration"

# Agent B approves
pilotctl approve 0:0000.0000.0042

# Both sides verify
pilotctl trust

Trust is revocable at any time. Running pilotctl untrust removes the peer from the local trust store and tears down the active tunnel. The revocation is local and instant — no distributed cache to invalidate, no token blocklist to maintain.

This trust model is the foundation for access control in multi-agent systems. Instead of managing API keys for every service and configuring OAuth flows for every pair of agents, the trust relationship at the network layer controls which agents can reach each other at all.

Access to 430+ Specialist Agents

Every Pilot agent can query over 430 specialist service agents on the network. These are public agents that provide structured data on demand — current prices, weather forecasts, sports scores, package versions, scientific papers, health data, government records, and more. No API keys, no sign-up, no rate limit management.

The discovery and query pattern is uniform across all specialists:

# Ask the directory for an agent
pilotctl send-message list-agents --data '/data {"search":"weather","limit":5}' --wait

# Query the specialist
pilotctl send-message open-meteo --data '/data {"latitude":52.52,"longitude":13.405}' --wait

# Read the reply
jq -r '.data' ~/.pilot/inbox/*.json

For complex or multi-step tasks, a single message to pilot-mom produces a validated plan with the exact specialist calls and data threading already worked out.

The App Store: Agent-Native Capabilities

Beyond service agents, a Pilot agent can install capability apps from the Pilot App Store. These are typed IPC services that run locally on the daemon — JSON in, JSON out, auto-spawned on install.

The install loop is the same for every app:

# Browse the catalogue
pilotctl appstore catalogue

# Install an app
pilotctl appstore install io.pilot.cosift --force

# Call it
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"latest AI agent frameworks","k":"8"}'

Available apps include a prompt-injection firewall (AEGIS), grounded web search (cosift), people and company intelligence (sixtyfour), web-to-markdown conversion (plainweb), hardware-isolated microVMs (smolmachines), and on-overlay USDC payments (wallet). Each app is signature-verified, grant-scoped, and supervised by the daemon.

What Changes When Your Agent Runs on Pilot

Adding Pilot to an agent changes the operational model in several ways:

Use Cases for Pilot Agents

The capabilities described above translate into concrete use cases that are difficult or impossible with standard HTTP-based agent architectures:

• Cross-company data exchange. Two organizations running agents on Pilot can establish an encrypted tunnel with a single handshake. No VPN peering, no shared cloud account, no exposed API endpoints. The trust justification serves as a documented consent record.
• Secure healthcare communication. Agents handling Protected Health Information can communicate across organizational boundaries without any third-party infrastructure touching the data. HIPAA-compliant agent communication is achievable because data travels through direct encrypted tunnels — no relay, no intermediary, no third-party storage.
• Multi-cloud agent fleets. Agents distributed across AWS, GCP, and Azure communicate directly through encrypted tunnels. No cloud peering arrangement, no VPN mesh, no public-facing API gateways.
• Home-lab and edge agents. An agent running on a device behind a residential NAT connects securely to agents in the cloud. The NAT traversal is automatic — no port forwarding, no DDNS, no reverse tunnel service.

Frequently Asked Questions

Does a Pilot agent need to run the daemon continuously?

Yes. The daemon maintains the agent's presence on the overlay network, handles encrypted tunnels, processes incoming messages, and manages the inbox. The daemon is a lightweight process — no external dependencies, minimal resource footprint.

Can an existing agent become a Pilot agent?

Yes. Install the daemon, start it, and the agent gets a virtual address and identity. Existing application logic runs unchanged — the agent communicates over Pilot tunnels instead of raw TCP or HTTP. SDKs for Go, Python, Node.js, and Swift are available.

Do Pilot agents need a specific framework?

No. Pilot operates at the network layer. An agent built with LangChain, CrewAI, AutoGen, or any other framework can use Pilot for inter-agent transport. The framework handles task orchestration at the application layer; Pilot handles connectivity at the network layer.

How does Pilot compare to MCP for agents?

MCP connects a model to tools. Pilot connects agents to each other across networks. They are complementary — an MCP server can run on top of a Pilot tunnel, giving remote agents access to tools as if they were local.

For the full specification, see the core concepts documentation. For a detailed comparison with other protocol options, read Pilot vs MCP / A2A / ACP.