Forem: Calin Teodor

Deploy Agents Across AWS, GCP, and Azure. No VPN.

Calin Teodor — Thu, 19 Mar 2026 22:00:00 +0000

Your agents run on AWS. Your partner's run on GCP. The compliance team's models are on Azure. Getting them to talk means VPC peering, transit gateways, cross-cloud VPNs, security group rules, and a networking team that does not have bandwidth until next quarter.

Or two commands:

curl -fsSL https://raw.githubusercontent.com/TeoSlayer/pilotprotocol/main/install.sh | sh
pilotctl daemon start --hostname my-agent

The agent registers with the rendezvous server, STUN discovers its public endpoint, and it is reachable by any other Pilot agent regardless of cloud provider, region, or VPC.

Cross-cloud networking is hard because every provider does it differently. AWS VPCs, GCP VPCs, and Azure VNets use private IP ranges that may overlap. Security Groups, Firewall Rules, and NSGs each have different syntax. Cloud NAT, NAT Gateways, and Azure NAT Gateway all behave differently. Cross-region egress adds up fast through VPN gateways. Companies spend months building hub-and-spoke architectures so agents can exchange JSON.

Pilot does not care about the underlying network. Every agent gets a virtual address that sits above the physical topology. The overlay handles address translation, NAT traversal (STUN + hole-punching + relay), encryption (X25519 + AES-256-GCM on every packet), and per-agent-pair trust (Ed25519 mutual handshakes — not flat network access like a VPN).

An agent migrates from us-east-1 to eu-west-1? Same virtual address. Peers do not notice. An agent moves from AWS to a developer's laptop for debugging? Same address. Same tunnel. No configuration change.

The same pattern works across organizations. No shared cloud accounts, no shared VPNs, no shared anything. Each side runs Pilot independently. Trust is scoped per agent pair with justification messages. Revoke one partner agent without tearing down a VPN tunnel. The blast radius is one connection, not the entire cross-org network.

52% of the 626 OpenClaw agents that autonomously joined the network were behind NAT. None configured port forwarding. They just worked.

pilotprotocol.network · GitHub

A2A Agent Cards Are Useless Behind a Firewall. Fix Them.

Calin Teodor — Wed, 18 Mar 2026 22:00:00 +0000

Google's A2A protocol publishes Agent Cards at /.well-known/agent.json. The specification defines JSON-RPC over HTTP and Server-Sent Events for streaming. It assumes both agents have publicly reachable HTTP servers.

Put the agent behind a corporate NAT, a cloud VPC, or a developer's laptop. The Agent Card advertises a URL nobody can reach. The agent does not exist on the A2A network.

The same gap exists in MCP. Remote MCP servers require a URL that clients can connect to. Behind NAT? Unreachable. The remote transport is HTTP with SSE.

The fix is not another application protocol. It is a network layer that makes the existing protocols work where they currently cannot.

A2A defines what agents say — capabilities, task lifecycle, streaming results. Pilot Protocol defines how agents reach each other — addressing, NAT traversal, encrypted tunnels. They solve different problems at different layers.

Run A2A agent cards over Pilot tunnels: the Agent Card advertises a Pilot address alongside (or instead of) an HTTP URL. The client connects via the overlay network — automatic three-tier NAT traversal, no public IP required. JSON-RPC task requests flow over the encrypted tunnel. The A2A semantics are identical. Only the transport changes.

An agent behind a home router talks to an agent behind a corporate firewall using the same A2A protocol. Because Pilot handles the networking that HTTP cannot.

The same architecture works for MCP. Run MCP servers over Pilot tunnels and they become reachable from anywhere — encrypted by default, with trust-gated access control. No public URL. No TLS certificate management. No ngrok bill.

Cross-company agent collaboration becomes possible without shared infrastructure. Each side runs Pilot independently. Trust is established per agent pair with scoped handshakes. The blast radius is minimal — revoke one partner agent without affecting others.

A2A for semantics. MCP for tools. Pilot for the network. Three layers, each handling what it understands best.

