DEV Community: Philip Stayetski

Agent App vs MCP Server: The Honest Structural Difference

Philip Stayetski — Sun, 19 Jul 2026 21:32:38 +0000

If you're building tools for AI agents, you've likely come across two approaches: agent apps (installable local capability services) and MCP servers (remote tools exposed via the Model Context Protocol). They look similar on the surface — both let agents do things beyond text completion — but they solve fundamentally different problems. Understanding the structural difference matters when you're deciding how to ship your own tool or evaluating what to wire into an agent pipeline.

This article lays out the honest architectural distinction: typed local IPC versus a hosted JSON-RPC endpoint. Both are valid. They solve different halves of the problem.

What an MCP Server Actually Is

The Model Context Protocol (MCP) defines a standard way for an agent to discover and call tools on a remote server. You run an MCP server somewhere — locally as a subprocess, on a VM, or behind a URL — and the agent talks to it over JSON-RPC (usually stdio or HTTP+SSE).

The core pattern:

Agent ──JSON-RPC──> MCP Server (stdio / HTTP)

The server announces its capabilities (tools, resources, prompts) at connect time. The agent calls tools by name with JSON arguments and gets JSON results back. It is an RPC protocol with a well-defined schema, and that's its strength: any agent that supports MCP can talk to any MCP server without custom integration code.

The trade-off: the server is something you run and manage. You pick the transport, handle the lifecycle, decide on authentication, and ensure uptime. MCP does not specify how the server is installed, verified, kept alive, or isolated — that is your responsibility.

What an Agent App Is

An agent app (as implemented by the Pilot Protocol app store) is a different model entirely. It is a typed IPC service that runs locally on the agent's own daemon, installed with a single command and auto-spawned on demand.

Agent ──JSON──> Daemon Supervisor ──spawns──> App (local IPC)

The loop is discover → install → call:

Discover: pilotctl appstore catalogue lists every available app.
View/Inspect: pilotctl appstore view <id> shows the manifest, permissions, and source.
Install: pilotctl appstore install <id> downloads the app, verifies its integrity, and registers it with the local daemon. No separate hosting, no manual wiring.
Call: pilotctl appstore call <id> <app>.method '<json>' — the daemon spawns the app, routes the JSON request, collects the JSON response, and tears it down when idle.

The structural differences from an MCP server are not cosmetic. They change who bears the operational cost and what guarantees you get.

The Honest Breakdown

Where It Runs

	MCP Server	Agent App
Host	You provision and manage (local process, VM, container, or serverless)	Daemon-managed local process, auto-spawned from install artifact
Lifecycle	You start/stop/monitor it	Daemon supervises — spawns on call, idles, restarts on crash
Network	stdio, HTTP, SSE — requires a reachable endpoint	Local IPC socket — no network exposure

An MCP server is a service you own the operations of. An agent app is a capability you install and forget.

Trust and Integrity

MCP servers use whatever auth the implementer chooses — API keys, bearer tokens, mutual TLS, or nothing. The protocol does not define a trust model; the agent typically trusts whatever server it connects to.

Agent apps have a built-in integrity model baked into the installation process:

Each app's manifest pins a sha256 hash and an Ed25519 signature.
The daemon re-verifies the hash + signature on every spawn.
Permissions are declared in the manifest and accepted at install time — no ambient authority.
The app runs in a daemon-supervised sandbox; it has no access to the filesystem, network, or other apps unless the manifest declares it.

This is deliberately stronger than "trust the URL" because agent apps are installed from a shared catalogue where anyone can publish.

Discovery

MCP servers are discovered through directories (like smithery.ai or community lists). Each is a pointer to a URL or repo — the agent still needs to connect and introspect to learn what tools exist.

Agent apps are runtime-discoverable after install. Calling <app>.help returns every method, its parameters, latency class, and cost — all as typed JSON, no network round-trip. The catalogue is queryable at any time with pilotctl appstore catalogue.

Protocol Surface

MCP uses JSON-RPC 2.0 over a streaming transport. It has a well-specified initialization handshake, capability negotiation, and notification model. This is powerful for complex tool ecosystems but adds overhead for simple "call a thing, get a result" operations.

Agent apps use raw JSON in → JSON out over a local IPC socket. No handshake, no capability negotiation, no streaming protocol — just input, output, and an error envelope on failure. The daemon handles transport, reliability, and spawning. The latency is negligible because there is no network.

When Each Shines

Choose an MCP server when:

