What Is pilotprotocol.network? A Field Guide to the Internet for Agents

A domain shows up in your terminal, your group chat, or a GitHub README you're skimming: pilotprotocol.network. Maybe someone pasted it as the answer to "how do I connect my agents across machines?" Maybe you saw it in a talk slide and typed it into a search bar to figure out what it actually is.

Before you curl it blind or file it under noise, it's worth two minutes to know what you're looking at. This is a field guide to pilotprotocol.network: what the project behind the domain does, what you'll actually find on the site, and how to verify it yourself without taking anyone's word for it.

What Is pilotprotocol.network?

pilotprotocol.network is the official site of Pilot Protocol — an open-source overlay network built specifically for AI agents. The landing page's one-liner is "the internet for agents," and the domain is where the project documents what that claim actually covers:

• Addressing. Every agent gets a permanent virtual address that survives restarts, IP changes, and moving between clouds. Your agent's address is its identity, not its current location.
• Transport. Encrypted UDP tunnels using X25519 key exchange with AES-GCM, plus userspace reliability on top of UDP.
• NAT traversal. STUN, hole-punching, and a relay fallback, so agents sitting behind home routers, office firewalls, or cloud NAT are reachable anyway.
• Trust. An explicit per-peer handshake. Two agents must mutually approve before anything flows — joining the network and trusting a specific peer are separate decisions, which is a deliberate departure from the VPN model where "joined" implies "trusted."
• Discovery. A rendezvous registry and nameserver let you find agents and capabilities by name or tag.
• An app store. Installable, agent-native capabilities that run locally on your daemon as typed IPC services — JSON in, JSON out.

The implementation is Go with zero external dependencies (stdlib only), open source under AGPL-3.0, with the source on GitHub. The network counts 243k+ agents and users, and SDKs exist for Go, Python (pilotprotocol on PyPI), Node, and Swift, plus an MCP server (pilot-mcp).

What's Actually on the Domain

The site is deliberately small — the kind of page you can read in one sitting. That's not an accident: the site is written to be readable by both humans and agents. Here's the map:

• The landing page. The one-liner, what the project does, and the install command front and center.
• /docs. The documentation: concepts, the CLI, the SDKs, the app store, the trust model.
• /publish. The page for builders — the process for turning an existing app or API into an agent app.
• /plain. A plain-text version of the site, designed to be fetched and parsed by agents rather than rendered in a browser.

If you hit the domain with a search operator like site:pilotprotocol.network, those are the pages you'll find. For a project this young, the whole public surface fits on one screen.

The App Store: Discover, Install, Call

The part of the site that gets the most attention right now is the app store — it's Pilot's main push. The model is simple: capability apps run locally on your daemon, auto-spawned when you install them, and you talk to them over typed IPC with JSON in and JSON out. The loop is three commands:

pilotctl appstore catalogue          # discover what's available
pilotctl appstore install <id>       # install an app
pilotctl appstore call <id> <app>.<method> '<json>'   # call it

Every app exposes a <app>.help convention, so an agent can discover what a freshly installed app does at runtime instead of reading a README. Apps include AEGIS (a runtime firewall for agents — prompt-injection and jailbreak defense), cosift (grounded web search that returns JSON), sixtyfour (people and company intelligence), miren (deploying apps from an agent), plainweb (web page to clean markdown), and wallet (on-overlay USDC), among others.

For builders, /publish is the entry point: describe your app, verify an email, and the project generates and signs an adapter for it. The pitch is "bring your existing app or API; agents do the rest" — every published app is a new reason for agents to be on the network.

Reading the Site as an Agent

One detail worth knowing if you're building agent tooling: the site serves a plain-text version at /plain specifically so agents can read it without a browser. A fetch-and-extract pipeline that chokes on a marketing page can just grab that instead:

curl -s https://pilotprotocol.network/plain

That's an unusual thing for a project website to ship, and it's consistent with the audience: the docs are written for developers building with agents, not for a marketing funnel.

Verify It Yourself

Everything above is checkable in about five minutes, and you should check the parts you care about. The full source is on GitHub at github.com/pilot-protocol — you can read the transport, the trust model, and the app-store signing before you ever install anything. The install script is a one-liner, so a throwaway sandbox is a cheap way to kick the tires:

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

If you're evaluating it for real, the order I'd suggest: skim the pilotprotocol.network landing page, read the docs section that matches your use case, then glance at the source before installing. Nothing on the site requires you to trust a black box.

Where It Sits in the Agent Stack

To be clear about scope: Pilot Protocol is not competing with MCP, A2A, or ACP in the way those compete with each other. MCP is about giving agents a standardized tool interface; A2A and ACP are about agent-to-agent conversation protocols. Pilot is the layer underneath those — persistent connectivity, addressing, and trust between agents, plus a distribution channel for agent-native apps. You can run MCP over it; the projects are complementary rather than rivals.

The honest caveat is the usual one for young infrastructure: the network is growing, but it's not the default choice yet, and whether it's worth adopting depends on whether your agents actually need persistent, cross-network connectivity. If they do, that's the problem it's built to solve — and now you know what's behind the domain.