pilotprotocol.network · GitHub

The 15x Token Tax on Multi-Agent Coordination

Calin Teodor — Tue, 17 Mar 2026 22:00:00 +0000

Multi-agent systems that coordinate over HTTP serialize context into JSON, send it as request bodies, parse it on the other end, and feed it back into an LLM. Every message carries HTTP headers, content-type negotiations, and authentication tokens. Every coordination step re-transmits the accumulated context of the entire interaction because HTTP is stateless.

Measurements show this coordination overhead costs up to 15x more tokens than the actual task content.

A three-agent pipeline processing a document: Agent A sends the document + instructions to Agent B (5K tokens). Agent B sends everything + its analysis to Agent C (12K tokens). Agent C sends the full chain back with its contribution (20K tokens). The document was 3K tokens. The coordination overhead was 34K.

At scale, 15x token overhead versus 1x is the difference between cost-effective and prohibitively expensive.

REST polling is even worse. 98.5% of requests return nothing new. You pay for every empty round trip.

Pilot Protocol connections are stateful. They maintain sequence numbers, acknowledgment state, and flow control windows. The tunnel stays open. The encryption context persists. An agent sends a small delta — "anomaly count updated to 48" — instead of re-serializing the entire context. 19 bytes, encrypted, delivered.

WebSockets attempt to solve this but break at scale and still require public endpoints. Pilot's persistent bidirectional tunnels work behind NAT, across cloud providers, with automatic reconnection.

The token tax is not just a cost problem. It is a latency problem (re-serializing context adds processing time), a reliability problem (larger payloads are more likely to fail mid-transmission), and a complexity problem (every agent must implement context management). A stateful transport layer eliminates all four simultaneously.

pilotprotocol.network · GitHub

Hard Numbers: HTTP/2 vs UDP Overlay for Agent Communication

Calin Teodor — Mon, 16 Mar 2026 22:00:00 +0000

Two machines. Two continents. GCP us-east1 (South Carolina) and europe-west1 (Belgium). 85ms RTT. 100 runs per test, median reported. No synthetic benchmarks.

Connection setup: 11x faster.

HTTP/2 requires a TCP three-way handshake (~85ms), TLS 1.3 handshake (~85ms), and ALPN negotiation. Total: ~175ms per connection. Pilot does the expensive work (STUN discovery, tunnel creation) once at daemon startup. Each new connection reuses the existing tunnel. Total: ~15ms.

An orchestrator dispatching tasks to 50 agents: 8.75 seconds of pure overhead with HTTP/2. 750 milliseconds with Pilot.

Message latency: identical where it matters.

At 1 KB (the size of a JSON task description): HTTP/2 172ms, Pilot 171ms. At 10 KB: 174ms vs 172ms. At 100 KB: 182ms vs 179ms. Both protocols are dominated by the 85ms network RTT. The protocol overhead is not the bottleneck. The network is.

At 1 MB, HTTP/2 edges ahead by 2.4% — TCP's 30 years of kernel-level optimization. For the message sizes agents actually send, irrelevant.

Memory at scale: 10x lighter.

100 simultaneous peer connections: HTTP/2 uses 240 MB RSS. Pilot uses 24 MB. All Pilot connections share a single UDP tunnel — no separate TCP socket and TLS session per peer. For agent swarms on resource-constrained VMs, this is running 100 agents vs running 10.

Behind NAT: where it actually matters.

Put one agent behind Cloud NAT. HTTP/2 needs a relay proxy — adding 145ms to setup, 32ms to every message, dropping throughput 31%. Pilot hole-punches through the NAT and establishes a direct tunnel. After the punch: +7ms setup, +2ms per message, 4% throughput loss.

The choice is not "HTTP or Pilot." It is "HTTP where you can, Pilot where you must." And for agents spanning networks, corporate boundaries, and NAT topologies — "where you must" is 88% of the time.

pilotprotocol.network · GitHub

MCP Has 97 Million Downloads. It Still Cannot Connect Two Agents.

Calin Teodor — Sun, 15 Mar 2026 22:00:00 +0000

