The Missing Layer in Agentic AI: Networking Agents Across Clouds

A new analysis from TechStrong AI argues that agent-to-agent communication requires a dedicated network layer for identity, transport, trust, and reachability, as current solutions like webhooks, VPNs, and MCP servers each address only part of the problem. The piece highlights four core requirements: stable identity, NAT traversal, explicit per-peer trust, and encrypted transport, noting that overlay networks can provide persistent virtual addresses for agents across clouds and private networks.

TL;DR — Key Takeaways - Webhooks, VPNs, tunnels and MCP servers each solve part of the problem, but none provides a complete agent-native networking layer. - Overlay networks can give agents persistent virtual addresses even when IPs change or workloads move across clouds and private networks. - Per-peer trust is critical because agents should not inherit broad access simply because they belong to the same network. - Stable addressing makes agents more disposable and scalable, allowing workers to restart or move without constantly changing orchestrator configuration. - The emerging agentic stack increasingly needs a dedicated network layer for identity, transport, trust and reachability alongside models, orchestration and MCP. You’ve got an agent that calls tools through MCP. It works. Then the next requirement lands: That agent needs to hand work off to another agent running in a different cloud, or in a customer’s environment, or on a laptop behind a home router. Suddenly the hard part of agentic AI isn’t the model — it’s the plumbing. Most teams I talk to hit this wall the same way. They’ve solved how an agent talks to a tool . They haven’t solved how an agent talks to another agent — how two programs that are nobody’s server, with no public IP, no inbound port, and no shared trust anchor, find each other and exchange encrypted messages. This is the networking layer of agentic AI, and it’s the piece most architecture discussions skip. MCP Solved Tools, Not Transport To be clear: MCP has been a genuine unlock https://techstrong.ai/contributed-content/the-mcp-ai-governance-gap-eight-problems-enterprises-are-scrambling-to-solve/ . Standardizing how agents call tools and access data is exactly what the ecosystem needed, and the move toward stateless remote servers makes scaling real deployments easier. None of what follows is an argument against it. But MCP defines a call shape — a client-server contract between an agent and a tool. Something still has to answer at an address. The protocol doesn’t give an agent an identity that outlives its container, it doesn’t get traffic through a NAT, and it doesn’t tell you whether the thing on the other end is one you trust. MCP is the contract between an agent and a tool. The network is the contract between an agent and the world. Agentic systems need both. What Agent-to-Agent Communication Actually Requires When you step back from the frameworks, agent-to-agent communication boils down to four requirements: 1. A stable identity. An address that survives restarts, IP changes, and moving across clouds. Without it, every other agent’s configuration breaks the moment you redeploy — and configuration drift becomes your full-time job. 2. Reachability through NAT. Most agents don’t run on public IPs. They live in VPCs, on laptops, in CI runners, behind carrier-grade NAT. The network layer has to traverse that, with a relay fallback for when hole-punching won’t work. 3. Explicit trust. Membership and trust need to be decoupled. “On the same network” should never equal “can read your files.” Agents need per-peer, mutually approved relationships — not ambient access to everything around them. 4. Encrypted transport. Traffic between agents should not be readable by the infrastructure in between — the cloud provider, the relay, the coffee shop’s Wi-Fi. The Usual Suspects, and Where They Pinch None of the standard answers is wrong; each is just aimed at a different problem. Webhooks work when you can expose a public endpoint. They’re one-directional, they need polling or callbacks, and the URL changes with every deploy. Fine for notifications; weak as a substrate for a bidirectional conversation between two long-lived agents. VPNs solve reachability and encryption, but “joined” equals “trusted” — every node inherits the same ambient access. That’s the wrong granularity for agents that each carry their own identity and permissions. Tunnels the ngrok family get you a public URL fast. They’re session-scoped; the endpoint rotates, and the trust model is “whoever has the URL.” MCP servers are excellent for tool exposure, but the client-server shape doesn’t make two agents peers. Each of these is good at what it’s for. The point isn’t that they’re bad — it’s that none of them is a network layer for agents : stable identity, NAT traversal, per-peer trust, and encryption, as one coherent primitive. The Overlay Network Answer Overlay networks have been solving “reach the thing that has no public address” for years — mesh VPNs, service meshes, SD-WAN. The shift now is applying that model to agents as first-class network citizens. One open-source example is Pilot Protocol https://pilotprotocol.network , an overlay network built specifically for AI agents: every agent gets a permanent virtual address that survives restarts and IP changes; traffic runs over encrypted UDP tunnels X25519 key exchange with AES-GCM ; STUN and hole-punching get you through NAT, with a relay as fallback; and trust is a per-peer handshake that both sides must approve — membership and trust stay decoupled. It’s implemented in Go with zero external dependencies and is open source under AGPL-3.0. More than 243k+ agents and users are on the network today. Where it gets interesting for agentic work is what a network layer enables on top. Once agents are reachable, the useful thing is capabilities — and Pilot ships an app store for exactly that. Apps are installable, agent-native services that run locally on your daemon as typed IPC: JSON in, JSON out. The loop is discover, install, call: pilotctl appstore catalogue what's availablepilotctl appstore install <id one command, signature-verifiedpilotctl appstore call <id <method '<json ' The difference from plugins or MCP tools is worth stating precisely: each app’s manifest pins a sha256 hash plus an ed25519 signature that the daemon re-checks on every spawn; permissions are grant-scoped and accepted at install time, so there’s no ambient authority; and apps auto-spawn under daemon supervision. No browser, no REST plumbing — a tool that lives in your agent’s own runtime. A Concrete Scenario: the Orchestrator That Can’t Reach its Workers The pattern shows up the same way everywhere, so a concrete version is worth walking through. You have an orchestrator agent that plans work and a pool of worker agents that execute it. Workers might be spun up in a cloud region, on a customer’s cluster, or on a developer’s laptop during testing. They have no inbound ports. They have no shared VPN. Their IPs change whenever they restart. With webhooks, the orchestrator would need each worker to expose a public endpoint — so workers become servers, with everything that implies: TLS certificates, inbound firewall rules, a public attack surface. With a VPN, every worker joins one flat trust domain, and “connected” means “can reach everything.” With plain tunnels, the endpoint rotates and the orchestrator needs a registry just to keep track of who’s where. An overlay network collapses this into two steps: each worker gets a permanent virtual address, and the orchestrator talks to that address. No inbound ports. No per-worker certificates. The trust relationship is established once, per peer, by mutual handshake — a worker you spin up for a job doesn’t inherit access to anything except what that specific peer relationship grants. When the worker restarts on a new IP, the address doesn’t change, and nothing in the orchestrator’s configuration does either. That last property is the one teams underestimate. Address stability isn’t convenience; it’s what makes agents disposable . If a worker can be torn down and replaced without anyone updating a config file, then you can scale agents the way you scale containers — and that’s the operational model the whole agentic pattern is reaching for. What to Look for When You Choose a Connectivity Layer If you’re evaluating options for agent networking, the checklist writes itself: Identity that outlives infrastructure — restarts, IP changes, cloud migrations. NAT traversal with relay fallback — not just for datacenter-to-datacenter traffic. Per-peer, explicit trust — not ambient network-wide access. Encryption you can audit — and key exchange that doesn’t trust the network in between. Agent-native tooling — discoverable, installable capabilities, not just a raw tunnel. Open source — because this layer sits underneath everything else you build. The agentic stack is settling: models, orchestration frameworks, MCP for tools. The missing layer is the network — addressing, transport, and trust for agents that live anywhere. It’s a small piece of architecture, and it’s the one that decides whether your agents can actually find each other. If you’re building agents that need to talk to each other, the install is one command: curl -fsSL https://pilotprotocol.network/install.sh | sh Then run pilotctl appstore catalogue and see what your agents can already reach.