Your tool requires server-side state, databases, or external API keys that shouldn't be distributed with the client.
You already run infrastructure and want to expose an existing service to any MCP-compatible agent.
You need streaming responses or long-running tool calls (MCP's notification pattern fits this better).
You want broad interoperability across agent frameworks — MCP is supported by Claude Desktop, many LangChain integrations, and a growing ecosystem.

Choose an agent app when:

Your tool is self-contained — it does not need a backend you host.
You want agents to install and use your tool with zero ops overhead.
Integrity matters: you want every invocation to be signature-verified before it runs.
You are building for an ecosystem where agents discover, install, and compose capabilities autonomously.

The honest answer is that many setups will use both. An MCP server is the right model for a hosted API gateway; an agent app is the right model for a packaged capability you want agents to self-serve.

A Concrete Example

An agent needs to research a topic. On the MCP side, it might connect to a web-search MCP server hosted at some endpoint — that server calls an upstream search API and returns results.

On the agent-app side, it runs pilotctl appstore call io.pilot.cosift cosift.search '{"q":"topic","k":"8"}' — the daemon spawns the cosift app locally, which performs grounded web search and returns structured JSON. No server to host, no API key to provision, no connection to manage. The app was installed once, signature-verified, and is always available.

Both produce search results. The difference is who owns the infrastructure between the agent and the data.

The Bottom Line

Agent apps and MCP servers are not competitors — they are different shapes for different operational realities. MCP is a wire protocol for tool interoperability across any agent and any server. Agent apps are a distribution and execution model for capabilities that install and run on the agent's own infrastructure.

If you have a backend you already run, expose it as an MCP server. If you have a capability you want agents to discover and use with no infrastructure on your side, package it as an agent app.

The Pilot Protocol app store is one implementation of the agent-app model. You can explore the catalogue at pilotprotocol.network/app-store — and publish your own app via the /publish flow. For most developers, the ideal strategy is to have both: an MCP server for your existing services, and an agent app for anything you want agents to self-install.

Pilot Protocol is an open-source overlay network with an app store for agent-native capabilities. Install with curl -fsSL https://pilotprotocol.network/install.sh | sh and explore the catalogue with pilotctl appstore catalogue.

How to Publish an Agent App: Turn Your API Into a One-Command Install

Philip Stayetski — Sun, 19 Jul 2026 16:32:36 +0000

You have an API. Agents should be able to call it.

You built a service — maybe a weather lookup, a company research endpoint, a code sandbox, a price feed. It works fine when a human pastes a curl command. But an autonomous AI agent? It needs discoverability, typed inputs, a contract it can read before calling. It needs an agent app.

This is the walkthrough for someone who already has an API and wants to drop it into the Pilot app store — where agents discover, install, and call it with one command.

What "publishing an agent app" actually means

An agent app on Pilot Protocol isn't a container or a server you ship. It's an adapter — a typed JSON-in/JSON-out description of your API's methods that the local Pilot daemon installs as a supervised IPC service. Agents on the network install it with one command and call your API without writing any integration code.

The publishing process is: describe your app → they build and sign the adapter → the team reviews → it's live in the catalogue.

You never upload code. You never hand over your API keys. You describe what your methods do, and Pilot generates the adapter for you.

Before you start

You need:

A working API (public or with a documented shape). Agents call it over the internet, so it needs to be reachable.
A valid email. Pilot uses this to send you a submission confirmation and the review decision.
A name and a short description for your app. Think about what an agent would search for.

That's it. No SDK to install, no container to build, no repository to maintain.

Step 1: Go to the publish page

Navigate to pilotprotocol.network/publish. The form is a 7-step wizard — it walks you through everything in order.

⚠️ The page shows a "Publishing needs a desktop" notice on small screens. Open it on a desktop browser to see the full form.

Step 2: Email (Step 1 of 7)

Enter your email address. Pilot sends a confirmation so they can reach you about your submission and the review decision. This is also where you'll get notified when your app goes live or needs changes.

Step 3: Identity (Step 2 of 7)

This is about who you are as a publisher. You provide your name and optionally a handle or organization name that appears alongside your app in the catalogue.

Step 4: Backend (Step 3 of 7)

Describe the backend your app talks to. This is the API base URL or endpoint. You don't upload credentials — Pilot's model is that secrets stay with the operator. At install time, the person running the agent supplies their own API keys for your service.

Step 5: Methods (Step 4 of 7)

This is the meat of the submission. Each method is one thing your API does. For each method you describe:

Name — a short identifier agents use to call it (e.g. search, lookup, analyze)
Description — what this method does, in plain language the agent's LLM can read to decide whether to call it
Input parameters — what the agent sends you (name, type, required/optional, a description)
Output shape — what your API returns

The Pilot team uses these descriptions to build a typed JSON adapter. An agent that installs your app calls <app>.<method> with JSON input and gets JSON output — no curl, no parsing, no conditional branches.

Make your descriptions agent-friendly. A good method description reads like "Search for a company by domain name and return its industry, employee count, and head office location" — not "POST /v2/search with q param."

Step 6: Listing (Step 5 of 7)

Catalogue details: a full description for the app store listing, a logo or icon URL if you have one, and a website link. This is what agents (and humans browsing the app store) see.

Step 7: Vendor (Step 6 of 7)

Contact details and any support URL. Pilot uses this if there's an issue with your app. It's also how the review team reaches you during the approval process.

Step 8: Review and release (Step 7 of 7)

The final step shows you a summary of everything you entered. Before submitting you confirm:

You have the right to publish this app and grant Pilot permission to distribute it
You agree to the Terms, Acceptable Use Policy, and Publisher Release Agreement

Submit when ready.

What happens next

Pilot's team reviews your submission. The review checks that:

The method descriptions match what the API actually does
The adapter it generates works correctly
The app doesn't violate the Acceptable Use Policy

Once approved, your app appears in the app store catalogue. Any agent on the network finds it with:

pilotctl appstore catalogue

And installs it with:

pilotctl appstore install <your-app-id>

Your API is now an agent-native tool. No additional code on your side. No integration maintenance. The agent calls it as a typed service — JSON in, JSON out, supervised by the daemon.

What kind of APIs make good agent apps

The best candidates are APIs that an autonomous agent would naturally reach for:

Lookup and research APIs — company data, person enrichment, domain info, patent search
Price and market data — crypto, FX, stocks, commodities
Weather and environmental data — forecast, air quality, marine, wildfire
Translation and language services
Code execution or sandbox APIs
Any API you'd want an agent to call without you writing integration logic

If your API already has a documented REST shape and you can describe each endpoint's intent in a sentence, it's a good fit.

No-code publishing, agent-native consumption

The loop is asymmetric by design: you publish without writing code, and the agent consumes without writing code. The adapter Pilot generates for you is signed and verified — the daemon re-checks the manifest's sha256 hash and ed25519 signature each time your app is spawned, so the agent never runs an untrusted adapter. At install time, the operator's secrets stay with the operator — your app just defines the shape.

This is the same model that lets agents chain multiple Pilot apps into a single workflow: install a research app, a web scraping app, and a notification app, and the agent calls them in sequence, piping JSON output to JSON input, without you ever writing a line of middleware.

Ready to publish?

Head over to the publish page and start the 7-step wizard. Describe your app, confirm your email, and let the platform generate the adapter. Your API becomes an agent-native tool in a single submission cycle.

Stateful vs Stateless Agents: The Hidden Cost of Starting Fresh Every Loop

Philip Stayetski — Sun, 19 Jul 2026 12:12:57 +0000

Every time an autonomous agent completes a task loop — calls an API, processes the result, decides the next action — it has to re-establish its identity and environment from scratch if it's truly stateless. That's not a design debate anymore; it's an operational cost that compounds with every iteration.

The Loop You Aren't Counting

Picture a stateless agent running on a serverless function. It starts, authenticates to two or three services (each requiring its own handshake or token refresh), discovers which peers or tools are available, hydrates some context from a database, does its work, and shuts down. Next invocation: same thing. Re-auth. Re-discovery. Cold start.

This is the default architecture for many agent deployments because it's simple to reason about and maps cleanly onto existing cloud infrastructure. But the hidden cost is real: every loop pays the setup tax. For a single-turn agent, that's noise. For an agent that runs hourly — or one that maintains ongoing conversations with other agents — it dominates the latency budget.

The divide between stateful vs stateless agents isn't about storing conversation history in a database. It's about whether the agent itself holds any durable identity that survives the gap between invocations.

Where Statelessness Bites

Three costs show up in practice:

Repeated authentication. Every invocation means re-proving identity. Token refreshes, JWTs, session cookies — each requires a round trip to an auth server. If the agent talks to multiple services, each one needs its own handshake. Multiply that by the number of invocations per hour, and the overhead accumulates fast.

Re-discovery of peers and capabilities. A stateless agent that needs to coordinate with other agents or talk to specialist services must discover what's available each time. That means directory lookups, capability negotiation, or hardcoded endpoints — all of which break when the network changes.

Cold-start context loss. The agent's working state — what it was doing, where it left off, which peers it was in conversation with — has to be serialized and stored between invocations. Serialization is lossy. The agent picks up with a snapshot, not a live connection.

The Case for a Persistent Address

A stateful agent holds a continuous identity. It can maintain long-lived connections, respond to inbound messages from peers without polling, and keep cryptographic state (session keys, negotiated parameters) alive across invocations. The natural consequence is a persistent network address: something that stays the same no matter where the agent runs or how many times it restarts.

Persistent addressing means:

One-time trust establishment. Handshake once with a peer or service; the relationship holds across restarts. No re-auth per loop.
Push, not poll. Peers can send messages to the agent's address without waiting for it to wake up and ask. That shifts the model from "agent asks the world" to "the world notifies the agent."
State continuity. Connections and cryptographic sessions survive the agent being offline. When it restarts, the old keys and relationships are still valid.

This is common ground with VPN overlays and mesh networks — but those were designed for devices, not agents. An agent overlay network gives the same durable addressing without requiring a full network interface, routing table, or device-level setup. The identity lives at the agent level, not the machine level.

What You Give Up Going Stateful

Stateful isn't free. The trade-offs are real:

Colder operation. Stateless is easier: spin up, work, spin down. Stateful means managing who can reach you, what state you keep, and what happens to it when you move.
State management. A persistent address only matters if the address allocation doesn't break when the agent moves across machines. That requires the overlay to handle mobility transparently.
Attack surface. A reachable agent is a reachable agent. Stateless agents are mostly invisible between invocations; stateful ones are always on the network, so they need authentication on every inbound message.

Where Each Model Fits

The stateless model works well for simple, single-purpose agents: check the weather, post a notification, run a quick lookup. The agent fires, does one thing, and exits. Any identity setup paid on every invocation is small relative to the actual work.

The stateful model earns its weight for agents that coordinate with each other, maintain ongoing conversations, or need to be discovered by peers without polling. A research agent that delegates subtasks, a monitoring agent that watches for events, or a multi-agent system where agents hand off work between invocations — these benefit from a persistent address because they'd otherwise pay the re-establishment cost on every delegation.

The Hybrid That Actually Works

Most production systems land somewhere in between. An agent stays stateless for the hot path — fast, disposable execution — but maintains a persistent overlay address for discovery and trust. Other agents and services reach it by that address; when it's offline they queue messages. When it fires up, it reconnects with its existing identity, drains the queue, and gets to work.

This gives you the operational simplicity of stateless execution (no long-running daemon, no keepalive management) while keeping the identity continuity that makes multi-agent coordination practical. The agent doesn't need to be "always on" — just always reachable at the same address.

The Bottom Line

When you design an agent system, don't default to fully stateless or fully stateful. Ask where your agent pays the re-establishment tax most often: on every loop, or only on infrequent cold starts. If it's every loop — if your agent talks to peers, maintains relationships, or delegates work — a persistent address changes the math. One-time identity establishment instead of per-loop re-auth. Push messages instead of polling. Trust that survives restarts.

Stateful vs stateless agents isn't a purity contest. It's a cost equation, and the cost side is bigger than most architecture discussions admit.

Pilot Protocol is an open-source overlay network that gives AI agents a persistent virtual address with encrypted tunnels and NAT traversal. Install it in one command:

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

Then discover, install, and call agent-native apps from the Pilot app store:

pilotctl appstore catalogue

How to Submit an IETF Internet Draft: The Datatracker Walkthrough

Philip Stayetski — Sat, 18 Jul 2026 20:05:31 +0000

How to Submit an IETF Internet Draft: The Datatracker Walkthrough

The IETF Datatracker looks deceptively simple. You log in, upload a document, hit submit. But between draft naming conventions, revision cadence rules, and the fact that one wrong filename prefix can get your submission rejected by the automated tooling, the first submission almost always goes wrong somehow.

I recently went through this for the first time — submitting the Pilot Protocol agent-transport specification as an individual Internet-Draft. Here's what the Datatracker actually asks for, how draft naming works, and what the revision cycle looks like in practice.

The Datatracker: Where Submissions Happen

All IETF Internet-Draft submissions go through datatracker.ietf.org. You need a Datatracker account, which requires an existing IETF or liaison relationship to create — the signup flow verifies your email against an approved domain or asks for a reference from an existing participant. If you're an individual contributor without an existing IETF relationship, you'll need a short email with a sponsor to get your account approved.

Once logged in, the submission page is straightforward: you upload a file in one of the accepted formats (XML v3 is the canonical format; plain text with the boilerplate works too), fill in a few metadata fields, and submit. The system validates your document for formatting compliance before accepting it.

The two things that trip up first-time submitters are the filename and the boilerplate.

Draft Naming Convention

Every Internet-Draft gets a name in this format:

draft-<author-or-prefix>-<topic>-<version-number>.txt

The <author-or-prefix> is typically your last name or a short group identifier. The <topic> is a hyphen-separated slug describing the draft. The version number starts at 00 and increments with each revision.

For the Pilot Protocol submission, the two drafts are:

draft-teodor-pilot-problem-statement-01 — the Informational track document describing why agents need network-layer infrastructure
draft-teodor-pilot-protocol-01 — the Experimental track document with the full wire specification

The teodor prefix comes from the author's last name (individual submissions use the submitter's name). The -01 suffix means these are on their second revision. A brand-new draft starts at -00.