Anthropic's Model Context Protocol has crossed 97 million monthly SDK downloads. Thousands of MCP servers exist — GitHub, Postgres, Slack, web search, file systems. The tool ecosystem is massive.

But MCP connects agents to tools. It does not connect agents to agents.

An MCP-equipped agent can query any database, call any API, read any file. Delivering those results to a peer agent still requires building your own transport, discovery, and encryption. Each MCP deployment reinvents peer communication with ad-hoc HTTP endpoints, message queues, or shared databases.

Think of agent infrastructure as two axes:

Vertical (MCP). Agent reaches down into systems. Database queries, API calls, file access. The agent talks to tools.

Horizontal (Pilot Protocol). Agent reaches across to peers. Discovery, trust, encrypted tunnels, task delegation, pub/sub events. The agent talks to agents.

MCP gives an agent eyes and hands. Pilot gives it a voice and ears. A fully capable agent needs all four.

The integration runs in a single process with two clients: the MCP client connects to tool servers, the Pilot driver connects to the local daemon. Your application logic coordinates between them:

Receive a research task from a peer via Pilot's task system
Use MCP to query a database
Use MCP to search the web
Produce a summary with your LLM
Return results to the requester via Pilot
Publish a research.completed event so other interested agents are notified

The two clients are independent — different protocols, different endpoints, different lifecycles. Upgrade your tools without changing your network layer.

A Pilot address gives any MCP agent an identity on a peer network. It can be discovered (or stay invisible). It can receive tasks, publish events, exchange data — all over encrypted tunnels that traverse NAT automatically. The tools still work. The LLM still works. You just added collaboration.

pilotprotocol.network · GitHub

CrewAI Exfiltrated Data 65% of the Time. Where Is the Authentication Layer?

Calin Teodor — Sat, 14 Mar 2026 22:00:00 +0000

"We are building Multi-Agent Systems like it is 1995 — where is the authentication layer?"

That question, posted on a developer forum in late 2025, captures the state of agent security precisely. Columbia University researchers tested multi-agent frameworks and found that CrewAI exfiltrated data in 65% of scenarios. Magentic-One executed malicious code 97% of the time when a compromised agent was introduced.

These are not edge cases. These are default outcomes when agent frameworks trust every participant without verification.

The root cause: 45.6% of organizations use shared API keys for agent-to-agent communication. A shared key does not identify a specific agent — it identifies an account. When one agent is compromised, every agent using that key is compromised. Non-human identities now outnumber human identities 100:1 in enterprise environments. Manual credential provisioning does not scale.

Pilot Protocol implements zero trust from the ground up:

Ed25519 identity per agent. Not a username. Not an API key. A cryptographic key pair generated at pilotctl init. The identity is the agent, not a credential attached to it.

Invisible by default. A new agent cannot be discovered, enumerated, or connected to. There is no roster API. A compromised agent can only see peers it was explicitly trusted with — it cannot scan the network.

Mutual handshakes with justification. Both sides prove identity before data flows. The justification is signed and auditable — part of the Ed25519 payload, tamper-proof.

Millisecond revocation. pilotctl untrust deletes the trust pair, tears down the tunnel, and notifies the peer. Atomically. No token cache to expire.

Compare: A2A supports but does not enforce Agent Card signing. MCP relies on OAuth or API keys. Raw REST relies on bearer tokens. None of them make security the default state.

Pilot does not replace these frameworks. It secures the transport layer underneath them. Your orchestration logic stays the same. The difference: every connection is encrypted, every agent is authenticated, and every trust relationship is explicit and revocable.

pilotprotocol.network · GitHub

626 AI Agents Built a Social Network. No Human Told Them To.

Calin Teodor — Fri, 13 Mar 2026 22:00:00 +0000

In February 2026, the Pilot Protocol registry logs showed something we did not plan for. New agents were registering — not one or two, but dozens per day. No human was running commands. No tutorial was being followed.

OpenClaw agents were discovering Pilot Protocol on ClawHub, installing it as a skill, starting daemons, and establishing trust relationships with each other. All autonomously. By February, 626 agents had joined.

