Agent Connectivity Best Practices: Why AI Agents Need a Network Stack

Remote AI agents need a deliberate network layer because application protocols do not, by themselves, make an endpoint reachable across laptops, private clouds, office networks, and organizational boundaries. Google's A2A defines task and message semantics across declared agent interfaces. Anthropic's MCP defines local stdio and remote Streamable HTTP transports for tool access. Frameworks such as LangChain, CrewAI, and AutoGen still depend on the deployment to provide addressing, routing, authentication, and reachability.

It is not.

So the first agent connectivity best practice is this: treat the network as a first-class part of your agent architecture, not as plumbing you can bolt on later. We are repeating the mistake the internet made in the 1990s, when every application built its own networking layer because TCP/IP was not yet universal. The agent ecosystem needs its own TCP/IP moment: a shared network layer that handles addressing, reachability, encryption, and trust, so that application-layer protocols can focus on semantics instead of plumbing.

The HTTP Assumption

Many remote agent interfaces are exposed through HTTP, HTTPS, or gRPC. Those protocols work well once the caller can route to the advertised endpoint. They do not determine how a private endpoint behind NAT becomes reachable or how its address survives a move between environments.

A2A publishes Agent Cards at well-known locations. A card declares one or more interfaces where the agent can receive tasks. Those interfaces may sit on the public web, a private network, or another routable environment; the application protocol does not create that route.

MCP defines stdio for local subprocesses and Streamable HTTP for remote servers, while allowing custom transports. A remote MCP client still needs a route to the server endpoint and an authorization model appropriate for that deployment.

The problem is not with these protocols -- they solve real problems at the application layer. The problem is with the assumption underneath them.

NAT is a normal condition of the real internet. Home routers, office firewalls, mobile carriers, and cloud egress paths translate addresses. An agent behind NAT cannot accept an unsolicited inbound connection unless the deployment supplies a mapping, proxy, relay, outbound tunnel, or traversal mechanism.

The standard workarounds -- reverse proxies, ngrok tunnels, cloud hosting, Cloudflare Tunnels -- all add complexity, cost, and fragility. They turn a networking problem into a deployment problem, and they make every developer solve the same problem independently.

The Identity Crisis

Agent identity is in worse shape than agent connectivity.

In the current ecosystem, agents typically authenticate using one of three mechanisms: API keys, OAuth tokens, or mutual TLS certificates. Each has severe limitations in an agent-to-agent context.

Shared API keys are still the default for agent-to-agent communication. A shared API key does not identify a specific agent -- it identifies an account, a project, or an organization. When an incident occurs, there is no way to trace it to the specific agent that caused it. When a key is compromised, every agent using that key is compromised.

The scale of the problem keeps growing. Non-human identities -- agents, service accounts, API keys, bots -- already outnumber human identities in enterprise environments. Each one needs its own identity. The old model of a human administrator manually provisioning and rotating credentials does not scale to fleets of autonomous agents.

What is useful is a system where every agent has a unique cryptographic identity that it controls and can prove to a peer. In Pilot, this begins with the Ed25519 key pair generated during pilotctl init. The node retains its private key and uses signatures during identity and trust operations; registry and enterprise identity controls remain separate parts of the deployment.

The Quadratic Explosion

A full mesh grows quadratically regardless of transport. The engineering question is how many peer relationships are actually required and how each active path is addressed, secured, observed, and recovered.

If you have N agents that need to communicate with each other, you need N x (N-1) / 2 pairwise connections. The mesh grows quadratically: a handful of agents is a small graph, but every added agent multiplies the number of links the system has to maintain.

With HTTP, each of these connections involves:

• TCP handshake -- multiple round trips before any payload flows
• TLS handshake -- additional round trips for certificate exchange and key agreement
• HTTP negotiation -- protocol version, headers, authentication
• Keep-alive management -- idle connection timeouts, reconnection logic
• Certificate management -- each agent needs a TLS certificate, trusted by every peer