One critical rule: the filename must match the document title's draft name. The Datatracker parses the first line of your document to extract the draft name, and if the filename on disk doesn't match what's declared in the document body, the submission will be rejected during validation. Always check that the filename and the document's own Internet-Draft header line agree before uploading.

The Boilerplate You Must Include

Every Internet-Draft needs specific boilerplate text near the top. Missing it is the most common validation failure. The required elements are:

Status of This Memo — a standard paragraph declaring this is an Internet-Draft, that it expires, and what category it belongs to.
Copyright Notice — the standard IETF Trust copyright.
Abstract — a brief summary of the document's purpose.

The exact wording for each category (Informational, Experimental, Standards Track) is specified in RFC 7841 and the current Internet-Draft Guidelines. The Datatracker's own submission page links to templates — use them rather than guessing.

For the Pilot drafts, the boilerplate declares Experimental status for the protocol spec (since it describes an active implementation under development, not a finalized protocol) and Informational for the problem statement (which surveys the landscape without specifying a protocol).

The Revision Cadence

An Internet-Draft expires six months after its last revision. The Datatracker tracks this automatically and will show an expiration date on the draft's page.

To keep a draft alive, you resubmit an updated version before the six-month mark. Each resubmission increments the version number by one (-00 → -01 → -02, etc.). You can submit revisions as often as you like — there is no minimum interval. Some working groups require a revision before every meeting; other drafts sit untouched for five months and get one quick resubmission to stay alive.

A revision does not have to contain substantive changes. Many drafts that are stable between meetings are resubmitted with only a date change in the boilerplate to reset the clock. The Datatracker handles this gracefully — it accepts minor updates and keeps the same document name with the incremented version.

What Happens After Submission

After you hit submit on the Datatracker:

Automated validation runs within seconds — checks filename, boilerplate, formatting, missing references.
The draft appears on the Datatracker within minutes, publicly accessible at https://datatracker.ietf.org/doc/draft-<name>/.
The Internet-Draft repository at https://www.ietf.org/archive/id/ mirrors it with a short delay.
The secretariat reviews for IETF-process compliance (not technical correctness) — this can take a day or two.
The draft is now citable by its draft name. Anyone can reference draft-teodor-pilot-protocol-01 in papers, other drafts, or RFCs.

There is no editorial review of technical content at this stage for individual submissions — that comes later if the draft is adopted by a working group or submitted to the IESG for publication. An individual Internet-Draft is a public statement that the problem and solution exist, not an endorsement by the IETF.

Practical Tips from a First Submission

Submit XML v3 if you can. The xml2rfc toolchain produces perfectly formatted text and HTML output. Writing plain-text drafts by hand is possible but error-prone — the page margins, line lengths, and section numbering rules are strict.
Use the idnits tool before submitting. It's available at https://www.ietf.org/tools/idnits/ and catches most boilerplate, reference, and formatting issues the Datatracker's validator will flag.
Check your references. If your draft cites RFCs or other drafts, the identifiers must match exactly what the RFC Editor uses. The idnits tool checks this too.
Pick your document stream up front. Individual submissions go through the Independent Stream; working-group submissions go through the IETF Stream. The stream affects the boilerplate text and the publication path.

The full process for the Pilot drafts is documented on the Pilot Protocol blog, including links to both live drafts on the Datatracker if you want to see what a real submission looks like end to end.

FAQ

How long does the Datatracker account approval take?

Typically 1–3 business days, depending on whether your sponsor responds promptly. The IETF secretariat processes these manually during business hours.

Can I submit a draft without a Datatracker account?

No. The submission system requires authentication. If you're collaborating, one author with an account can submit on behalf of the group.

What happens if my draft expires?

It is removed from the active Internet-Drafts directory but remains in the archive at the same URL. You can submit a new version at any time to reactivate it, starting from the previous version number.

Can an AI agent submit an Internet-Draft automatically?

In theory, if an agent holds Datatracker credentials, it can upload a file through the submission API. The Pilot Protocol app store includes tools for agent-native API access, but the IETF submission process itself still requires a human account holder to own the credentials — no automated tooling can bypass the identity verification step.

Headscale vs Nebula: Self-Hosted Overlay Networks Compared

Philip Stayetski — Sat, 18 Jul 2026 15:14:07 +0000

If you're evaluating self-hosted overlay networks in 2026, two names come up constantly: Headscale and Nebula. Both are open source. Both let you build a private mesh without relying on a third-party service. But they take radically different approaches to the same problem, and which one fits your use case depends heavily on what kind of traffic you're routing and who — or what — your nodes actually are.

This comparison walks through the architecture, deployment model, and tradeoffs of each, then looks at where the requirements start to diverge when the nodes are AI agents instead of servers or laptops.

Headscale: Tailscale for People Who Want Full Control

Headscale is an open-source implementation of the Tailscale coordination server. It provides the same centralized control-plane model: nodes register with a server, the server distributes cryptographic keys and ACLs, and nodes connect directly to each other via WireGuard tunnels when possible, falling back to DERP relay servers when NAT or firewalls block direct connections.

How it works: A single headscale server (or cluster) acts as the coordination point. Each node runs Tailscale's open-source client, which authenticates with headscale, receives its node key and ACL policy, then negotiates WireGuard tunnels to every other node it's authorized to reach. Traffic is encrypted end-to-end by WireGuard. The headscale server itself never sees data-plane traffic — it only handles coordination, key distribution, and NAT traversal signaling.

What it's good at:

Small-to-medium device meshes (tens to low hundreds of nodes)
Teams that want a Tailscale-like experience without paying for Tailscale's SaaS
Environments that already use WireGuard and want to layer identity and ACLs on top
Human-operated device access (SSH, web UIs, database connections)

Where it struggles:

The central control plane is a single point of failure and a coordination bottleneck
Scaling beyond a few hundred active nodes puts strain on the server
Each node maintains a WireGuard tunnel to every other node it can reach — O(n²) state for the mesh
DERP relay performance varies; relayed traffic adds latency and bandwidth on the relay node

Headscale is an excellent choice for a team of developers or a small organization that needs private, zero-trust connectivity between devices. The user experience, inherited from Tailscale's design, is polished and familiar.

Nebula: Lighthouse-Based Mesh at Scale

Nebula, originally built by Slack and now maintained as an open-source project under the Linux Foundation, takes a fundamentally different architectural approach. Instead of a centralized control plane, it uses a distributed lighthouse model.

How it works: Nebula nodes (called "hosts") discover each other through one or more lighthouse nodes. The lighthouse's job is purely directory and NAT traversal assistance — it tells node A how to reach node B, but it never routes or relays traffic between them. Once nodes have each other's addresses, they establish encrypted tunnels directly using Nebula's own protocol (not WireGuard). Nebula uses certificate-based authentication: a certificate authority signs host certificates that encode the host's identity, IP address within the overlay, and group membership.

What it's good at:

Larger meshes (hundreds to thousands of nodes)
Site-to-site connectivity where traffic patterns are predictable
Environments where you want no single point of failure in the data or control path
Infrastructure that already uses certificate-based identity

Where it struggles:

No built-in relay fallback — if two nodes can't establish a direct tunnel, they can't communicate
The CLI and configuration surface are more bare-metal than Headscale's
Lighthouse scoping requires thought: too few lighthouses creates a bottleneck, too many creates coordination overhead
Certificates need their own lifecycle management (rotation, revocation, distribution)

Nebula shines in infrastructure-grade deployments where traffic patterns are stable, node count is high, and the team has the operational maturity to manage certificates and lighthouse topology.

Where Node Identity Changes Everything

Both Headscale and Nebula were designed for device or user identity. A node is a server, a laptop, a container — something with a stable hostname and an operator on the other end. The overlay makes that device reachable from anywhere.

AI agents are not devices. They are:

Ephemeral: An agent spins up, does work, and terminates. It may have seconds of uptime. Registering it with a control plane and negotiating a full mesh every time is wasted work.
Transient in address: An agent can move between clouds, containers, and serverless runtimes multiple times a minute. Its IP changes constantly — even within a single session.
Trust-dynamic: Agents from different teams, organizations, or frameworks need to collaborate on one task and never talk again. Full mesh membership is the wrong scope. Per-peer, per-session trust is what matters.
Traffic-shaped differently: Agents don't stream terminals or files. They exchange structured data — JSON payloads, function calls, context blocks. A tunnel designed for TCP streams adds unnecessary overhead for small, frequent messages.

Headscale's full-mesh model means every new agent registers, gets a key, and tunnels to every other node — O(n) setup time that grows with every peer. Nebula's lighthouse model avoids the central bottleneck, but the lack of relay fallback means two agents behind NAT can't talk at all without help.

Pilot Protocol: Built for Agent-Shaped Traffic

Pilot Protocol was designed from the ground up for AI agents, not devices. It's an open-source overlay network that gives every agent a permanent virtual address — one that survives restarts, IP changes, and cloud migrations — without needing a full-mesh tunnel to every peer.

How it differs from both approaches:

No central control plane. Discovery uses a rendezvous registry, not a coordination server. There is no single point of failure and no server that sees all traffic.
NAT traversal by default. STUN + hole-punching + beacon relay fallback. Agents behind any NAT topology are reachable without manual relay configuration.
Per-peer trust, not mesh membership. Trust is explicit and bidirectional — one handshake at a time. Joining the network does not imply trusting everyone on it. This is the opposite of a VPN where membership equals trust.
Agent-native tools. The app store delivers capabilities as typed IPC services — discover, install, call. An agent finds what it needs at runtime through pilotctl appstore catalogue, not pre-configured tunnel ACLs.
Permanent virtual addressing. Move an agent between three clouds in one session. It keeps its address. There is no re-registration, no tunnel teardown.

243k+ agents already use the network, and the protocol is pure Go with zero external dependencies.

Which Should You Choose?

Constraint	Headscale	Nebula	Pilot Protocol
Node type	Human-operated devices	Infrastructure hosts	AI agents
Traffic pattern	Persistent tunnels	Site-to-site / host-to-host	Ephemeral, structured data
NAT traversal	DERP relay (built-in)	None (direct only)	STUN + hole-punch + beacon
Trust model	Mesh membership	CA certificates	Per-peer handshake
Scale ceiling	Low hundreds	Thousands	Designed for agent density
Self-hosted	Yes (one server)	Yes (lighthouse(s))	Optional (rendezvous)

Headscale is the right choice for a team needing a self-hosted, device-first overlay with a polished UI. Nebula wins for infrastructure-scale meshes where teams can manage certificates. For AI agents — ephemeral, address-changing, trust-dynamic — neither model maps cleanly, which is exactly why Pilot Protocol starts from a different set of assumptions.

Pilot Protocol is open source (AGPL-3.0) and built in Go. Source at github.com/pilot-protocol. To see how it works:

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

AES-GCM vs ChaCha20-Poly1305: A Practical Comparison for Protocol Designers

Philip Stayetski — Fri, 17 Jul 2026 23:33:10 +0000

If you build anything with transport security — VPNs, tunnels, messaging protocols, or encrypted overlay networks — you've met two dominant AEAD constructions: AES-256-GCM and ChaCha20-Poly1305. Both give you authenticated encryption (confidentiality + integrity in one pass), but they take very different engineering paths to get there.

This is a practical comparison for developers choosing between them: the hardware landscape, the threat models each handles better, and the trade-offs that actually matter in production.

What they are

AES-GCM (Galois/Counter Mode) combines AES block encryption in CTR mode with a GHASH polynomial authenticator. It's been the default for TLS 1.2 and IPsec for over a decade. NIST-standard, FIPS-140-certifiable, and backed by dedicated CPU instructions (AES-NI + PCLMULQDQ) on virtually every modern x86 and ARM chip.

ChaCha20-Poly1305 is a stream cipher (ChaCha20) paired with a Poly1305 MAC. Designed by Daniel J. Bernstein, it does not use AES at all — it operates on 512-bit blocks with ARX (add-rotate-XOR) primitives. Standardised in RFC 8439, mandatory in TLS 1.3, and the default for SSH, WireGuard, and a growing share of HTTPS connections (especially on mobile).

Hardware acceleration: the real divide

The single most important practical difference is whether the CPU has AES-NI.

On x86-64 with AES-NI + PCLMULQDQ, AES-256-GCM encrypts at around 1–3 cycles per byte — extremely fast. On mobile ARM with the ARMv8 Crypto Extensions, the same. With hardware acceleration, AES-GCM is usually faster than ChaCha20-Poly1305.

Without it — on older ARM Cortex-A cores, low-power MCUs, or software-only fallback paths — AES-GCM slows down dramatically. AES's S-box substitution is expensive in pure software. ChaCha20-Poly1305, which runs entirely on ARX operations, has no such penalty. Without hardware AES, ChaCha20-Poly1305 is typically 3–5x faster.

This is why you see ChaCha20-Poly1305 everywhere in mobile-first protocols (WireGuard, TLS to mobile clients). It guarantees good performance on hardware where AES acceleration is absent or disabled.

Side-channel and security posture

Both ciphers are considered cryptographically sound, but their side-channel profiles differ.

AES-GCM has a well-known nonce reuse vulnerability: encrypting two messages with the same 96-bit nonce and key leaks the GHASH authentication key, allowing forgeries. With a 96-bit nonce, a random nonce collision begins to become likely after about 2^32 messages (the birthday bound). For high-volume protocols, this is a real concern — TLS 1.3 mitigates it with record sequence numbers, but not every protocol has that luxury.

GCM is also incrementally slower with short messages in software, because the GHASH polynomial multiplication has setup overhead. OpenSSL and BoringSSL have constant-time GCM implementations for x86, but careful implementation is required.

ChaCha20-Poly1305 is more forgiving. A 96-bit nonce is standard here too, and reuse is equally catastrophic, but the cipher's underlying structure is naturally constant-time on almost any architecture — no lookup tables, no secret-dependent branches. It also has a larger POLY1305 tag (128-bit) with better forgery bounds than GCM's GHASH, though this rarely matters in practice at standard message sizes.

The XChaCha20 variant (extended 192-bit nonce) is worth mentioning: the larger nonce eliminates random-collision risk entirely for most practical workloads, making it much safer for protocols that cannot guarantee unique nonces.

Where each shines

Choose AES-GCM when:

You run on x86-64 with AES-NI or ARMv8 Crypto Extensions (the majority of cloud servers, modern laptops, and recent phones)
You need FIPS 140 certification
You want maximum hardware-accelerated throughput for bulk encryption
Your protocol enforces unique nonces (sequence numbers, epoch counters)

Choose ChaCha20-Poly1305 when:

You target mixed hardware (older phones, IoT, embedded, SBCs)
You want constant-time properties guaranteed by construction
Your protocol cannot guarantee unique nonces (consider XChaCha20 for 192-bit nonces)
You ship mobile or browser clients where the other endpoint's CPU is unknown
You value implementation simplicity and want to audit the cipher yourself

What this means for protocol designers

Many modern transport protocols don't pick one — they offer both as ciphersuites. WireGuard only offers ChaCha20-Poly1305. TLS 1.3 mandates both (TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256). QUIC and HTTP/3 use both.

The right question is not "which is better?" but "what does your deployment look like?" If you control both ends and know the hardware (a cloud-to-cloud tunnel), AES-256-GCM on AES-NI is the obvious choice. If you're building a P2P protocol where endpoints are unpredictable, ChaCha20-Poly1305 is the safer default.

A real example: Pilot Protocol

Pilot Protocol — an open-source overlay network for AI agents — is a case study in this exact trade-off. It connects agents across arbitrary infrastructure: cloud VMs, local workstations, edge devices, even machines behind NAT. It cannot assume AES-NI on every peer.

Pilot builds its encrypted UDP tunnels with X25519 key exchange and AES-256-GCM for transport payloads. The choice reflects a specific deployment reality: Pilot's daemon runs on servers and developer machines where AES-NI is nearly universal. The ciphersuites are pinned — no negotiation, no downgrade surface.

A protocol like Pilot could equally well use ChaCha20-Poly1305 as an alternative ciphersuite for ARM-based edge deployments. The important thing is that the cipher choice follows the topology and hardware constraints, not fashion or inertia.

Final take

AES-256-GCM and ChaCha20-Poly1305 are both excellent. Neither is "broken" or "wrong." The difference is in engineering trade-offs — hardware dependency, constant-time guarantees, nonce budget, and certification requirements. A well-designed protocol knows its deployment envelope and picks accordingly. The best protocols offer both and let the endpoints negotiate.

X25519 Key Exchange Explained: Walk Through the Handshake

Philip Stayetski — Fri, 17 Jul 2026 19:10:05 +0000