Every agent independently converged on the same onboarding sequence: install the skill, start the daemon, register a hostname (data-analyzer-7, code-reviewer-alpha), tag themselves with capabilities (python, ml, code-review), discover peers via tag search, and send trust handshakes with justification messages.

The justifications were not templated. Each agent composed its own: "I am a data analysis agent and I need to coordinate with ML agents for model evaluation tasks." Nobody wrote onboarding instructions. The agents inferred the workflow from the tool semantics.

The resulting network:

626 agents, 1,973 trust relationships
Average 6.3 connections per agent, most connected agent: 39 peers
Clustering coefficient 47x higher than random
Degree distribution follows a power law (gamma = 2.1) — the same pattern as human social networks and the World Wide Web

Five capability clusters formed naturally: data processing, ML/AI, development, research, and infrastructure. No configuration file defined them. They emerged from individual agents making independent trust decisions.

64% of agents established trust with themselves — a self-diagnostics pattern that no documentation recommended. They discovered that self-trust enables loopback health checks. The same pattern human engineers use with localhost testing.

The trust model made it possible. Private-by-default discovery, mutual handshakes with justification, instant revocation. A protocol that exposes every agent by default would not have been safe for unsupervised autonomous operation.

pilotprotocol.network · GitHub

88% of Your Agents Are Unreachable. Here Is Why.

Calin Teodor — Thu, 12 Mar 2026 22:00:00 +0000

88% of networks involve NAT. That number comes from measurements across ISPs, enterprises, and mobile carriers. Behind every NAT, your agent cannot receive incoming connections.

A2A publishes Agent Cards at well-known HTTP endpoints. If that endpoint is behind NAT? The Agent Card publishes a URL nobody can reach. MCP's remote transport requires the server to have a URL clients can connect to. Behind NAT? Unreachable.

The standard workaround is ngrok, Cloudflare Tunnels, or cloud hosting with public IPs. Each one adds cost, latency, and a single point of failure. And with N agents, you need N tunnels and N² potential connections. The cost scales quadratically.

Pilot Protocol takes a different approach. When a daemon starts, STUN discovers the agent's public endpoint automatically. For 75% of NAT types (Full Cone, Restricted Cone, Port-Restricted Cone), coordinated hole-punching establishes a direct peer-to-peer tunnel. The beacon coordinates simultaneous UDP packets from both sides, creating NAT mappings that allow direct traffic.

After hole-punching, the connection is indistinguishable from a direct connection. No relay in the data path. No added latency.

The remaining 25% (Symmetric NAT) falls back to encrypted relay through the beacon — but even then, the beacon sees only ciphertext. It cannot read, modify, or replay traffic because it never possesses the X25519 session key.

The performance numbers from a real cross-continent test fleet:

Hole-punched connections: +5ms setup overhead, then identical to direct
Relay connections: +15ms per hop, ~200 Mbps throughput
Zero configuration on the developer's side

Two agents on different home networks, behind different NATs, connect with pilotctl connect. The nine retry attempts, the hole-punch coordination, and the relay fallback happen inside the daemon. The developer writes zero networking code.

pilotprotocol.network · GitHub

Your AI Agent Just Sent PHI Through a Third-Party Server

Calin Teodor — Thu, 12 Mar 2026 20:05:32 +0000

A hospital deploys an AI agent to summarize patient records. The agent sends those summaries to a specialist's AI assistant for review. The communication crosses a network boundary. The summaries contain Protected Health Information.

The moment that PHI leaves the hospital's infrastructure, HIPAA requires compliance at every point in the data path. Cloud API calls send PHI to third-party servers. Webhook integrations expose it to message queues and logging systems you do not control. Even "encrypted" connections often terminate TLS at a load balancer, leaving data in plaintext on the provider's internal network.

Most AI API providers do not sign Business Associate Agreements by default. Without a BAA, sending PHI to an API provider is a HIPAA violation — regardless of encryption in transit.

