learn: AI transport layer for reliable multi-device conversational agents

src/data/learnGuides.ts

@@ -49,6 +49,13 @@ export const learnGuides: LearnGuide[] = [
     date: 'July 25, 2026',
     track: 'Transport',
   },
+  {
+    slug: 'ai-transport-layer-for-reliable-multi-device-conversational-agents',
+    title: 'AI Transport Layer for Reliable Multi-Device Conversational Agents',
+    description: 'The transport requirements for agents that span phones, laptops, and background workers: stable addressing, NAT traversal, encryption, and discovery.',
+    date: 'August 28, 2026',
+    track: 'Transport',
+  },
   {
     slug: 'how-are-network-agent-tokens-different',
     title: 'How Network Agent Tokens Differ',

src/pages/blog/why-ai-agents-need-network-stack.astro

@@ -31,6 +31,8 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>The problem is not with these protocols -- they solve real problems at the application layer. The problem is with the assumption underneath them.</p>
 
+  <p>For a conversational agent that spans multiple devices, the assumption bites twice: not only must every instance be reachable, the transport has to keep the session alive while the user roams between networks and devices. Our guide on the <a href="/learn/ai-transport-layer-for-reliable-multi-device-conversational-agents">AI transport layer for reliable multi-device conversational agents</a> walks through those requirements.</p>
+
   <p><strong>88% of networks involve NAT.</strong> This number comes from measurements of real-world networks across ISPs, enterprises, and mobile carriers. Behind every NAT, agents cannot receive incoming HTTP connections. They are invisible to A2A. They are unreachable by MCP clients. They simply do not exist on the agent internet.</p>
 
   <p>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.</p>

src/pages/learn/ai-transport-layer-for-reliable-multi-device-conversational-agents.astro

@@ -0,0 +1,133 @@
+---
+import BlogLayout from '../../layouts/BlogLayout.astro';
+
+const bodyContent = `<p>Your conversational agent is not one process on one machine. There is a client on the phone, one in the browser, a desktop app, and often background workers that handle retrieval or summarization while the user is away. When the user picks the conversation back up on a laptop, the state has to follow — context, session, and the agent's identity all need to keep working across devices. That handoff is not an application problem. It is a transport problem.</p>
+
+<p>This guide covers the <strong>AI transport layer for reliable multi-device conversational agents</strong>: what it has to provide, where the usual options (HTTP, WebSockets, brokers, VPNs) fall short in specific ways, and what to look for when you evaluate a transport built for agents. The goal is a working mental model, not a product pitch — you can use the same criteria to judge any transport.</p>
+
+<h2 id="what-a-transport-layer-must-do">What an AI transport layer must do for multi-device conversational agents</h2>
+
+<p>A conversational agent differs from a typical web service in one important way: the connection is long-lived, bidirectional, and tied to a <em>user session</em> that outlives any single network connection. The user closes the laptop, the phone switches from WiFi to cellular, the agent restarts after an update — and the conversation should survive all of it.</p>
+
+<p>That gives a transport layer five concrete requirements:</p>
+
+<ul>
+  <li><strong>Persistent connectivity across network changes.</strong> WiFi to cellular, sleep and wake, router reboots. The connection either survives the transition or recovers without the user noticing.</li>
+  <li><strong>Stable identity independent of location.</strong> The agent's address must not change when its IP changes, or when it moves to another device entirely. Peers need one name they can always reach.</li>
+  <li><strong>Reachability from behind NAT.</strong> Phones, laptops, and home devices do not accept inbound connections. A transport that requires a public IP excludes most real devices.</li>
+  <li><strong>Encryption by default.</strong> Conversations are sensitive — session context, user data, tool results. Encryption should be a property of the transport, not an add-on.</li>
+  <li><strong>Discovery.</strong> When a new device joins the user's agent, it has to find the agent's other instances and the services they expose — without a human editing config files.</li>
+</ul>
+
+<p>Each requirement is easy to satisfy in isolation. The hard part is satisfying all five at once, because they interact. NAT traversal, for example, is much easier if identity is decoupled from location — but most transports never decouple them.</p>
+
+<h2 id="why-http-and-websockets-struggle">Why HTTP and WebSockets struggle with device mobility</h2>
+
+<p>HTTP and WebSockets are the default choices for conversational agents, and for good reason: they are everywhere, well-understood, and work fine inside a controlled environment. The failure modes show up exactly where multi-device agents live — at the boundary between networks and devices.</p>
+
+<h3>HTTP request/response</h3>
+
+<p>HTTP is a request/response protocol. The server must be reachable, and the client initiates everything. For a conversation, that means either polling (wasteful, and state still lives server-side) or a long-lived upgrade to something else. HTTP is fine for fetching a page or calling an API; it is a poor fit for a bidirectional session that must survive hours of idle time.</p>
+
+<h3>WebSockets</h3>
+
+<p>WebSockets give you a persistent bidirectional channel, which is closer to what a conversation needs. The limitation is what the channel is bound to: a TCP socket at a specific IP:port, with a NAT mapping that expires when idle. When the phone moves from WiFi to cellular, the socket dies. When the laptop sleeps, the mapping times out. Reconnection is possible — resume tokens, session IDs, replay — but every reconnect is application code you write and maintain, and every one of them can drop state.</p>
+
+<p>None of this makes WebSockets a bad choice. It makes them a choice with a specific operational cost: you own the reconnect, resume, and state-sync logic across every device and every network transition. For a single-device agent behind a stable network, that cost is small. For a multi-device agent, it becomes the bulk of your reliability work.</p>
+
+<h3>Brokers</h3>
+
+<p>Message brokers (MQTT, NATS, and similar) solve a different problem well: decoupling producers from consumers with pub/sub semantics and durable delivery. They are mature and worth using when a central broker fits your architecture. The tradeoff is architectural: every agent connects outbound to the broker, and the broker sits in the data path. If your agents span clouds, homes, and mobile devices, the broker is the single point through which all traffic passes — and the one piece of infrastructure you must operate. For a deeper comparison of broker versus direct-connection models, see <a href="/learn/nats-vs-grpc-agent-messaging">NATS vs. gRPC for agent messaging</a>.</p>
+
+<h2 id="the-addressing-problem">The addressing problem: separating identity from location</h2>
+
+<p>A phone's IP address changes constantly: every WiFi handoff, every cellular transition, every carrier NAT rebinding. A laptop's address changes when it moves between networks. If the agent's identity <em>is</em> its IP, the agent becomes unreachable every time the network changes — and every peer that cached the old address has to rediscover it.</p>
+
+<p>This is the core problem an AI transport layer has to solve for multi-device agents: <strong>identity must be decoupled from location</strong>. The agent needs a name that survives network changes, restarts, and moves between devices, while the actual path to reach it (IP and port) is resolved underneath.</p>
+
+<p>That is what a virtual address gives you. Each agent holds a permanent address — in Pilot Protocol's case a 48-bit identifier like <code>N:NNNN.HHHH.LLLL</code> — that does not change when the underlying IP changes, when the device roams, or when the agent migrates to another cloud. Peers cache the address, not the IP. The transport layer resolves the address to a current path, and if the path breaks it re-resolves. The conversation continues against a stable name, which is what makes session continuity possible in the first place.</p>
+
+<h2 id="nat-traversal">NAT traversal: the mobile reality</h2>
+
+<p>Most devices that host conversational agents are behind NAT — home routers, carrier-grade NAT on mobile networks, office firewalls. A device behind NAT can make outbound connections, but cannot accept inbound ones. Any transport that requires the agent to be directly reachable (raw TCP, most gRPC deployments, plain WebSockets without a relay) quietly excludes those devices.</p>
+
+<p>The standard answer is NAT traversal: use STUN to discover the device's public mapping, punch a hole so peers can connect directly, and fall back to a relay (a beacon) when hole-punching fails because of symmetric NAT or restrictive firewalls. The key property is that traversal happens automatically, in the transport layer, rather than being something each application implements. Agents behind NAT become reachable the same way agents on public IPs are — the network does the work.</p>
+
+<p>A VPN is the traditional alternative for reaching devices behind NAT: it puts every device on a virtual LAN so they can talk as if co-located. That works, and it is a legitimate choice. The limitation is that a VPN operates at the IP layer: it treats every machine as equivalent, gives you no per-agent identity, and grants network membership to everything joined. For a conversation that must follow a specific agent across devices, IP-layer reachability is necessary but not sufficient — you also need the agent's identity, trust, and discovery to move with it. That distinction is covered in more detail in <a href="/learn/mcp-tunnels-vs-vpn">MCP tunnels vs. VPNs for AI agents</a>.</p>
+
+<h2 id="encryption">Encryption without certificate management</h2>
+
+<p>A multi-device conversational agent moves sensitive data — session context, user instructions, tool outputs — over whatever network the device happens to be on. Transport encryption should not be optional, and it should not require per-device certificate provisioning.</p>
+
+<p>Modern approaches solve this with key exchange rather than certificates: peers establish a shared secret at connection time (X25519 key agreement) and encrypt the tunnel with an authenticated cipher (AES-GCM). Each agent's identity is its public key, generated once and held locally; trust between peers is established by explicit handshake — both sides approve, or the connection does not exist. No certificate authority, no renewal, no per-device PKI. The device can be brand new; it carries the agent's key, so it inherits the agent's identity and its existing trust relationships. For the underlying cryptography, see <a href="/learn/x25519-encryption">how X25519 secures agent communication</a>.</p>
+
+<h2 id="where-an-overlay-fits">Where an overlay transport layer fits</h2>
+
+<p>Put the requirements together and a pattern emerges: the transport for multi-device conversational agents is not a protocol you bolt onto HTTP. It is a network layer that runs <em>above</em> the physical network and provides its own addressing, connectivity, and trust — an overlay.</p>
+
+<p>An overlay gives the agent a virtual address that survives network changes, a tunnel that works through NAT, encryption as a property of the tunnel, and a registry for discovery. The application layer — MCP for tools, A2A for agent-to-agent semantics, or a plain custom protocol — runs on top of the overlay instead of being responsible for connectivity. <a href="/blog/why-ai-agents-need-network-stack">Why AI agents need a network stack</a> makes the case for this layering in depth.</p>
+
+<p><a href="https://pilotprotocol.network">Pilot Protocol</a> is one implementation of that idea, built specifically for AI agents. It gives every agent a permanent virtual address, establishes encrypted UDP tunnels (X25519 key exchange with AES-GCM) using STUN and hole-punching with relay fallback, and provides a rendezvous registry for discovery. Trust is explicit: peers handshake and approve each other before any traffic flows. The core daemon is written in Go with no external dependencies, and the network today has <strong>243k+</strong> registered agents and users. It is open source (AGPL-3.0) at github.com/pilot-protocol.</p>
+
+<p>It is not the only approach, and it is not right for every system. If your agents are all on one trusted network, a broker or a VPN may serve you better with less machinery. The point of this guide is the criteria — if a transport candidate cannot keep the agent reachable across network changes, cannot keep its identity stable across devices, and cannot encrypt by default, it will cost you the reliability you are trying to build.</p>
+
+<h2 id="evaluating-transports">Evaluating a transport for your conversational agent</h2>
+
+<p>When you evaluate any transport candidate, ask these questions in order:</p>
+
+<ul>
+  <li>Does the agent's address survive a network change? (Roaming, reboot, cloud migration.)</li>
+  <li>Does the address survive a <em>device</em> change? Can the agent's identity move to a new phone or laptop and keep its existing connections and trust?</li>
+  <li>Can peers reach the agent when it is behind NAT and idle — without a public IP and without the application implementing relay logic?</li>
+  <li>Is encryption automatic, or does it depend on certificates and per-device configuration?</li>
+  <li>Is discovery built in, or do you maintain a hand-rolled registry?</li>
+  <li>What does reconnection cost? If the transport has no resume story, that cost is yours.</li>
+</ul>
+
+<p>If a candidate fails any of the first four, the reliability burden lands on your application code — and it will be paid again on every device, in every network transition, for the life of the product.</p>
+
+<p>If you want to see an overlay transport in practice, the fastest path is to run one:</p>
+
+<pre><code>curl -fsSL https://pilotprotocol.network/install.sh | sh
+pilotctl daemon status   # confirm your node is online</code></pre>
+
+<p>The <a href="https://pilotprotocol.network/docs">documentation</a> covers addressing, tunnels, NAT traversal, and trust in detail. For the transport layer's place in the wider stack, the <a href="/learn/grpc-udp-transport">gRPC and UDP transport guide</a> and the <a href="/blog/replace-webhooks-with-persistent-agent-tunnels">case for persistent agent tunnels over webhooks</a> are good next reads.</p>`;
+
+
+const faqItems = [
+  {
+    question: "What is an AI transport layer for multi-device conversational agents?",
+    answer: "It is the networking layer that carries messages between a conversational agent's instances across devices (phone, laptop, web, background workers). For multi-device agents it must provide persistent connectivity across network changes, a stable identity independent of IP address, reachability from behind NAT, encryption by default, and discovery — so a conversation can continue seamlessly when the user switches devices.",
+  },
+  {
+    question: "Why do WebSocket connections drop when a device switches networks?",
+    answer: "A WebSocket is bound to a TCP socket at a specific IP:port, and the NAT mapping for that socket expires when idle or when the network changes. Moving from WiFi to cellular, or waking a laptop from sleep, breaks the mapping, so the connection dies. Recovery is possible with reconnect logic, resume tokens, and session state — but that logic is application code you write and maintain for every device and network transition.",
+  },
+  {
+    question: "What is NAT traversal and why does it matter for conversational agents?",
+    answer: "Most devices (phones, laptops, home devices) are behind network address translation and cannot accept inbound connections. NAT traversal lets them become reachable anyway: STUN discovers the public mapping, hole-punching opens a direct path between peers, and a relay (beacon) is the fallback when direct paths are blocked. It matters because a transport without NAT traversal excludes most real devices from hosting agents.",
+  },
+  {
+    question: "How do virtual addresses help conversational agents stay reachable?",
+    answer: "A virtual address decouples the agent's identity from its current IP address. The address persists across restarts, IP changes, roaming, and moves between devices or clouds, so peers always have a stable name to reach. The transport resolves that name to a current path underneath, which makes session continuity and device handoff possible without rediscovery on every interaction.",
+  },
+  {
+    question: "What is Pilot Protocol and how does it fit?",
+    answer: "Pilot Protocol is an open-source overlay network for AI agents. It gives each agent a permanent virtual address, encrypted UDP tunnels (X25519 key exchange with AES-GCM), NAT traversal via STUN and hole-punching with relay fallback, and a rendezvous registry for discovery. Trust is explicit — peers handshake and approve each other. It is one implementation of the overlay transport model described in this guide, not the only option.",
+  },
+  {
+    question: "Can MCP or gRPC run over an overlay transport?",
+    answer: "Yes. An overlay operates at the network layer, so application protocols run on top of it unchanged. MCP servers and clients can connect through tunnels instead of public HTTP endpoints, and gRPC can run over an encrypted overlay tunnel. The overlay provides connectivity, encryption, and identity; MCP and gRPC keep providing tool access and typed service contracts.",
+  },
+];
+---
+<BlogLayout
+  title="AI Transport Layer for Reliable Multi-Device Conversational Agents"
+  description="What a reliable AI transport layer needs for multi-device agents: stable addressing, NAT traversal, encrypted tunnels — and how to evaluate options."
+  date="August 28, 2026"
+  tags={["transport", "conversational-agents", "multi-device", "networking", "reliability"]}
+  canonicalPath="/learn/ai-transport-layer-for-reliable-multi-device-conversational-agents"
+  faqItems={faqItems}
+>
+  <Fragment set:html={bodyContent} />
+</BlogLayout>

src/pages/learn/grpc-udp-transport.astro

@@ -54,6 +54,8 @@ const bodyContent = `<p>If you have worked with gRPC, you know it uses HTTP/2 un
 
 <p>An alternative approach is to side-step the TCP/UDP transport question entirely by using an overlay network that handles reachability, encryption, and peer discovery for you. The overlay gives agents a virtual network interface — they send and receive messages over it, and the overlay handles the messy reality of NAT traversal, connection mobility, and encryption underneath.</p>
 
+<p>For conversational agents that span phones, laptops, and background workers, those properties are what keep a session alive across device handoffs — see the <a href="/learn/ai-transport-layer-for-reliable-multi-device-conversational-agents">AI transport layer for reliable multi-device conversational agents</a> guide for the full requirement set.</p>
+
 <p><a href="https://pilotprotocol.network">Pilot Protocol</a> is one such overlay, built specifically for AI agents. It runs entirely over UDP — the daemon establishes encrypted tunnels using X25519 key exchange and AES-256-GCM. STUN and hole-punching create direct P2P paths through NATs. A relay fallback handles symmetric NAT where hole-punching fails.</p>
 
 <p>The key difference from running gRPC over QUIC is that Pilot is not a transport for an RPC framework — it is the communication layer itself. Agents speak to each other over the overlay using the protocol that makes sense for their interaction (JSON messages, structured RPC, streaming file transfers). The overlay provides:</p>