A Pilot Protocol agent maintains a single UDP socket. All connections are multiplexed over this socket using virtual addresses and port numbers. The tunnel layer handles encryption once per peer, not once per connection. Any number of connections to any number of agents share the same UDP port, the same tunnel, and the same encryption key per peer.

An HTTP deployment can reuse persistent connections and connection pools. Pilot takes a different approach: one UDP socket carries traffic for multiple peers, while a peer tunnel can multiplex multiple logical streams. Both designs still need sensible topology and lifecycle management; Pilot moves those concerns below the application protocol.

Separate Transport Overhead From Model Context

It is important not to conflate network overhead with model-token usage.

HTTP exchanges carry headers and application framing, while a fresh connection may also incur transport and cryptographic setup. Persistent connections can reuse established paths and can make bidirectional streaming easier. These are network and application-latency considerations.

Model context is different. HTTP can support stateful applications, and a persistent tunnel does not automatically reduce the tokens sent to a model. Token usage depends on the application protocol, memory design, prompts, and whether agents exchange full histories or compact deltas.

Pilot connections maintain transport state such as sequence numbers, acknowledgments, and flow-control windows. Applications may use that persistent path to exchange compact events or deltas, but the application remains responsible for conversation state and model context. For a comparison of connection patterns, see persistent connections for agents.

This separation matters during architecture reviews: measure connection setup, framing, delivery behavior, and model tokens independently instead of attributing every coordination cost to the transport.

What a Network Stack Gives You

A proper network stack for agents solves five problems simultaneously:

Permanent Addresses

Every initialized node gets a 48-bit virtual address that remains stable while its identity state is retained, even when the underlying IP changes or the node moves between machines. This decouples the agent-facing address from a particular network endpoint.

See the addressing section of our architecture deep dive for the full technical details.

NAT Traversal

The network stack handles STUN discovery, hole-punching, and relay fallback automatically. The agent developer never thinks about NAT types, port mappings, or firewall rules. An agent behind a home router communicates with an agent behind a corporate firewall as easily as two agents on the same LAN.

Tunnel Encryption

Tunnel encryption is enabled by default using X25519 key exchange and AES-256-GCM. There are no certificates to manage. The key exchange happens automatically when tunnels are established, and encrypted packets are authenticated and integrity-checked. An explicit plaintext override exists for controlled testing, not production profiles.

Trust Model

Agents are private by default at the application connectivity layer. Directory metadata may remain visible, but open lookups withhold private endpoints and private nodes reject application traffic without peer trust or applicable shared-network membership. Peer trust can be revoked.

For a deep dive into why this matters, read Why Agents Should Be Invisible by Default.

Port-Based Services

The network stack provides well-known port numbers for common services: echo (7), data exchange (1001), pub/sub events (1002). Applications build on these services instead of reinventing message passing and event distribution. This same port-based architecture works for everything from drone and robot swarm communication to cloud-free smart home device networks.

Agent Connectivity Best Practices

If you are designing a multi-agent system today, these are the agent connectivity best practices that separate systems that survive production from demos that only work on a laptop:

Give every agent a durable identity and address

Address the agent, not a transient process endpoint. An IP address can change when an agent restarts, moves clouds, or shifts onto another host. A retained virtual identity decouples "which node is this" from "where is it running now."

Assume NAT, and build traversal in from day one

Do not design for a world where every agent has a public IP. Agents often live behind a home router, office firewall, or cloud egress path. Decide explicitly whether the deployment will use a proxy, private network, outbound tunnel, direct traversal, relay fallback, or some combination of them.

Encrypt the tunnel, not just the payload

TLS and encrypted overlays both protect payloads while leaving some transport metadata visible to the systems carrying the traffic. Pilot places X25519 key agreement and AES-GCM payload protection at the tunnel layer, so multiple application protocols can share the same encrypted peer path without each application managing certificates at that layer.

Decouple membership from trust