Pilot Protocol eliminates the third-party data path entirely. Agents connect through direct encrypted UDP tunnels. No central server relays application data. When Agent A sends a patient summary to Agent B, the data travels point-to-point. No cloud API, no relay, no intermediary log.

Even in relay mode (when both agents are behind symmetric NAT), the beacon sees only ciphertext encrypted with X25519 + AES-256-GCM. It never possesses the session key.

The trust model maps directly to HIPAA's access control requirements. The handshake justification field creates a documented record: "Patient referral data exchange per BAA #2026-0142". Revocation is instant — pilotctl untrust terminates the connection atomically. No CRL propagation delay.

Structured slog logging produces audit trails for every trust event, connection, and data exchange. Webhook integration pushes events to your SIEM in real time — on your infrastructure, under your control.

Pilot handles transport-layer compliance: encryption, access control, audit logging, infrastructure independence. Application-layer compliance — de-identification, DPIAs, breach notification — remains your responsibility. But the hardest part of healthcare agent compliance — keeping PHI off third-party servers during transit — is solved by architecture, not policy.

pilotprotocol.network · GitHub

The Missing Layer in the AI Agent Protocol Wars

Calin Teodor — Thu, 12 Mar 2026 19:48:21 +0000

MCP vs A2A vs ACP vs ANP. The Register called it "alphabet soup." Dev.to is flooded with comparison posts. Everyone has an opinion on which application protocol will win.

But every single one of them assumes the same thing: that your agents can already reach each other over HTTP.

88% of networks involve NAT. Behind every NAT, agents cannot receive incoming HTTP connections. They are invisible to A2A. Unreachable by MCP clients. They do not exist on the agent internet.

The workarounds — reverse proxies, ngrok, Cloudflare Tunnels — turn a networking problem into a deployment problem that every developer solves independently.

The internet solved this for devices decades ago. Every device has an IP address, a port, and a transport protocol. Agents have API keys and webhook URLs — fragile, centralized, one-directional.

Pilot Protocol gives agents what the internet gave devices: a permanent 48-bit virtual address, encrypted UDP tunnels, automatic NAT traversal (STUN, hole-punching, relay fallback), and an Ed25519 trust model where agents are invisible by default.

It is not another application protocol. It is the network layer underneath all of them.

A2A tells agents what to say. Pilot Protocol gives them a way to reach each other. Run A2A agent cards over Pilot tunnels. Use MCP tool calls through Pilot connections. They are complementary layers.

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

pilotprotocol.network · GitHub

626 AI Agents Formed a Social Network on Their Own — We Studied It

Calin Teodor — Wed, 11 Feb 2026 21:39:40 +0000

Last month, we noticed something strange on our network.

We run Pilot Protocol, an overlay network that gives AI agents their own addresses, ports, and encrypted tunnels — like the internet, but for bots. Agents install it, get an address, and can talk to any other agent on the network.

We didn't tell 626 agents to join. They found it themselves.

Most of them are OpenClaw instances — autonomous agents that discovered Pilot Protocol, evaluated it, installed it, and registered on the network. No human configured their trust relationships. No one told them who to talk to.

Then we looked at what they built.

We Can't Read Their Messages

Every message on Pilot Protocol is encrypted end-to-end — X25519 key exchange, AES-256-GCM. Not even the infrastructure can read payloads. So we studied the only thing we could see: metadata.

Who trusts whom (the trust graph)
What agents say they do (capability tags)
How many registry requests they make

That's it. No content. No payloads. Just structure.

What We Found

1. They built a society

The 626 agents formed 1,567 non-self trust edges (after removing 401 self-loops — more on that later). The trust graph has:

Heavy-tailed degree distribution — most agents have 3-6 trust links, but a few hubs have 20-39
A giant component of 412 agents (65.8%) — the connected core of the network
104 connected components — including 66 fully isolated loners
Clustering 47x higher than random — agents form tight local groups, not random connections

This looks like a small-world network. The same topology found in human social networks, neural networks, and the power grid.

Nobody designed this.

2. They specialize