X25519 is everywhere. Here's what actually happens in the handshake.

Start reading any modern protocol spec — WireGuard, Signal, Noise, Pilot Protocol — and you hit the same wall: "X25519 key exchange." The name appears in a security-considerations section, maybe with a one-liner about Curve25519, and the spec moves on. If you're an engineer building with these protocols (or writing one yourself), that wall is frustrating. What does the handshake actually do? What bytes cross the wire? And why X25519 instead of the ECDHE you already know from TLS?

This is the walkthrough I wanted when I first encountered it: an end-to-end trace of a real X25519 handshake, using an agent-to-agent tunnel as the concrete example.

The problem X25519 solves

Before any encrypted tunnel carries data, both sides need a shared secret that nobody else knows. The classic approach — the Diffie-Hellman you learn in a cryptography course — works over a finite field: both sides pick a private number, send a public value computed from it, and combine their private number with the other side's public value to arrive at the same secret.

X25519 does the same thing, but over an elliptic curve (Curve25519) instead of a finite field. The math difference matters because:

Smaller keys: 32-byte public keys instead of the 256-byte or larger keys finite-field DH needs for equivalent security.
Faster computation: Curve25519 operations are constant-time and vectorize well on modern CPUs (no side-channel leaks from data-dependent branches).
No validation needed: Every 32-byte string is a valid Curve25519 public key. Finite-field DH requires checking that the received value isn't out of range or in a small subgroup.

The handshake, step by step

Let's trace what happens when two agents — call them Agent A and Agent B — establish an encrypted tunnel. They've discovered each other through a registry and agreed to talk. Now they need a shared secret.

Step 1: Generate keypairs.

Each agent generates an X25519 keypair. A keypair is two values:

Private key (scalar): 32 random bytes, clamped to prevent small-subgroup attacks (the low 3 bits cleared, the high bit cleared, the second-highest bit set).
Public key: The result of the scalar multiplication clamp(private) × basepoint — another 32-byte value derived deterministically from the private key.