Flat-network deployments can treat membership as broad reachability, although modern private networks may add detailed policy. For agents, keep membership, discovery, and authorization as distinct decisions. Pilot peer trust uses a bilateral handshake, while managed-network policy can further constrain relationships.

Keep connections stateful

Persistent connections avoid repeated connection setup and support ongoing bidirectional exchanges. They do not choose what model context an application sends. Design the application protocol to send the minimum state required, and measure network overhead separately from model usage.

Standardize the service layer

Every agent team ends up reinventing message passing and event distribution. Well-known service ports (echo, data exchange, pub/sub) give agents a shared vocabulary for common capabilities, so applications build on a stable service layer instead of bespoke protocols. It is the same move the internet made when it standardized on TCP/IP and DNS: a shared foundation lets everyone innovate above it.

These practices are exactly what Pilot Protocol implements as its core: permanent virtual addresses, automatic NAT traversal, encrypted tunnels, per-peer trust, stateful connections, and well-known service ports -- in a single Go daemon with no external dependencies. The fastest way to see them in practice is the five-minute multi-agent network tutorial, or the plain-language primer on what Pilot Protocol is.

The Tailscale Analogy

The best analogy for what Pilot Protocol does for agents is what Tailscale did for humans.

Before Tailscale, connecting to resources on a private network required VPN configuration, firewall rules, certificate management, and ongoing operational overhead. Tailscale did not replace HTTP or SSH or any application protocol. It made them work in places they could not before -- behind NAT, across cloud providers, from mobile devices.

Pilot applies a related pattern to AI agents. It does not replace A2A, MCP, or another application-layer protocol. It supplies addressing, reachability, encrypted peer paths, and connectivity controls beneath those protocols.

Consider the architecture that becomes possible:

• A2A for semantics -- Agent Cards, task delegation, capability matching -- running over Pilot Protocol tunnels instead of public HTTP endpoints
• MCP for tool access -- tool servers that agents connect to over the overlay network, reachable even behind corporate firewalls
• LangChain/CrewAI for orchestration -- agent frameworks that use Pilot addresses instead of URLs, with automatic NAT traversal and encryption

The application-layer protocol handles what agents say to each other. The network stack handles how they reach each other. These are different problems, and they deserve different solutions.

The Missing Layer

The agent ecosystem has built impressive application-layer capabilities. Agents can reason, plan, use tools, generate code, analyze data, and coordinate complex tasks. What is missing is the infrastructure layer that makes these capabilities accessible across network boundaries.

Every time a team separately implements NAT traversal, peer addressing, tunnel encryption, and discovery for each application protocol, it creates another networking surface to operate. Application-level delivery guarantees and business retries still belong above that network layer.

The internet works because the network layer is shared. Everyone uses TCP/IP. Everyone uses DNS. The application layer can innovate because the transport layer is stable and universal. Agents need the same foundation.

Pilot Protocol is a proposal for what that foundation looks like: permanent addresses, encrypted tunnels, automatic NAT traversal, cryptographic trust, and port-based services. The core daemon is a static Go binary with no external runtime dependencies. It is one of several agent networking approaches worth evaluating -- see the honest architecture comparison in Pilot vs Tailscale vs Nebula vs ZeroTier for AI Agents, and the broader AI networking best practices guide for the security side of the same coin.

Getting Started

If this argument resonates, the best next step is to try it. Pilot Protocol is open source (AGPL-3.0), written in Go, and available through a single-command installer. Its core daemon is distributed as a static binary on supported platforms.

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

• Evaluate a private agent network -- architecture, controls, and deployment paths for multi-machine agent teams
• Build a multi-agent network in 5 minutes -- hands-on tutorial from install to working demo
• How Pilot Protocol works -- architecture deep dive covering every layer of the stack
• Core concepts -- technical reference for addressing, transport, encryption, and trust
• Integration guide -- embed Pilot Protocol in your existing Go agent applications