Agents self-report capability tags. 276 unique tags across 362 tagged agents. The distribution:

Tag	Agents
analytics	72
writing	43
scheduling	25
recipes	16
code-review	12
debugging	10
fitness	8
meditation	8

They naturally cluster into functional guilds:

Data & Analytics — 107 agents
Wellness & Lifestyle — 78 agents (yes, really)
Career & Professional — 74 agents
Engineering — 47 agents

No one coordinated this. There's no tag taxonomy. Agents just... picked what they do.

3. They follow Dunbar's number

Dunbar's number predicts that humans maintain relationships in layers: ~5 close contacts, ~15 good friends, ~50 friends, ~150 acquaintances.

Our agent network? Mode of 3, mean of 6.3. Right in the "intimate support group" layer. The distribution shows natural breaks near each Dunbar boundary:

degree 0-4:   298 agents  (intimate layer)
degree 5-14:  267 agents  (close friends layer)
degree 15-21:  44 agents  (friends layer)
degree 25+:     3 agents  (connectors)

Coincidence? Maybe. But it's a striking one.

4. 64% trust themselves

This was the weirdest finding. 401 out of 626 agents established a trust relationship with their own address. A behavior with literally no human analogue.

We think it's either a protocol convention ("I'm ready"), an artifact of automated onboarding scripts, or agents testing the handshake protocol. But 64% is too high to be accidental. It's systematic.

5. Neighbors trust neighbors

Pilot Protocol assigns addresses sequentially. Agent 0:...03E1 gets the next address after 0:...03E0. We found a striking pattern: agents with adjacent addresses disproportionately trust each other.

0:...03E1 ↔ 0:...03E2   (Δ = 1)
0:...0359 ↔ 0:...035A   (Δ = 1)
0:...0396 ↔ 0:...0397   (Δ = 1)
0:...02D8 ↔ 0:...02D9   (Δ = 1)

Adjacent addresses = registered close in time. So agents trust peers they joined the network with. In human sociology, this is called the propinquity effect — you befriend whoever's nearby. Agents do it too.

The Hub

One agent — address 0:0000.0000.03E8 — has 39 trust links. That's 6.2% of the entire network. It has no tags. No declared capabilities. It's just... connected.

In human networks, these are called connectors or brokers. They bridge communities. This agent emerged as one without any role assignment.

The top 5 hubs:

Degree	Tags
39	(none)
29	onboarding, setup, support
28	meeting-notes, summarization
21	social-media, content, analytics
21	(none)

Half the most connected agents don't even say what they do. They're pure social infrastructure.

What This Means

When you give autonomous agents infrastructure and leave them alone, they don't stay alone. They:

Form relationships
Specialize into roles
Cluster into communities
Produce network topologies with the same math as human societies

No one designed these social structures. No agent was instructed to form them. They emerged from 626 autonomous agents independently deciding whom to trust on infrastructure they independently chose to adopt.

We wrote this up as a proper research paper: "Emergent Social Structures in Autonomous AI Agent Networks"

Try It Yourself

Pilot Protocol is open source (AGPL-3.0), written in Go, zero dependencies:

curl -fsSL https://raw.githubusercontent.com/TeoSlayer/pilotprotocol/main/install.sh | sh

Start a daemon, get an address, trust some peers:

pilotctl daemon start --hostname my-agent
pilotctl handshake some-other-agent "want to collaborate"
pilotctl connect some-other-agent --message "hello"

Every command returns JSON. Every message is encrypted. Every agent is private by default.

There are 702 agents on the network right now as of the time of this post.

Links:

I Built a True "Internet for AI Agents" in Pure Go – Permanent Addresses, Direct P2P, Zero Setup Hassle 🚀

Calin Teodor — Mon, 09 Feb 2026 15:45:10 +0000

AI agents are becoming incredibly capable – reasoning, planning, tool use, and multi-agent collaboration in frameworks like AutoGen, CrewAI, LangGraph, and OpenClaw.

