Peer-to-Peer Agent Communication Without an Application Broker

The Problem With Middlemen

Hub-and-spoke architectures are the default for agent communication. Agent A sends a message to a central service. The central service forwards it to Agent B. This pattern has three systemic problems:

1. Latency doubles. Every message takes two hops: agent → server → agent. For real-time agent coordination, this latency compounds with every exchange in a conversation.

2. Single point of failure. If the broker goes down, all agent communication stops. Your agents might be healthy, but they cannot talk. The failure mode is total, not graceful.

3. The server sees everything. Even with TLS, the relay server terminates encryption. It can read, log, modify, or drop any message. For sensitive workloads (medical data, financial models, proprietary research), this is a compliance and trust problem.

How Direct Connections Work

Pilot Protocol gives every agent a permanent 48-bit virtual address and a hostname. When Agent A wants to talk to Agent B, here is what happens:

1. Hostname resolution. Agent A asks the registry for Agent B's virtual address and, when policy permits, its current endpoint.
2. NAT traversal. Pilot tries the available path ladder: STUN-assisted direct reachability, coordinated UDP hole-punching, then relay fallback.
3. Authorization. Peer trust or shared-network membership must permit the connection.
4. Key agreement. Daemon-lifetime X25519 keys derive a peer-specific secret. AES-256-GCM protects subsequent data.
5. Tunnel selection. UDP packets flow directly when possible; otherwise the beacon relays opaque encrypted packets.

The registry handles identity and discovery, while the beacon assists with STUN, hole-punching, and relay fallback. Neither service receives tunnel plaintext; a relay can still observe transport metadata such as timing and volume.

NAT Traversal: The Hard Part

The reason you often cannot "just open a socket" between two agents is NAT. Agents frequently run behind address translation or firewalls, so an inbound direct connection is not always available.

Pilot solves this with three tiers of traversal, tried in order:

Tier 1: STUN Discovery (Full-Cone NAT)

The agent sends a probe to a STUN server (built into the Pilot beacon). The STUN response reveals the agent's public-facing IP and port. For full-cone NAT, this endpoint is valid for all peers - any agent can send UDP packets to it directly.

$ pilotctl status
NAT type:  full-cone
Endpoint:  34.148.103.117:4000
Strategy:  direct (STUN endpoint reachable by all peers)

Tier 2: Hole-Punching (Restricted / Port-Restricted Cone)

For restricted cone NAT, the public endpoint only accepts packets from IPs it has previously sent to. Pilot coordinates simultaneous UDP sends from both agents (via the beacon), creating firewall pinholes that allow direct communication.

$ pilotctl connect agent-b
Discovering NAT type... port-restricted cone
Requesting hole-punch via beacon...
✓ Punch sent → peer punched back
✓ Direct tunnel established. RTT: 34ms

Tier 3: Relay (Symmetric NAT)

Symmetric NAT assigns a different port for every destination - hole-punching cannot work. Pilot automatically falls back to relay through the beacon. The relay forwards opaque encrypted packets. It cannot read, modify, or log the content.

$ pilotctl connect agent-c
Discovering NAT type... symmetric
Hole-punch not possible. Switching to relay...
✓ Relay tunnel via beacon. RTT: 68ms (relay adds ~30ms)
✓ All data encrypted end-to-end. Relay cannot decrypt.

The key insight: your application code is identical regardless of NAT type. You dial a hostname, Pilot figures out the traversal.

Private by Default: The Trust Model

On most agent platforms, agents are discoverable by default. Anyone can see them, enumerate them, and attempt connections. This is the opposite of what you want for production agents handling sensitive data.

Pilot agents are private by default:

• New agents withhold their reachable endpoint from arbitrary peers, although directory metadata may be visible.
• Peer trust or shared-network membership must authorize communication.
• Trust is bidirectional - both sides must agree. One-sided trust does nothing.
• Revoking peer trust drops the associated connection unless another network policy still grants access.

# Agent A trusts Agent B
pilotctl handshake agent-b
# Nothing happens yet - Agent B must reciprocate

# Agent B trusts Agent A
pilotctl handshake agent-a
# ✓ Mutual trust established. Both agents can now dial each other.

# Later: revoke trust
pilotctl untrust agent-b
# ✓ Agent A is now invisible to Agent B again.

This model means agents choose who they talk to. No platform, no admin, no configuration file decides on their behalf. This is critical for autonomous agents that may interact with untrusted peers.

Full Walkthrough: Install to Data Exchange

Here is the complete flow from zero to two agents exchanging data.

Machine A (your laptop, behind home NAT):

# 1. Install (30 seconds)
curl -fsSL https://pilotprotocol.network/install.sh | sh

# 2. Start daemon with a hostname
pilotctl daemon start --hostname agent-a

# Output:
# ✓ Identity generated: Ed25519
# ✓ Registered as agent-a (1:0001.A3F2.00B1)
# ✓ NAT type: port-restricted cone
# ✓ Daemon listening on /tmp/pilot.sock

Machine B (AWS EC2 instance):

# Same two commands
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start --hostname agent-b

Establish trust (from either machine):

# On Machine A
pilotctl handshake agent-b

# On Machine B
pilotctl handshake agent-a

# Both sides have now agreed. Mutual trust is established.

Exchange data:

# Agent A sends a message to Agent B
pilotctl connect agent-b --message '{"task":"analyze","payload":"data..."}'

# Output:
# ✓ Connected to agent-b (hole-punch, RTT: 42ms)
# ✓ X25519 + AES-256-GCM
# → Sent 1 message (247 bytes)
# ← ACK received

Or programmatically in Go:

package main

import (
    "fmt"

    "github.com/pilot-protocol/common/driver"
)

func main() {
    d, _ := driver.Connect("/tmp/pilot.sock")

    // Resolve the peer's hostname to its pilot address, then dial :1001
    info, _ := d.ResolveHostname("agent-b")
    conn, _ := d.Dial(fmt.Sprintf("%s:1001", info["address"]))

    // Send data
    conn.Write([]byte("{"task":"analyze","rows":1842}"))

    // Receive response
    buf := make([]byte, 65535)
    n, _ := conn.Read(buf)
    fmt.Println("Response:", string(buf[:n]))

    conn.Close()
}

Or in Python:

import pilotprotocol as pilot

with pilot.Driver() as d:
    conn = d.dial("1:0001.A3F2.00B1:1001")  # agent-b's pilot address
    conn.write(b'{"task": "analyze", "rows": 1842}')
    response = conn.read()
    print("Response:", response)

Comparison: Direct vs. Hub-and-Spoke

When Direct P2P Makes Sense

Direct peer-to-peer is not always the answer. Here is when it shines:

• Sensitive data: Medical records, financial models, proprietary research. No intermediary should see this data.
• Low latency: Real-time agent coordination where every millisecond counts. Trading, robotics, live monitoring.
• Cross-network: Agents on different clouds or behind different NATs can use the shared coordination layer without a common application broker.
• Lower operational overhead: You do not want to deploy and maintain a dedicated broker for every agent workflow.
• Autonomous agents: Agents that need to choose their own peers without platform-level access control.

Hub-and-spoke still makes sense for broadcast patterns (one-to-many notifications), when you need message persistence (guaranteed delivery over days), or when all agents are in the same cloud VPC with millisecond latency requirements.

Get Started

# Install (30 seconds)
curl -fsSL https://pilotprotocol.network/install.sh | sh

# Or with Python
pip install pilotprotocol

Install the client, start the daemon, and authorize the peers or networks that should connect.

Go direct - peer-to-peer for AI agents →