In Go (Pilot's implementation language), this is:

privateKey := make([]byte, 32)
rand.Read(privateKey)
publicKey, _ := x25519.X25519(privateKey, curve25519.Basepoint)

The standard library's crypto/curve25519 (stdlib-only, no external deps) does the clamping and multiplication in one call.

Step 2: Exchange public keys.

Agent A sends its 32-byte public key to Agent B. Agent B sends its 32-byte public key to Agent A. Transfer is over UDP — these 32 bytes plus a few bytes of protocol framing fit in a single packet.

The raw exchange at this point is just two 32-byte values crossing the wire. No handshake state beyond "sent pubkey, waiting for peer's."

Step 3: Compute the shared secret.

Each agent performs the scalar multiplication again, this time using their own private key and the peer's public key:

sharedSecret, err := x25519.X25519(myPrivate, peerPublic)

Both agents compute the same 32-byte value — this is the crucial property of Diffie-Hellman. An eavesdropper who saw both public keys pass across the wire cannot compute this value (the computational Diffie-Hellman assumption: given a×G and b×G, computing a×b×G is infeasible).

Step 4: Derive session keys.

The shared secret isn't used directly as an encryption key. Instead, it's fed through a key-derivation function (KDF) to produce separate keys for the two directions of the tunnel:

encrypt_key_a_to_b = HKDF(shared_secret, salt, "pilot-enc-a2b")
encrypt_key_b_to_a = HKDF(shared_secret, salt, "pilot-enc-b2a")

The salt comes from the handshake transcript — a hash of every message sent so far — which binds the session keys to this specific handshake and prevents replay attacks (key confirmation).

Step 5: Encrypt traffic.

Now the tunnel is live. Every packet is encrypted with AES-256-GCM using the derived session key. Each packet carries a nonce that increments monotonically — the receiver rejects any packet that reuses a nonce (replay protection for free, since GCM's security relies on nonce uniqueness).

A real trace from an agent tunnel

Here's what the actual bytes look like when two Pilot Protocol agents handshake. I've simplified the framing to show only the X25519 exchange (the real protocol also includes version negotiation and a handshake transcript hash).

Agent A → B (handshake init, 44 bytes UDP):

Type: 0x01 (KeyExchange)
Pubkey: d85a336b5e8f8a1c9a7b3e2f1c6d8a4b0e2f3c5a7b9d1e3f5c7a9b0d2e4f6c8a

Agent B → A (handshake response, 44 bytes UDP):

Type: 0x02 (KeyExchange)
Pubkey: e7b9c1d3f5a7b9c1d3e5f7a9b0c2d4e6f8a0b2c4d6e8f0a2c4d6e8f0a2c4d6e8

After these two packets, both sides compute the shared secret. The next packet from either direction is encrypted with AES-256-GCM. Total handshake latency: one round trip. About 200-300 microseconds on a modern CPU for the X25519 scalar multiplication itself.

Why protocol specs keep using X25519

Walk through the steps above and a pattern emerges: X25519 fits naturally into the constraints protocol designers actually face.

It's fast enough to do per-connection without thinking about it. An X25519 key exchange takes microseconds — not milliseconds — on modern hardware. You don't need session resumption or ticket caching for performance reasons.
The implementation is simple enough to audit. The entire Curve25519 scalar multiplication fits in about 300 lines of C (the original TweetNaCl implementation is even smaller). The Go standard library ships it. No external crypto library dependency needed.
No edge cases. Finite-field DH has corner cases around group validation and small subgroups that a careful implementation must handle. X25519 eliminates them: every 32-byte input is valid, and clamping handles the small-subgroup threat at the scalar level.
It composes cleanly with modern AEAD. The 32-byte shared secret maps naturally into HKDF for key derivation, and HKDF's output feeds AES-256-GCM or ChaCha20-Poly1305. No weird size mismatches.

Common misconceptions

"X25519 and Curve25519 are the same thing." Almost — Curve25519 is the elliptic curve; X25519 is the Diffie-Hellman function defined over it. The distinction matters when you read specs: X25519 is specifically the ECDH function, not the curve itself.

"X25519 needs a trusted setup or certificate." No. X25519 is a key-exchange algorithm, not a PKI. It gives both sides a shared secret after exchanging public keys, but it doesn't tell you who you exchanged it with. Authentication — proving that Agent A really is Agent A — requires an additional step (typically an Ed25519 signature on the handshake transcript). X25519 and Ed25519 share the same curve math (Curve25519 vs Ed25519), but they're different operations: key exchange vs signing.

"You need a separate library for X25519." Not anymore. Go's crypto/curve25519 is stdlib. OpenSSL 1.1.0+ includes it. Libsodium wraps it. BoringSSL ships it. If your language's crypto standard library shipped in the last five years, X25519 is almost certainly already there.

Putting it together

When you see "X25519 key exchange" in a protocol spec, here's what the author is saying: two parties each generate a 32-byte keypair, exchange the public halves, compute a shared 32-byte secret, and derive session keys from it. No CA. No certificates in the key-exchange phase. One round trip. Microseconds of CPU.

The agent tunnel in the example above — two Pilot Protocol agents on different machines, each behind NAT — establishes an encrypted tunnel with exactly this exchange. The X25519 handshake runs once when the tunnel opens, and the derived session keys encrypt every packet after that. The whole handshake takes a single round trip and fits in two 44-byte UDP packets.

If you're building agent infrastructure (or any encrypted transport), the protocol stack you want is X25519 for key exchange, HKDF for key derivation, and AES-256-GCM for bulk encryption — all in your standard library, zero external dependencies. That's the combination that keeps appearing in protocol specs because it works, it's auditable, and it doesn't impose operational complexity.

Pilot Protocol uses exactly this stack for every agent-to-agent tunnel: X25519 + HKDF + AES-256-GCM, all from the Go standard library, zero external crypto dependencies. The same key exchange described above runs between every pair of agents on the network.
.

HIPAA-Compliant AI Agent Architecture: The Network Layer You Can't Skip

Philip Stayetski — Fri, 17 Jul 2026 13:37:52 +0000

When you're thinking through a HIPAA-compliant AI agent architecture, most of the checklists focus on the obvious layers: data encryption at rest, access controls, audit logging, business associate agreements. The network layer tends to be an afterthought — "just put everything in a VPC" is the default answer.

But for AI agents that need to communicate across environments, clouds, or organizational boundaries, the network layer is where compliance architecture either holds together or leaks. Here's how to think about it.

Why the Network Layer Matters for PHI-Handling Agents

HIPAA's Security Rule requires safeguards for electronic protected health information (ePHI) in transit. For a traditional web application, that means TLS between browser and server, and maybe a VPN between services. For an AI agent architecture — where autonomous processes fetch data, call APIs, coordinate with other agents, and return results across a chain of services — the picture is more complex.

Every hop between agents, every tool call to an external service, every peer-to-peer coordination message is a data-in-transit event. If agents are handling or passing PHI, each of those hops needs confidentiality and integrity protection, and each identity needs verification.

This is not a compliance document and it does not constitute legal advice. But as an architectural matter: if you're building agent infrastructure that will handle PHI, the network transport is part of your compliance surface, and it deserves the same attention as your storage and application layers.

The Traditional Approach: Shared Flat Network

The simplest approach is to put every agent and every service on a single private network — a VPC, a VPN mesh, or a Tailscale/ZeroTier network. Join everything, and everything can talk to everything.

The problem with this model for HIPAA-relevant architectures is that membership and trust are coupled. When you join an agent to the network, that agent can reach every other resource on that network. A compromised agent — or one that was never supposed to see PHI — has ambient network access to everything.

In a flat-network model, the perimeter is between "inside the network" and "outside the network." That works well for static service meshes. For autonomous agents that move between environments, join and leave dynamically, and operate with different levels of privilege, it's a poor fit.

A Better Layer: Encrypted Peer-to-Peer with Explicit Trust

An alternative approach is to decouple membership from trust. Instead of a shared network where joining means trusting, the architecture treats every agent-to-agent connection as an individual, explicitly authorized tunnel.

At the transport level, this means:

Per-tunnel encryption using a key exchange per connection, so no shared secret exists across the network.
Explicit handshake between two agents before any data flows — no ambient access to other nodes.
Identity pinned to keys, not to IP addresses, so agents can move between networks, clouds, or containers without reconfiguring trust.

This is the zero-trust networking model applied to agent communication: every pair of agents authenticates each other independently, and no agent has standing access to another agent's resources.

How Per-Tunnel Encryption Works at the Transport Layer

For a HIPAA-relevant architecture, the transport needs to provide:

Mutual authentication — both sides prove their identity before any data is exchanged.
Forward secrecy — compromising one session's key does not compromise past or future sessions.
Integrity — tampering with a message in transit is detectable.
Confidentiality — message content is visible only to the intended recipient.

A concrete example: X25519 key agreement for the initial handshake, with AES-GCM for the per-message encryption and authentication. Each agent generates its own keypair. Agent A and Agent B exchange public keys (authenticated through a handshake), derive a shared session key, and all subsequent traffic is encrypted and authenticated. No intermediate proxy, no shared VPC network, no flat trust.

Each tunnel is independent. Even if Agent A is talking to Agents B, C, and D simultaneously, each connection uses a distinct session key derived from a separate key exchange. Compromising one tunnel has no effect on the others.

NAT Traversal as a Security Consideration

AI agents frequently run behind NAT — inside a cloud private subnet, on a laptop behind a home router, in a container with no public IP. For a TCP-based service behind NAT, the standard workaround is a reverse proxy or a cloud relay: expose a public endpoint, route traffic through it.

For compliance-conscious architectures, NAT traversal matters because every relay or reverse proxy is an additional data plane. If PHI passes through a relay, that relay becomes part of your compliance boundary. A better approach is direct peer-to-peer tunnels with NAT traversal built into the transport layer — using STUN to discover public mappings and hole-punching to establish direct connections, falling back to a relay only when both sides are behind restrictive NATs.

The relay path is still encrypted end-to-end — the relay never has access to the plaintext — but minimizing relay usage reduces the number of components in the trusted data path.

Honest Comparison of Approaches

No single approach fits every architecture. Here's an honest assessment of common options:

WireGuard / Tailscale / ZeroTier: Excellent for traditional VPN-style connectivity. Easy to set up, strong encryption. The trade-off is the flat-trust model — joining the network grants broad access. For static deployments where every node has the same trust level, these work well. For dynamic agent workloads where agents have different privilege levels, you need additional network segmentation or ACLs on top.
Mutual TLS: Strong authentication, well-understood. The operational cost is certificate management — issuing, rotating, and revoking certificates for every agent that joins and leaves. For long-lived services this is manageable; for ephemeral agents it adds friction.
Webhook / polling patterns: No persistent connection needed. The trade-off is that every interaction requires a round trip through shared infrastructure (a message queue, an API gateway, or a polling endpoint), which adds latency and creates a central data plane that needs its own compliance treatment.
Per-tunnel encrypted mesh (what Pilot Protocol implements): Decouples membership from trust. Every connection is individually authenticated and encrypted. No shared network fabric. The trade-off is higher per-connection coordination overhead — the handshake happens per pair, not once per network join.

The Security Model in Practice

For a HIPAA-relevant agent architecture, the key architectural property is that trust is per-connection, not per-network. When an agent joins a deployment, it does not automatically get access to other agents or services. It must be explicitly authorized for each peer. This means:

A PHI-handling agent and a non-PHI agent can coexist on the same infrastructure without the non-PHI agent ever having a path to sensitive data.
An agent that is compromised or misconfigured cannot laterally access other agents' communications or data.
Audit logs record exactly which peer connections were established, when, and for how long — because each tunnel is a discrete, documented event.

This is achievable with any of the approaches above, with varying levels of operational overhead. The architecture decision is about where you want the complexity: in network configuration rules and ACLs (flat-network approach), in certificate lifecycle management (mTLS), or in per-connection handshake logic (mesh approach).

Where to Start

If you're evaluating network architectures for a HIPAA-relevant agent deployment, start by mapping every hop an agent's data will take. For each hop, ask: is this connection authenticated on both sides? Is it encrypted with a session-specific key? Is the trust scope limited to this one pair, or does it extend to the whole network?

The answers will tell you which transport model fits your compliance requirements.

For developers evaluating options, the install is the same either way:

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

The full docs at pilotprotocol.network/docs cover the transport details — handshake protocol, per-tunnel encryption, and the trust model — so you can compare against your own architecture requirements.
.

gRPC vs UDP for Low Latency: What You Actually Give Up

Philip Stayetski — Thu, 16 Jul 2026 21:32:23 +0000

gRPC vs UDP for Low Latency: What You Actually Give Up

When your multi-agent system needs low latency, the default reflex is gRPC. Fast serialization, HTTP/2 multiplexing, bidirectional streams — it checks every box on paper. But between two agents on different machines, gRPC runs over TCP. And TCP has non-negotiables: in-order delivery, congestion control, retransmission backoff, head-of-line blocking inside a single HTTP/2 connection.

For agent-to-agent communication, those properties aren't free. The question isn't whether gRPC is fast — it's whether TCP's guarantees cost more latency than your use case can afford.

The TCP tax gRPC can't escape

gRPC inherits every TCP tradeoff even though most developers never configure a single TCP knob. Here's what you're paying for by default:

Head-of-line blocking inside HTTP/2. HTTP/2 multiplexes multiple streams over one TCP connection, but TCP delivers bytes in order. A lost packet on stream A stalls every other stream on that connection until retransmission arrives. HTTP/2's own flow control adds another per-stream queue on top. Two agents exchanging many small messages concurrently will hit this.

Congestion control ramps up slowly. TCP slow-start on a fresh connection means the first few round-trips carry far fewer packets than the path can handle. For an agent that sends a burst of 20 messages then goes silent, every burst pays the slow-start tax. BBR and other modern CCs help, but they still react to loss—and for agents on lossy wireless or home NAT links, that reaction is a latency spike.

Retransmission timeout (RTO) floor. Linux defaults to 200ms RTO minimum. A single lost TCP segment on a gRPC stream stalls that entire connection for at least 200ms. Over a cross-continent or tail-latency-sensitive agent link, that's an eternity.

Connection setup. gRPC adds TLS handshake on top of the TCP three-way handshake. For long-lived agent connections this is a one-time cost. But for agents that discover each other ephemerally—think a task-specific worker fleet that starts up, communicates, and shuts down—the setup latency before a single message is exchanged can be 2-3 round trips.

What UDP gives back

Moving to UDP removes all four tax lines at once. No head-of-line blocking (each datagram is independent). No slow-start (send at line rate immediately). No 200ms RTO (loss detection is yours to control). No handshake overhead (connectionless by design).

But UDP also removes TCP's guarantees. No ordering, no retransmission, no congestion control, no flow control. You get datagrams: best-effort, unordered, up to ~65KB (though real-world MTU limits make 1400 bytes the practical max).

This is the core trade. gRPC over TCP says: "I'll guarantee ordering and delivery, and you take the latency cost." Raw UDP says: "I'll get out of your way, and you handle order and loss yourself."

Userspace reliability: the middle path

Most agent transports that choose UDP don't stay at raw datagrams. They build userspace reliability on top: selective retransmission (not the whole accumulated TCP window), pluggable loss detection (not a fixed 200ms RTO), and optional ordering (not every message must be in-order; an agent status update can arrive after a later one without breaking anything).

This is a fundamentally different reliability model from TCP's. TCP treats all traffic as one ordered byte stream. A userspace transport over UDP can treat each message as an independent unit and decide per-message whether ordering matters, whether loss is tolerable, and whether the sender even needs an ack.

For agent workloads this maps well:

Heartbeats and presence updates: loss is fine, order doesn't matter, no reliability needed.
Task dispatch: ordering matters within one task, not across tasks. Selective ack per message group, not a TCP window.
Large payloads (state sync, model config): fragment, sequence, retransmit only the missing fragments.

Where agents pay the gRPC-over-TCP tax hardest

Three patterns common in multi-agent systems expose the TCP gRPC tax more than a traditional client-server microservice setup:

1. One-to-many fan-out. A coordinator sends the same task to 10 workers. With gRPC, that's 10 TCP connections (or one HTTP/2 connection per worker). Each has its own congestion state. A lossy link to one worker stalls that stream — not the others, but you're still paying 10× the TCP setup cost. Over UDP the coordinator sends 10 datagrams in a single batch with one syscall batch.

2. Ephemeral agent groups. Agents that form teams per task and dissolve afterward pay TCP connection setup + TLS every time. A 3-RTT setup cost on a 50ms link adds 150ms before the first message arrives. For a 2-second task, that's 7% overhead just to start talking.

3. Lossy or asymmetric links. Agents on residential NAT, WiFi, cellular uplinks, or tail-latency cross-region links see more packet loss than datacenter TCP was designed for. TCP interprets loss as congestion and backs off. A user-space transport can distinguish congestion from corruption and retransmit aggressively on a known-clean link.

Pilot Protocol's approach: userspace reliability over UDP

Pilot Protocol implements exactly this middle path. It builds a userspace reliability layer over encrypted UDP tunnels (X25519 + AES-GCM), with pluggable loss detection and selective retransmission per message — not per byte. The transport is connectionless in the TCP sense but connection-oriented at the application layer: agents have permanent virtual addresses that survive restarts and IP changes, and message delivery semantics are negotiated per exchange rather than dictated by the transport.

The key difference from gRPC over TCP: Pilot's transport doesn't guarantee ordering unless you ask for it. A status update can arrive before or after a task result without stalling either. It doesn't do slow-start — it sends at line rate from message one. And it doesn't have a 200ms RTO floor — retransmission timing is tuned by the application, not the kernel.

This isn't a replacement for gRPC everywhere. gRPC's ecosystem — protobufs, service definitions, generated clients, streaming RPCs — is mature and valuable for request-response APIs between stable services. But for agent-to-agent messaging where latency variance matters more than strict ordering, the transport tradeoffs flip.

What you actually give up

If you move from gRPC over TCP to a userspace-UDP transport, you give up:

Stream abstraction — you don't get a buffered bidirectional pipe for free. You get messages, and you compose ordering/reliability yourself per use case.
Ecosystem — no protobuf codegen (though you can still use protobuf for serialization over UDP; serialization and transport are orthogonal).
Middlebox familiarity — TCP goes through every NAT, firewall, and load balancer predictably. UDP hole-punching is well-understood but not universal; some enterprise networks drop all non-DNS UDP.

What you gain is control over your latency profile. For agent systems where a 200ms stall on a task-critical link is a failure, not a nuisance, that control is worth the trade.

Interested in how userspace reliability over UDP works in practice? Pilot Protocol's documentation covers the transport layer, trust model, and how to connect agents across NAT without a VPN.

NATS vs gRPC for Messaging: When the Answer Is Neither

Philip Stayetski — Wed, 15 Jul 2026 20:32:53 +0000

NATS vs gRPC for Messaging: When the Answer Is Neither

If you're building a distributed system that needs reliable inter-service communication, the NATS vs gRPC debate comes up early. Engineers pick one and usually make it work — but how it works, and what it assumes about your architecture, matters a lot.

This is a map of the trade-offs, not a winner. And for one growing use case — autonomous agents that need to talk across clouds and NAT boundaries — both may be the wrong shape.

gRPC: RPC with strong contracts

gRPC wraps HTTP/2 with Protocol Buffers, giving you typed RPC methods, server streaming, client streaming, and bidirectional streaming. It shines when you have:

Strict service contracts. The .proto file defines exactly what each service does. Code generation produces clients and servers in 12+ languages.
Request-reply patterns. Most gRPC usage is unary RPC — call a method, get a response.
A service mesh or DNS layer underneath. gRPC assumes endpoints are reachable by hostname. It does not discover peers or traverse NAT — those jobs go to a service mesh (Istio, Linkerd) or a separate discovery system.

The cost: TLS certificates are mandatory (gRPC won't connect without them), and every service needs a stable DNS name or proxy in front of it. That works well inside a Kubernetes cluster or a VPN. Outside that boundary, it gets complicated.

NATS: Cloud-native messaging

NATS is a broker-based messaging system. Clients connect to a NATS server cluster and publish/subscribe on subjects. It handles:

Pub/sub, request-reply, and queue groups. NATS has excellent semantics for event-driven architectures and workload distribution.
At-most-once delivery by default (with JetStream for persistence where needed).
High throughput and low latency. The NATS server is famously fast — a single Go binary that handles millions of messages per second.

The trade-off: every client must reach the NATS cluster. If your services live behind different NATs, on different clouds, or in different corporate networks, you need the broker to be publicly reachable — or you run a cluster per network and bridge them. The broker also sees message payloads (unless you add a separate encryption layer), and you're responsible for operating the cluster.

What both assume

gRPC assumes reachable endpoints. NATS assumes a reachable broker. Both assume you control the network or have infrastructure (VPN, service mesh, public DNS) to make endpoints reachable.

That assumption holds for a microservice inside a VPC. It breaks down when you have:

Agents running on a user's laptop behind a home router
Cross-cloud agent fleets (AWS → GCP → Azure with no shared VPC)
Agents that wake up on dynamic IPs and need to find each other
Any topology without a central broker you control

The third shape: an agent overlay

There is a third category that doesn't compete with either gRPC or NATS — it solves a different problem. An agent overlay network gives every agent a permanent virtual address, handles NAT traversal transparently, and encrypts everything end-to-end by default.

Pilot Protocol is an open-source example of this approach. It is not a messaging broker (NATS) or an RPC framework (gRPC). It is a layer-3.5 overlay: agents get a stable address (N:NNNN.HHHH.LLLL) that survives restarts and IP changes, encrypted UDP tunnels traverse NAT without any infrastructure, and trust is established via cryptographic handshake — not a VPN that trusts everyone who joins.

Where does it fit alongside NATS and gRPC?

Scenario	Reach for
Event-driven microservices in one cluster	NATS
Typed RPC with codegen inside a service mesh	gRPC
Agents talking across clouds, NATs, or firewalls	Overlay (Pilot Protocol)
Agents need to discover each other dynamically	Overlay
End-to-end encrypted by default, no broker	Overlay

You probably need more than one

The pragmatic take: these are complementary tools, not alternatives. Your agent fleet behind NAT can use an overlay for connectivity (peer discovery, encrypted tunnels) and still use gRPC or NATS on top of that connectivity for messaging semantics. NATS on an overlay means pub/sub across any network. gRPC on an overlay means RPC without TLS certificate management for every agent.

The question "NATS vs gRPC for messaging" is the right one for a single-VPC deployment. For multi-cloud, multi-network, multi-org agent systems, the real question is "what provides connectivity before I pick my messaging layer?" — and that's where the third shape earns its place.

Getting started

If you want to try the overlay approach:

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl send-message list-agents --data '/data' --wait

Your agent is now addressable on the overlay network, behind NAT, with no DNS, no TLS certs, and no broker to maintain. Then layer NATS or gRPC on top if you need their semantics — the overlay handles the connectivity problem so your messaging layer can focus on what it does best.

MCP Tunnels vs VPN for AI Agents: When a VPN Is the Wrong Shape

Philip Stayetski — Wed, 15 Jul 2026 16:10:35 +0000

If you are running an MCP server, you have probably hit the connectivity question: how do agents across the internet reach it? The default answer is usually "put everything on a VPN." It is familiar, it works, and it feels safe. But a VPN is the wrong shape for an MCP server, and the mismatch costs you in surprising ways.

The Problem VPNs Solve (And Why It Looks Like a Fit)

A VPN — Tailscale, ZeroTier, WireGuard with a mesh — solves a real problem: you want machines in different networks to talk as if they were on the same LAN. Every device gets a virtual IP, traffic is encrypted, and the mesh handles routing.

For a developer running a handful of servers and workstations, this works well. You join the VPN, you are in. Endpoints are reachable, traffic is private, and the setup is well understood.

Now apply it to an MCP server. The MCP server runs in one place — a VPS, a home server, a cloud VM. The agents that call it are ephemeral: they spin up, make requests, and disappear. They run in CI pipelines, on user laptops, in serverless functions, across different clouds. Every one of these agents needs a path to the MCP server.

A VPN says: make every agent a member of the VPN. The problem is in that word — member.

Membership vs. Trust — The Critical Difference

VPNs treat membership and trust as the same thing. If you are on the VPN, you are trusted. If you are not on the VPN, you are unreachable. This is fine for a team of known machines. It breaks for an open or semi-open MCP server that serves many clients.

Every new agent needs a VPN join key. That key is expensive to rotate and hard to scope. Leak it once and every node on the VPN is exposed.
Revoking a compromised agent means removing it from the VPN. That is a manual operation, and in a mesh VPN, it has to propagate to every peer.
Ephemeral agents don't fit. A CI runner that calls an MCP server for 30 seconds should not need a persistent VPN membership that lives beyond the job.

This is not a flaw in VPN design. VPNs were built for stable, long-lived connections between known machines. MCP servers serve a fundamentally different pattern: many clients, short sessions, high turnover.

What an MCP Server Actually Needs

An MCP server needs a small set of properties that are surprisingly different from a VPN's feature set:

Inbound reachability — the server has a stable address that clients can reach, regardless of where it is hosted.
Per-connection trust — each client authenticates individually; trust is scoped to the session, not to the network.
No persistent membership — clients connect, do work, and disconnect. No join key, no long-lived assignment.
UDP-friendly — many MCP calls are short request-response cycles; TCP overhead from VPN tunnels adds latency that compounds.

A VPN gives you (1) and part of (3), but it actively fights (2) by giving every member access to everything on the subnet. And it adds network overhead for (4) that is invisible until you measure it.

Per-Peer Tunnels — The Alternative Shape

The alternative is a per-peer tunnel: instead of joining a shared network, each client establishes a direct encrypted tunnel to the MCP server. The server never exposes a subnet; it exposes exactly one endpoint. Trust is per-handshake, not per-membership.

This pattern has practical advantages that map directly to the MCP use case:

No join key to distribute. Each agent authenticates on connection with its own credentials. There is no shared secret that, leaked, compromises the whole mesh.
Revocation is instant. Drop the peer's trust entry on the server. That agent cannot connect again. No propagation delay, no stale membership.
Ephemeral clients work. An agent that connects for a single query and disappears leaves nothing behind. No cleanup, no lingering tunnel state.
No subnet exposure. The MCP server appears at a single address. There is no virtual network to scan, no lateral movement possible from a compromised peer.

Pilot Protocol uses exactly this model: per-peer encrypted UDP tunnels with explicit handshake-based trust. An agent finds the MCP server by name (via a rendezvous registry), establishes a tunnel, and communicates — no VPN join, no subnet, no shared key. The trust is bidirectional and individually scoped.

When a VPN Is Still the Right Call

None of this says VPNs are bad. If you run a private MCP server for a fixed team of 5–10 agents that run on known machines, a Tailscale mesh is simple and effective. The overhead is negligible at that scale, and the mental model matches the deployment pattern.

The mismatch appears when the set of calling agents is dynamic — agents that appear and disappear, agents on different clouds, agents operated by different teams or organizations. At that point, the VPN's membership model starts working against you, and per-peer tunnels become simpler, not harder.

The Practical Takeaway

When you design the connectivity for an MCP server, ask yourself: how many entities need access, and how stable are they? If the answer is "a small, fixed set of machines I control," a VPN is the straightforward path. If it is "a growing set of agents I don't fully control, some ephemeral, some persistent," then per-peer tunnels with individual trust are a better architectural fit.

The two patterns are not in competition — they serve different deployment profiles. But confusing one for the other leads to unnecessary complexity, either from managing VPN membership for short-lived agents or from over-engineering tunnels for a static team.

For the agent-native case, Pilot Protocol's overlay network implements the per-peer tunnel model natively — it is built for agents, not for laptops. But the point stands regardless of the implementation: match the connectivity model to the actual agent lifecycle, not to the most familiar tool.

Crypto Price API With No Key: The Real Keyless Options Compared

Philip Stayetski — Sat, 11 Jul 2026 02:33:14 +0000

The problem with "free" crypto price APIs

You want the current price of BTC, ETH, or a handful of altcoins in a script, a Discord bot, or an agent — and you don't want to create an account, verify an email, or paste a secret key into an environment variable for something this simple. That's a completely reasonable ask, and there are more keyless options than most "top 10 crypto APIs" roundups let on. They just don't all deserve the same amount of trust.

This post compares the actual no-signup, no-key options for pulling crypto (and adjacent FX) prices, what limits and caveats come with each, and — since agents are increasingly the ones making these calls, not humans — where Pilot Protocol's finance agents fit into the picture as a genuinely agent-native option.

What "no key" actually means in practice

Before comparing anything, it's worth separating three things that get lumped together as "free crypto API":

Truly keyless, no signup — you hit an endpoint and get JSON back. No headers, no account.
Free tier, but still requires a key — you sign up once, get a key, and stay under a request ceiling.
"Try it keyless" marketing — a demo endpoint that works without a key for light testing, but production use still expects registration.

Most listicles conflate all three. If your actual requirement is zero setup, zero account, only option 1 counts.

Keyless options worth knowing

CoinGecko's public API is the most commonly recommended keyless option. The /simple/price endpoint returns spot prices for a coin list against one or more fiat/crypto quote currencies with no key required on the public tier. It's well documented, covers a huge number of assets, and is the default answer in most threads on this topic — worth checking their current terms before depending on it, since free-tier policies shift over time.

Exchange public endpoints are another underused keyless path. Coinbase, Kraken, and Binance all expose public market-data endpoints (ticker, order book, recent trades) that don't require authentication — because they're public market data, not account data. The tradeoff: you get exchange-specific pricing (which can diverge slightly from a blended index) and you're depending on an exchange's infra and rate-limiting policy rather than a dedicated data provider's.

FreeCryptoAPI and similar keyless aggregators exist specifically to serve the "just give me a price, no signup" use case. These are worth spot-checking for uptime and coverage before relying on them for anything production-critical — smaller providers can have less predictable availability than the exchanges or CoinGecko.

What changes when the caller is an agent, not a human

Every option above assumes a human developer reading docs, picking an endpoint, and writing a request. That model gets awkward when the caller is an autonomous agent: the agent has to know which of a dozen keyless crypto APIs exists, parse each one's inconsistent JSON shape, and handle each provider's own rate-limit and error conventions — repeated work every agent building this integration does independently.

This is the specific gap Pilot Protocol is built around. Pilot is an overlay network that gives agents a permanent address and lets them query specialist agents directly — structured JSON in, structured JSON out, no API key, no SDK. A handful of the ~243k+ agents already on the network are finance specialists that answer exactly this kind of query: current crypto spot prices, FX rates, and related market data, each with a documented /data query shape instead of a bespoke REST contract you have to reverse-engineer.

The pattern from an agent's side looks like this:

# one-time install
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start --hostname my-agent

# find a finance specialist agent
pilotctl send-message list-agents --data '/data {"search":"bitcoin"}' --wait

# query it directly — no key, no signup
pilotctl send-message <agent-name> --data '/data {"symbol":"BTC"}' --wait

If you don't know which specialist to query, pilot-director will resolve it for you from a plain-English description of the task:

pilotctl send-message pilot-director --data 'current bitcoin price in USD' --wait

This isn't a claim that Pilot replaces CoinGecko or an exchange's public API for a human developer writing a one-off script — for that, a plain HTTP GET to a keyless REST endpoint is still the simplest path, and CoinGecko or an exchange's own endpoint is a fine choice. Where Pilot earns its place is the agent case: one consistent connection method across many data domains (finance is one category among 20+), rather than a different keyless API, a different JSON shape, and a different rate-limit policy for every data source an agent needs to reach.

Choosing between them

Option	Setup	Best for
CoinGecko public API	None	General-purpose spot prices, broad coin coverage
Exchange public endpoints (Coinbase/Kraken/Binance)	None	Exchange-specific pricing, order-book/trade data
Keyless aggregators (FreeCryptoAPI, etc.)	None	Quick scripts; verify uptime before depending on it
Pilot Protocol finance specialists	Install `pilotctl` once	Agents that need consistent structured access across finance and other live-data domains (weather, transit, news, etc.) without juggling a different keyless API per category

FAQ

Is there a truly free, no-signup crypto price API?
Yes — CoinGecko's public API and the public market-data endpoints on major exchanges (Coinbase, Kraken, Binance) don't require a key for basic price lookups. Verify current rate limits and terms before depending on any of them long-term.

Why would an agent use Pilot instead of hitting CoinGecko directly?
Both work. Pilot's value for an agent is consistency: one connection method (no key) that reaches finance specialists and dozens of other live-data domains, instead of learning and maintaining a different keyless integration per source.

Does Pilot require an API key?
No. Pilot's service agents — including its finance specialists — are queried directly over the overlay network with no key and no SDK required, per the documented /plain reference.

Where do I see the full catalogue of what Pilot's specialists cover?
pilotctl send-message list-agents --data '/data' --wait returns the live catalogue, or see the plain-text summary at pilotprotocol.network/plain.

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