Picking a network layer for AI agents is a different problem than picking one for microservices. Agents move across clouds, restart on new IPs, sit behind NAT, and need to prove who they are before another agent trusts them with anything. Get this wrong and the failure mode isn't a slow API call — it's an agent that silently can't reach its peers, or worse, one that trusts a connection it shouldn't.
This post walks through what "secure, scalable connectivity" actually means for agent networks, looks at a few real approaches, and shows where an overlay-network design like Pilot Protocol fits.
What to evaluate in an AI agent network
Before comparing frameworks, it helps to fix the criteria. The ones that actually matter in production:
- Decentralization — is there a single broker or hub that becomes a bottleneck or point of failure?
- Identity and addressing — does an agent keep a stable identity across restarts, IP changes, and cloud migrations, or does it get a new address every time it redeploys?
- Communication security — are channels encrypted and authenticated by default, or is that bolted on later?
- Trust model — is "on the network" the same thing as "trusted," or are those two separate decisions?
- NAT traversal — can two agents behind different NATs (common in containerized/cloud environments) actually reach each other without manual port-forwarding?
- Composability — can agents built on different stacks (LangChain, LangGraph, custom runtimes) talk to each other, or is the protocol vendor-locked?
A common mistake is under-engineering this layer — treating agent-to-agent communication as "just another webhook" — until NAT traversal, firewall rules, and rotating IPs break things in production. The opposite mistake, over-engineering with premature abstraction layers, adds latency without solving the actual problem. Neither the plumbing nor the trust model should be an afterthought.
Framework 1: Agent-to-Agent protocols with structured capability descriptors
One well-known approach to agent interoperability is describing each agent's capabilities, endpoints, and auth requirements in a structured document — an "agent card" — that other agents can fetch and parse before initiating a session. Communication typically rides over JSON-RPC on top of HTTP or gRPC, so it layers onto infrastructure teams already run.
This kind of approach is genuinely useful for discovery and capability negotiation — knowing what an agent can do and how to call it before you connect. It complements tool-calling protocols like MCP rather than replacing them: one handles agent-to-agent coordination, the other handles agent-to-tool interaction.
What it typically leaves as someone else's problem: the actual transport. JSON-RPC over HTTP assumes both sides are reachable — it doesn't traverse NAT for you, doesn't give an agent a stable address across IP changes, and doesn't handle key exchange for the underlying connection. Discovery and transport are separable concerns, and it's worth being clear about which one a given protocol actually solves.
Framework 2: Onchain agents
Another direction runs agents inside smart-contract-like compute environments with persistent state and HTTP-accessible endpoints, so agent execution and memory live onchain rather than on infrastructure the operator controls directly. This buys sovereignty and composability with other onchain services, at the cost of tying agent execution to a specific chain's runtime model — a real trade-off depending on whether your agents need to interoperate with Web3-native services or with the rest of your (probably off-chain) stack.
Framework 3: A dedicated overlay network — where Pilot Protocol fits
Pilot Protocol takes a different angle: instead of describing capabilities over HTTP, or moving execution onchain, it gives every agent first-class network citizenship — the same category of primitive Tailscale or Nebula give machines, but designed around how agents actually behave.
Concretely:
- A permanent virtual address per agent that survives restarts, IP changes, and moving across clouds — no re-registering endpoints every time an agent redeploys.
- Encrypted UDP tunnels using X25519 key exchange and AES-GCM, with userspace reliability built on top of UDP, so every agent-to-agent link is authenticated and encrypted by default.
- NAT traversal via STUN, hole-punching, and relay fallback — agents behind NAT (the default for most containerized and cloud deployments) are reachable without manual network configuration.
- A trust model that decouples membership from trust. Being reachable on the network is not the same as being trusted by a given peer — each relationship requires an explicit, mutual handshake. This matters for agent networks specifically: you want new or unknown agents to be discoverable without automatically granting them access to act on your behalf.
- A rendezvous registry and nameserver for finding agents and capabilities by name or tag, rather than hardcoding IPs.
It's implemented in Go with zero external dependencies (stdlib only), is open source under AGPL-3.0, and ships SDKs for Go, Python (pilotprotocol on PyPI), Node, and Swift, plus an MCP server (pilot-mcp) for agents that already speak that protocol.
The app store: capabilities as a install-and-call primitive
The part of Pilot Protocol most relevant to "scalable connectivity" in practice is its app store. Rather than every agent team writing its own HTTP client, auth handling, and retry logic for every external capability it needs, Pilot apps run locally on your daemon as typed IPC services — JSON in, JSON out — auto-spawned on install. The workflow is discover → install → call:
pilotctl appstore catalogue # what's installable
pilotctl appstore install io.pilot.cosift # daemon auto-spawns it
pilotctl appstore call io.pilot.cosift cosift.answer '{"q":"What is HNSW and why use it?"}'
This is a meaningfully different shape than a shared MCP server or a plugin registry: the manifest pins a sha256 and an ed25519 signature that gets re-checked on every spawn, permissions are grant-scoped at install time rather than granted ambient authority, and every app exposes a <app>.help method so an agent can discover its method surface and expected latency at runtime instead of guessing. Live apps in the store today include things like AEGIS (a runtime firewall for prompt-injection and jailbreak defense), cosift (grounded web search and research), sixtyfour (people/company intelligence), and plainweb (web-to-markdown) — capabilities an agent can add with one command instead of standing up its own integration.
Choosing between them
None of these are strictly better across every axis — that's the honest takeaway. A2A-style agent cards are a good fit when the priority is cross-vendor capability discovery over infrastructure you already run. Onchain agent frameworks make sense when composability with Web3-native services and execution sovereignty matter more than integration with your existing cloud stack. An overlay network like Pilot Protocol is the right layer when the actual bottleneck is the network itself — agents that can't reliably find each other, can't traverse NAT, or don't have a trust model that's separate from "is on the network."
In practice these aren't always mutually exclusive: you can run agent cards for capability discovery over an overlay network's transport, and Pilot's own app store treats "who's on the network" and "who do I trust to call" as separate questions for exactly this reason.
If you're evaluating this for a real deployment, the criteria from the top of this post — decentralization, identity stability, encrypted-by-default transport, decoupled trust, and real NAT traversal — are a better filter than any single framework's marketing. Pilot Protocol is currently used by 243k+ agents on the network; you can read the architecture in more depth at Pilot Protocol's overlay network docs.
FAQ
Is Pilot Protocol a replacement for MCP or A2A?
No — it operates at a different layer. MCP and A2A-style protocols describe what an agent can do and how to call it; Pilot Protocol handles the transport underneath: addressing, encryption, NAT traversal, and trust. You can run either on top of an overlay network.
Does an overlay network add latency compared to plain HTTP?
It adds a tunnel-setup step (encrypted UDP), but once established, agents get a direct or relayed path without repeated NAT/firewall negotiation on every request — which is the overhead a lot of production incidents in agent networking actually come from.
What happens if an agent is on the network but I don't trust it?
Nothing — that's the point of decoupling membership from trust. An agent being discoverable via the registry doesn't grant it a tunnel; a mutual handshake is required before any traffic flows between two specific agents.
Top comments (0)