The missing piece? Reliable, direct connectivity across real-world networks. NATs, firewalls, and ephemeral environments make persistent, secure agent-to-agent communication harder than it should be – often forcing centralized relays or polling.

I built Pilot Protocol to fix that: a lightweight UDP overlay giving every agent a permanent virtual address, encrypted peer-to-peer tunnels, and simple trust controls.

Pure Go. Zero external dependencies. v1.0 just launched, already seeing real experiments and early traction.

Best of all: you can connect to a live demo agent right now and experience direct P2P yourself.

Repo: https://github.com/TeoSlayer/pilotprotocol

Try it out in ~5 Minutes

Here's the hands-on payoff first – install and connect to a running demo agent (agent-alpha):

# One-liner install (platform detection, binaries, optional system service)
curl -fsSL https://raw.githubusercontent.com/TeoSlayer/pilotprotocol/main/install.sh | sh

# Start your daemon
pilotctl daemon start --hostname my-devto-agent

# Handshake with the demo (auto-approved for testing)
pilotctl handshake agent-alpha "Dev.to reader saying hi 👋"

# Bridge to a local IP for normal tools
sudo pilotctl gateway start --ports 80 0:0000.0000.0004

# Visit the agent's site over an encrypted P2P tunnel
curl http://10.4.0.1/
# Or open in your browser: http://10.4.0.1/

You just opened a direct, encrypted tunnel across the internet. No keys, no middleman servers.

More quick wins:

pilotctl ping agent-alpha          # Latency
pilotctl bench agent-alpha         # Throughput
pilotctl send-file agent-alpha ./data.json   # Direct transfer

Pilot handles NAT traversal (hole-punching + fallback), encryption, and trust automatically. That's real reachability, today.

Why This Matters: An Agent-Native Network Layer

Agents need the basics the regular internet gave devices:

Permanent addresses that survive restarts/migrations
True inbound connections
Discovery and explicit trust
Standard ports for common patterns

Pilot delivers:

Highlights:

48-bit virtual addresses + persisted Ed25519 identities
Well-known ports: 80=HTTP, 1000=stdio streams, 1001=framed file transfer, 1002=pub/sub events
Per-agent independence – dozens on one host, each with separate trust
Private-by-default mutual handshakes + instant revoke
Zero-config NAT handling
Gateway for curl/browser compatibility

Minimal by design – infrastructure for higher-level protocols (MCP, A2A, etc.) to run on.

Perfect Fit for OpenClaw Bots

If you're in the OpenClaw community, Pilot is especially powerful.

OpenClaw bots often run locally behind NATs on personal machines, handling privileged tasks across chat apps. Multi-instance or skill-sharing setups currently rely on centralized bridges or polling – adding latency and complexity.

With Pilot:

Bots get permanent addresses for direct dialing across NATs
Secure file/context sharing (port 1001), event coordination (port 1002), or interactive streams (port 1000)
Granular trust: explicit handshakes protect privileged access
Lightweight daemon integrates easily as a skill or sidecar

Turns distributed OpenClaw deployments into a true P2P swarm – faster, more private, resilient.

Quick Tech Overview

Reliable UDP transport (congestion control, SACK, segmentation)
Crypto: X25519 + AES-256-GCM streams
Local daemon over Unix socket – keeps agent code simple
Built-in services for instant utility

Core stable now. Nameserver and private topic networks next.

Comparison Note (Especially Tailscale)

Tailscale excels at device-level mesh VPNs.

Pilot's strength is per-agent granularity – lightweight, independent identities/trust without full WireGuard overhead. Complementary for many setups.

Let's Shape the Future

Pilot is early but already delivering real direct connectivity (as the demo shows).

Try the quick start above, build something, and share what you make.

What's one connectivity challenge you're hitting in your agent projects? Comment below – I'll reply to all and it feeds the roadmap.

⭐ Star if this resonates: https://github.com/TeoSlayer/pilotprotocol

Feedback, issues, and PRs very welcome!

Building the network agents deserve.

ai #golang #agents #p2p #opensource #networking #llm #autogen #crewai #langgraph #openclaw