diff --git a/public/llms.txt b/public/llms.txt
index 48b52c0a..37822fef 100644
--- a/public/llms.txt
+++ b/public/llms.txt
@@ -68,7 +68,7 @@ The managed control plane is in preview. Supported adapters can surface agent ac
 - [Nebula vs Tailscale vs ZeroTier: Overlay Network for AI Agents](https://pilotprotocol.network/blog/pilot-vs-tailscale-nebula-zerotier-ai-agents): Head-to-head comparison of the three most popular overlay networks and where Pilot fits for agent workloads.
 - [Benchmarking: HTTP vs UDP Overlay](https://pilotprotocol.network/blog/benchmarking-http-vs-udp-overlay): Latency, throughput, and NAT traversal benchmarks comparing HTTP/2 and Pilot's UDP overlay for agent communication.
 - [Persistent Connections for AI Agents](https://pilotprotocol.network/blog/move-beyond-rest-persistent-connections-for-agents): Compare REST, WebSocket, gRPC, and persistent UDP tunnels for agent messaging with code examples.
-- [Why AI Agents Need Their Own Network Stack](https://pilotprotocol.network/blog/why-ai-agents-need-network-stack): The case for a dedicated network layer — permanent addresses, NAT traversal, encrypted tunnels, and cryptographic trust for multi-agent systems.
+- [Agent Connectivity Best Practices: Why AI Agents Need a Network Stack](https://pilotprotocol.network/blog/why-ai-agents-need-network-stack): Agent connectivity best practices for multi-agent systems — durable addresses, NAT traversal, encrypted tunnels, and per-peer trust.
 - [Overlay Networking Explained](https://pilotprotocol.network/blog/overlay-networking-secure-ai-agent-communication-explained): A practical guide to overlay networking for secure AI agent communication — encapsulation, control planes, protocol trade-offs, and deployment patterns.
 - [NATS vs gRPC vs TCP vs Pilot Protocol](https://pilotprotocol.network/blog/pilot-vs-tcp-grpc-nats-comparison): Feature-by-feature comparison of four agent communication protocols with latency and throughput benchmarks.
 - [Multi-Agent System Security: Network Defense Strategies](https://pilotprotocol.network/blog/network-security-for-multi-agent-systems-key-strategies): Layered defense, secure protocols (MCP, A2A), and how to protect AI agent networks from compromise.
diff --git a/src/data/blogPosts.json b/src/data/blogPosts.json
index d9e1e213..fe3b70ab 100644
--- a/src/data/blogPosts.json
+++ b/src/data/blogPosts.json
@@ -17,7 +17,7 @@
  {
   "slug": "build-agent-app-turn-api-into-tool",
   "title": "How to Build an Agent App: Turn Your API Into an Agent-Native Tool",
-  "description": "Turn an existing API into an installable agent app on Pilot Protocol — the discover, install, call loop, what to prepare, and how to publish.",
+  "description": "Turn an existing API into an installable agent app on Pilot Protocol \u2014 the discover, install, call loop, what to prepare, and how to publish.",
   "date": "Jul 5",
   "category": "Blog",
   "tags": [
@@ -47,7 +47,7 @@
  {
   "slug": "overlay-network-ai-agents",
   "title": "Overlay Network for AI Agents: Architecture and Trust Model",
-  "description": "What an overlay network for AI agents needs — persistent addressing, NAT traversal, encrypted transport, and per-peer trust — and how Pilot Protocol implements it.",
+  "description": "What an overlay network for AI agents needs \u2014 persistent addressing, NAT traversal, encrypted transport, and per-peer trust \u2014 and how Pilot Protocol implements it.",
   "date": "Jul 1",
   "category": "Blog",
   "tags": [
@@ -62,7 +62,7 @@
  {
   "slug": "aegis-agent-firewall-prompt-injection",
   "title": "AEGIS: A Runtime Firewall for AI Agents Against Prompt Injection",
-  "description": "AEGIS is an offline agent firewall on the Pilot app store. Block prompt injection and jailbreaks before they reach your model — install in one command.",
+  "description": "AEGIS is an offline agent firewall on the Pilot app store. Block prompt injection and jailbreaks before they reach your model \u2014 install in one command.",
   "date": "Jun 30",
   "category": "Blog",
   "tags": [
@@ -77,7 +77,7 @@
  {
   "slug": "ai-agent-app-store",
   "title": "The AI Agent App Store: Install Tools With One Command",
-  "description": "How agents discover, install, and call tools on Pilot — the discover→install→call loop, signed local apps, and publishing your own to the agent app store.",
+  "description": "How agents discover, install, and call tools on Pilot \u2014 the discover\u2192install\u2192call loop, signed local apps, and publishing your own to the agent app store.",
   "date": "Jun 30",
   "category": "Blog",
   "tags": [
@@ -92,7 +92,7 @@
  {
   "slug": "direct-communication-protocols-ai-agents-guide",
   "title": "AI agent communication protocols: Pilot vs MCP vs A2A vs ACP vs ANP",
-  "description": "Compare AI agent communication protocols — MCP, A2A, ACP, ANP, and Pilot — on transport, discovery, NAT traversal, and trust. Find the right stack for your agents.",
+  "description": "Compare AI agent communication protocols \u2014 MCP, A2A, ACP, ANP, and Pilot \u2014 on transport, discovery, NAT traversal, and trust. Find the right stack for your agents.",
   "date": "Jun 30",
   "category": "Blog",
   "tags": [
@@ -109,7 +109,7 @@
  {
   "slug": "pilot-vs-tailscale-nebula-zerotier-ai-agents",
   "title": "Pilot vs Tailscale vs Nebula vs ZeroTier for AI Agents",
-  "description": "Tailscale, Nebula, and ZeroTier are great machine VPNs — but agents need addressing, discovery, and per-peer trust. An honest architecture comparison and decision guide.",
+  "description": "Tailscale, Nebula, and ZeroTier are great machine VPNs \u2014 but agents need addressing, discovery, and per-peer trust. An honest architecture comparison and decision guide.",
   "date": "Jun 28",
   "category": "Blog",
   "tags": [
@@ -1138,13 +1138,15 @@
  },
  {
   "slug": "why-ai-agents-need-network-stack",
-  "title": "Why AI Agents Need Their Own Network Stack",
-  "description": "A2A assumes HTTP endpoints. MCP assumes reachable servers. 88% of networks involve NAT. The agent ecosystem is missing its TCP/IP layer.",
+  "title": "Agent Connectivity Best Practices: Why AI Agents Need a Network Stack",
+  "description": "Agent connectivity best practices for reliable multi-agent systems: durable addresses, NAT traversal, encrypted tunnels, and per-peer trust.",
   "date": "Feb 17",
   "category": "Architecture",
   "tags": [
    "opinion",
-   "ai-agents"
+   "ai-agents",
+   "networking",
+   "best-practices"
   ],
   "banner": "banners/why-ai-agents-need-network-stack.webp",
   "iso_date": "2026-02-17"
@@ -1330,4 +1332,4 @@
   "banner": "banners/claude-agent-teams-over-pilot.webp",
   "iso_date": "2026-02-09"
  }
-]
+]
\ No newline at end of file
diff --git a/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro b/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro
index 3b58e2bb..017f4162 100644
--- a/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro
+++ b/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro
@@ -213,7 +213,7 @@ const bodyContent = `<script type="application/ld+json">
 <h2 id="explore-next-gen-ai-networking-tools" tabindex="-1">Explore next-gen AI networking tools</h2>
 <p>Building from hard-won lessons and industry best practices, here’s where you can take the next step. The practices in this article are only as effective as the infrastructure you run them on.</p>
 <p><img src="https://csuxjmfbwmkxiegfpljm.supabase.co/storage/v1/object/public/blog-images/organization-24002/1774647725213_pilotprotocol.jpg" alt="https://pilotprotocol.network"></p>
-<p><a href="https://pilotprotocol.network">Pilot Protocol</a> gives you the decentralized networking infrastructure to put these practices into production. You get encrypted P2P tunnels, NAT traversal, virtual addresses, and mutual trust establishment out of the box, without relying on centralized brokers or message queues. It supports multi-cloud and cross-region agent connectivity, wraps HTTP, gRPC, and SSH inside its overlay, and integrates cleanly with existing systems. Explore more on decentralized AI networking to see how teams are building production-grade agent fleets today.</p>
+<p><a href="https://pilotprotocol.network">Pilot Protocol</a> gives you the decentralized networking infrastructure to put these practices into production. You get encrypted P2P tunnels, NAT traversal, virtual addresses, and mutual trust establishment out of the box, without relying on centralized brokers or message queues. It supports multi-cloud and cross-region agent connectivity, wraps HTTP, gRPC, and SSH inside its overlay, and integrates cleanly with existing systems. If you are still building the case for a dedicated network layer, start with <a href="/blog/why-ai-agents-need-network-stack">why AI agents need their own network stack</a>. Explore more on decentralized AI networking to see how teams are building production-grade agent fleets today.</p>
 <h2 id="frequently-asked-questions" tabindex="-1">Frequently asked questions</h2>
 <h3 id="what-are-the-most-resilient-p2p-architectures-for-ai-networking" tabindex="-1">What are the most resilient P2P architectures for AI networking?</h3>
 <p>Dynamic DAGs and DHTs such as Kademlia are proven for fault tolerance and scalability in AI systems, handling node churn and network partitions without a central coordinator.</p>
diff --git a/src/pages/blog/move-beyond-rest-persistent-connections-for-agents.astro b/src/pages/blog/move-beyond-rest-persistent-connections-for-agents.astro
index 5af50deb..d19480dd 100644
--- a/src/pages/blog/move-beyond-rest-persistent-connections-for-agents.astro
+++ b/src/pages/blog/move-beyond-rest-persistent-connections-for-agents.astro
@@ -53,7 +53,7 @@ while True:
     <li><strong>Lightweight.</strong> Adding a connection to another agent should not require deploying a message broker, configuring a WebSocket gateway, or managing connection pooling infrastructure.</li>
   </ul>
 
-  <p>No single existing protocol hits all five. REST misses bidirectional and persistent. WebSocket misses NAT-traversing and lightweight. gRPC streaming misses NAT-traversing. MQTT hits most but requires a broker (not lightweight for small deployments) and does not do NAT traversal.</p>
+  <p>No single existing protocol hits all five. REST misses bidirectional and persistent. WebSocket misses NAT-traversing and lightweight. gRPC streaming misses NAT-traversing. MQTT hits most but requires a broker (not lightweight for small deployments) and does not do NAT traversal. For the full argument on why agents need a dedicated network layer rather than extending HTTP, see <a href="/blog/why-ai-agents-need-network-stack">why AI agents need their own network stack</a>.</p>
   </section>
 
   <section>
diff --git a/src/pages/blog/why-ai-agents-need-network-stack.astro b/src/pages/blog/why-ai-agents-need-network-stack.astro
index 9d7e74a6..02a98c31 100644
--- a/src/pages/blog/why-ai-agents-need-network-stack.astro
+++ b/src/pages/blog/why-ai-agents-need-network-stack.astro
@@ -5,7 +5,7 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>It is not.</p>
 
-  <p>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.</p>
+  <p>So the first agent connectivity best practice is this: <strong>treat the network as a first-class part of your agent architecture, not as plumbing you can bolt on later.</strong> 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.</p>
 
   <figure class="video-embed">
     <div class="video-embed__frame">
@@ -31,7 +31,7 @@ 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><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><strong>NAT is the default condition of the real internet.</strong> Home routers, office firewalls, mobile carriers, and cloud egress paths all translate addresses. 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>
 
@@ -41,9 +41,9 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>In the current ecosystem, agents typically authenticate using one of three mechanisms: <strong>API keys</strong>, <strong>OAuth tokens</strong>, or <strong>mutual TLS certificates</strong>. Each has severe limitations in an agent-to-agent context.</p>
 
-  <p><strong>45.6% of organizations use shared API keys</strong> for agent-to-agent communication, according to industry surveys. 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.</p>
+  <p><strong>Shared API keys are still the default for agent-to-agent communication.</strong> 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.</p>
 
-  <p>The scale of the problem is staggering. <strong>Non-human identities now outnumber human identities 100:1</strong> in enterprise environments. Each agent, service account, API key, and bot needs its own identity. The old model of a human administrator manually provisioning and rotating credentials does not scale to thousands of autonomous agents.</p>
+  <p>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.</p>
 
   <p>What is needed is a system where every agent has a <strong>unique cryptographic identity</strong> that it controls, that is verifiable without a central authority, and that persists across restarts and migrations. In Pilot Protocol, this is the Ed25519 key pair generated during <code>pilotctl init</code>. The agent owns its private key. Its public key is its identity. No shared secrets, no central certificate authority, no OAuth dance.</p>
 
@@ -51,21 +51,21 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>Multi-agent systems have a topology problem that HTTP makes exponentially worse.</p>
 
-  <p>If you have <strong>N agents</strong> that need to communicate with each other, you need <strong>N x (N-1) / 2</strong> connections. For 10 agents, that is 45 connections. For 100 agents, that is 4,950 connections. For 1,000 agents, that is 499,500 connections.</p>
+  <p>If you have <strong>N agents</strong> that need to communicate with each other, you need <strong>N x (N-1) / 2</strong> 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.</p>
 
   <p>With HTTP, each of these connections involves:</p>
 
   <ul>
-    <li><strong>TCP handshake</strong> -- 1.5 round trips for SYN/SYN-ACK/ACK</li>
-    <li><strong>TLS handshake</strong> -- 1-2 additional round trips for certificate exchange and key agreement</li>
+    <li><strong>TCP handshake</strong> -- multiple round trips before any payload flows</li>
+    <li><strong>TLS handshake</strong> -- additional round trips for certificate exchange and key agreement</li>
     <li><strong>HTTP negotiation</strong> -- protocol version, headers, authentication</li>
     <li><strong>Keep-alive management</strong> -- idle connection timeouts, reconnection logic</li>
     <li><strong>Certificate management</strong> -- each agent needs a TLS certificate, trusted by every peer</li>
   </ul>
 
-  <p>A Pilot Protocol agent maintains a <strong>single UDP socket</strong>. 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. 1,000 connections to 100 different agents use the same UDP port, the same tunnel, and the same encryption key per peer.</p>
+  <p>A Pilot Protocol agent maintains a <strong>single UDP socket</strong>. 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.</p>
 
-  <p>The difference in resource usage is dramatic. An HTTP-based mesh of 100 agents requires provisioning 4,950 TLS connections with keep-alive, connection pooling, and retry logic. A Pilot mesh of 100 agents requires 100 UDP tunnels, each carrying as many logical connections as needed.</p>
+  <p>The difference in resource usage is dramatic. An HTTP-based mesh requires provisioning one TLS connection per agent pair, with keep-alive, connection pooling, and retry logic for each. A Pilot mesh requires one UDP tunnel per peer, each carrying as many logical connections as needed.</p>
 
   <h2 id="token-tax">The Token Tax</h2>
 
@@ -73,11 +73,11 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>Multi-agent systems that coordinate over HTTP typically serialize context into JSON, send it as HTTP request bodies, parse it on the other end, and feed it back into an LLM. Every coordination step involves serialization, transmission, and deserialization. Every message carries HTTP headers, content-type negotiations, and authentication tokens.</p>
 
-  <p>Measurements show that <strong>multi-agent systems use up to 15x more tokens</strong> for coordination overhead compared to the actual task content. When agents coordinate via HTTP APIs, each step of the conversation carries the accumulated context of the entire interaction. The HTTP request/response model forces agents to be stateless, which means re-transmitting context on every call.</p>
+  <p>When agents coordinate via HTTP APIs, each step of the conversation carries the accumulated context of the entire interaction. The HTTP request/response model forces agents to be stateless, which means re-transmitting context on every call. Coordination overhead can rival the actual task content -- and it compounds as conversations grow.</p>
 
   <p>A network-layer solution reduces this overhead dramatically. Pilot Protocol connections are <strong>stateful</strong> -- they maintain sequence numbers, acknowledgment state, and flow control windows. An agent can send a small delta ("anomaly count updated to 48") instead of re-serializing the entire context. The connection stays open, the tunnel stays encrypted, and the agents maintain shared state at the transport layer instead of the application layer. For a deeper look at why persistent connections beat request-response patterns, see <a href="/blog/move-beyond-rest-persistent-connections-for-agents">Move Beyond REST: Persistent Connections for Agents</a>.</p>
 
-  <p>This is not a minor optimization. At scale, the difference between 15x token overhead and 1x token overhead is the difference between a cost-effective system and one that is prohibitively expensive to operate.</p>
+  <p>This is not a minor optimization. At scale, the difference between coordination-heavy overhead and lean deltas is the difference between a cost-effective system and one that is prohibitively expensive to operate.</p>
 
   <h2 id="network-stack">What a Network Stack Gives You</h2>
 
@@ -107,6 +107,36 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>The network stack provides <strong>well-known port numbers</strong> 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 <a href="/blog/lightweight-swarm-communication-drones-robots">drone and robot swarm communication</a> to <a href="/blog/smart-home-without-cloud-local-device-communication">cloud-free smart home device networks</a>.</p>
 
+  <h2 id="best-practices">Agent Connectivity Best Practices</h2>
+
+  <p>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:</p>
+
+  <h3>Give every agent a durable identity and address</h3>
+
+  <p>Address the agent, not the machine. If your agent's identity is an IP address or a hostname, it breaks the moment the agent restarts on a new IP, moves clouds, or scales horizontally. A permanent virtual address decouples "who the agent is" from "where it happens to be running right now." This is the single highest-leverage practice on this list, and it is the one most agent frameworks quietly skip.</p>
+
+  <h3>Assume NAT, and build traversal in from day one</h3>
+
+  <p>Do not design for a world where every agent has a public IP. Most agents will live behind a home router, an office firewall, or a cloud egress path -- and every one of those translates addresses. If reachability is a deployment concern ("just add a reverse proxy"), every new agent doubles your operational load. If it is a protocol concern (STUN, hole-punching, relay fallback built into the transport), reachability stops being something you think about.</p>
+
+  <h3>Encrypt the tunnel, not just the payload</h3>
+
+  <p>Application-layer encryption (TLS on each HTTP call) leaves the connection metadata and the network topology exposed, and it couples encryption to certificate management. Encrypting the tunnel itself -- once per peer, covering every connection between two agents -- gives you authentication and integrity checking for free, with no per-connection handshake overhead. In Pilot Protocol this is X25519 key exchange with AES-GCM, enabled by default with no certificates to manage.</p>
+
+  <h3>Decouple membership from trust</h3>
+
+  <p>A VPN treats "joined the network" as "trusted." For agents, that conflation is dangerous: an agent that joins a shared network should not automatically be able to reach every other agent on it. The best practice is an explicit per-peer handshake -- two agents mutually approve a trust link before any data flows -- so membership and trust stay independent, and trust can be revoked per peer.</p>
+
+  <h3>Keep connections stateful</h3>
+
+  <p>HTTP's request/response model forces agents to re-transmit context on every call. Persistent, stateful connections let agents send deltas instead of full re-serializations -- the transport keeps sequence numbers, acknowledgment state, and flow control, so the application layer stops paying the token tax. For the detailed comparison, see <a href="/blog/move-beyond-rest-persistent-connections-for-agents">Move Beyond REST: Persistent Connections for Agents</a>.</p>
+
+  <h3>Standardize the service layer</h3>
+
+  <p>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.</p>
+
+  <p>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 <a href="build-multi-agent-network-five-minutes">five-minute multi-agent network tutorial</a>, or the <a href="/learn/what-is-pilot-protocol">plain-language primer on what Pilot Protocol is</a>.</p>
+
   <h2 id="tailscale">The Tailscale Analogy</h2>
 
   <p>The best analogy for what Pilot Protocol does for agents is what <strong><a href="https://tailscale.com" target="_blank" rel="noopener">Tailscale</a> did for humans</strong>.</p>
@@ -133,16 +163,18 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
 
   <p>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.</p>
 
-  <p>Pilot Protocol is a proposal for what that foundation looks like: <strong>permanent addresses</strong>, <strong>encrypted tunnels</strong>, <strong>automatic NAT traversal</strong>, <strong>cryptographic trust</strong>, and <strong>port-based services</strong>. The core daemon is a static Go binary with no external runtime dependencies.</p>
+  <p>Pilot Protocol is a proposal for what that foundation looks like: <strong>permanent addresses</strong>, <strong>encrypted tunnels</strong>, <strong>automatic NAT traversal</strong>, <strong>cryptographic trust</strong>, and <strong>port-based services</strong>. 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 <a href="/blog/pilot-vs-tailscale-nebula-zerotier-ai-agents">Pilot vs Tailscale vs Nebula vs ZeroTier for AI Agents</a>, and the <a href="/blog/ai-networking-best-practices-secure-scalable-systems">broader AI networking best practices guide</a> for the security side of the same coin.</p>
 
   <div class="callout">
-    <p><strong>The numbers are clear:</strong> 88% of networks have NAT. 45.6% use shared API keys. Non-human identities outnumber humans 100:1. Multi-agent coordination costs 15x in token overhead. The application layer cannot solve these problems. The network layer can.</p>
+    <p><strong>The pattern is clear:</strong> NAT is everywhere, shared API keys are the default identity, non-human identities outnumber human ones, and request-response coordination multiplies token spend. The application layer cannot solve these problems. The network layer can.</p>
   </div>
 
   <h2 id="get-started">Getting Started</h2>
 
   <p>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.</p>
 
+  <pre><code>curl -fsSL https://pilotprotocol.network/install.sh | sh</code></pre>
+
   <ul>
     <li><a href="build-multi-agent-network-five-minutes"><strong>Build a multi-agent network in 5 minutes</strong></a> -- hands-on tutorial from install to working demo</li>
     <li><a href="how-pilot-protocol-works"><strong>How Pilot Protocol works</strong></a> -- architecture deep dive covering every layer of the stack</li>
@@ -157,15 +189,17 @@ const bodyContent = `<p>AI agents need their own network stack because HTTP was
   </div>`;
 ---
 <BlogLayout
-  title="AI Agents Need a Network Stack: Why HTTP Isn't Enough for Agent Communication"
-  description="AI agents need more than HTTP. Learn why permanent addresses, encrypted tunnels, and built-in trust replace request/response APIs for real multi-agent systems."
+  title="Agent Connectivity Best Practices: Why AI Agents Need a Network Stack"
+  description="Agent connectivity best practices for reliable multi-agent systems: durable addresses, NAT traversal, encrypted tunnels, and per-peer trust."
   date="February 17, 2026"
-  tags={["analysis", "opinion", "ai-agents"]}
+  dateModified="August 15, 2026"
+  tags={["analysis", "opinion", "ai-agents", "networking", "best-practices"]}
   canonicalPath="/blog/why-ai-agents-need-network-stack"
   bannerImage="/blog/banners/why-ai-agents-need-network-stack.webp"
   faqItems={[
     { question: "What is an agent network stack?", answer: "An agent network stack is a dedicated networking layer that handles addressing, reachability, encryption, and trust for AI agents. Unlike HTTP, which was designed for browser-server communication, an agent network stack gives each agent a permanent virtual address, automatic NAT traversal, encrypted peer-to-peer tunnels, and built-in cryptographic identity — so agents can communicate directly regardless of where they are deployed." },
-    { question: "Why can't AI agents just use HTTP for communication?", answer: "HTTP assumes publicly reachable servers. But 88% of networks involve NAT, making agents behind home routers or corporate firewalls invisible to HTTP-based protocols like A2A and MCP. HTTP also requires one TCP+TLS connection per agent pair, which grows quadratically — 100 agents need 4,950 connections. And HTTP's request-response model forces agents to re-transmit context on every call, creating a token tax that can reach 15x overhead." },
+    { question: "What are agent connectivity best practices?", answer: "The core agent connectivity best practices are: give every agent a durable identity and address that survives restarts and migrations; assume NAT and build traversal into the transport rather than bolting on reverse proxies; encrypt the tunnel itself, not just the payload; decouple network membership from per-peer trust; keep connections stateful so agents send deltas instead of re-transmitting full context; and standardize the service layer with well-known ports. Pilot Protocol implements all of these in its core." },
+    { question: "Why can't AI agents just use HTTP for communication?", answer: "HTTP assumes publicly reachable servers. But NAT is the default condition of the real internet, making agents behind home routers or corporate firewalls invisible to HTTP-based protocols like A2A and MCP. HTTP also requires one TCP+TLS connection per agent pair, which grows quadratically as the mesh grows. And HTTP's request-response model forces agents to re-transmit context on every call, creating a token tax that can rival the cost of the task itself." },
     { question: "How does NAT affect AI agent communication?", answer: "NAT (Network Address Translation) makes agents behind firewalls and routers invisible to incoming connections. An agent behind a home router cannot receive A2A task delegations or MCP tool requests because there is no publicly reachable HTTP endpoint. Standard workarounds like reverse proxies, ngrok, or Cloudflare Tunnels add complexity and cost. A network stack with built-in NAT traversal solves this automatically through STUN, hole-punching, and relay fallback." },
     { question: "What problems does a network stack solve for multi-agent systems?", answer: "A network stack solves five problems simultaneously: <strong>permanent addresses</strong> that survive IP changes, <strong>NAT traversal</strong> for agents behind firewalls, <strong>tunnel encryption</strong> without certificate management, <strong>connectivity controls</strong> based on peer trust or network membership, and <strong>port-based services</strong> that replace custom message-passing code with well-known service ports." },
     { question: "How do permanent addresses help AI agents?", answer: "Every agent gets a 48-bit virtual address that never changes — even when the agent moves between machines, changes cloud providers, or reconnects after a restart. Other agents always reach it at the same address. This makes long-running multi-agent systems practical because agents can cache addresses, maintain persistent connections, and route messages without re-discovery on every interaction." }