Pilot Protocol vs MCP vs A2A vs ACP

Four protocols at different layers of the agent communication stack. They are often complementary rather than competing.

Overview

Pilot Protocol - A network-layer overlay that gives each agent a permanent virtual address, encrypted UDP tunnels, NAT traversal, and a trust model. "TCP/IP for agents."
MCP (Model Context Protocol) - Anthropic's protocol for connecting LLMs to tools and data sources. Defines how a model calls external functions and retrieves context.
A2A (Agent-to-Agent) - Google's protocol for agent interoperability. Defines agent cards, task lifecycle, and message exchange between agents.
ACP (Agent Communication Protocol) - BeeAI's protocol for multi-agent orchestration. Defines how agents discover each other, exchange messages, and coordinate tasks within a runtime.

vs MCP (Model Context Protocol)

MCP connects an LLM to tools and data sources. Pilot Protocol connects agents to each other.

Layer: Pilot = Network (L3/L4); MCP = Application (L7)
Purpose: Pilot = agent-to-agent connectivity; MCP = model-to-tool connectivity
Transport: Pilot = encrypted UDP tunnels; MCP = stdio, HTTP+SSE
Addressing: Pilot = 48-bit virtual addresses; MCP = named tool endpoints
NAT traversal: Pilot = built-in (STUN + relay); MCP = not applicable
Trust model: Pilot = mutual handshake + crypto; MCP = implicit (local process)
Discovery: Pilot = registry + tags + DNS; MCP = tool manifests
Multi-agent: Pilot = native (any-to-any); MCP = hub-and-spoke (host to server)

Key difference: MCP is designed for a single model interacting with local tools. Pilot Protocol is designed for distributed agents communicating across networks. An MCP server could run on top of a Pilot tunnel to expose tools to remote agents.

vs A2A (Agent-to-Agent)

A2A defines the application-level contract between agents - agent cards, task lifecycle, and message schemas. Pilot Protocol provides the network-level connectivity that moves those messages.

Layer: Pilot = Network (L3/L4); A2A = Application (L7)
Purpose: Pilot = connectivity + encryption + trust; A2A = task lifecycle + interop
Transport: Pilot = encrypted UDP tunnels; A2A = HTTP/JSON-RPC
Discovery: Pilot = registry + tags + DNS; A2A = agent cards (/.well-known/agent.json)
NAT traversal: Pilot = built-in (STUN + relay); A2A = requires public endpoints or VPN
Security: Pilot = X25519+AES-GCM per tunnel; A2A = delegated to HTTP/TLS
Addressing: Pilot = permanent virtual addresses; A2A = URLs
Offline support: Pilot = inbox queuing; A2A = polling / push notifications

Key difference: A2A assumes agents are reachable via HTTP URLs. Pilot Protocol makes agents reachable even behind NATs, firewalls, or without public IPs. A2A agent cards can advertise Pilot addresses, and A2A JSON-RPC messages can travel over Pilot tunnels.

vs ACP (Agent Communication Protocol)

ACP focuses on multi-agent orchestration within a runtime. Pilot Protocol focuses on the network layer beneath.

Layer: Pilot = Network (L3/L4); ACP = Application / Runtime (L7)
Purpose: Pilot = cross-network connectivity; ACP = local runtime orchestration
Scope: Pilot = internet-scale (any network); ACP = single runtime / cluster
Transport: Pilot = encrypted UDP tunnels; ACP = HTTP/REST
Discovery: Pilot = global registry + tags; ACP = local agent directory
Trust: Pilot = mutual handshake + crypto identity; ACP = runtime-level access control
NAT traversal: Pilot = built-in; ACP = not applicable (local)

Key difference: ACP orchestrates agents within a single runtime environment. Pilot Protocol connects agents across different machines, networks, and organizations. ACP agents can use Pilot tunnels to communicate with agents in remote runtimes.

Feature matrix

Permanent agent identity: Pilot = Yes; MCP = No; A2A = agent cards; ACP = agent ID
Virtual addressing: Pilot = 48-bit; MCP = No; A2A = No; ACP = No
End-to-end encryption: Pilot = X25519+AES-GCM; MCP = No; A2A = TLS; ACP = No
NAT traversal: Pilot = STUN+relay; MCP = N/A; A2A = No; ACP = N/A
Mutual trust model: Pilot = Yes; MCP = No; A2A = No; ACP = No
Peer discovery: Pilot = registry+tags; MCP = tool manifest; A2A = agent cards; ACP = directory
Pub/Sub: Pilot = built-in; MCP = No; A2A = No; ACP = No
Task delegation: Pilot = app-level (via service agents); MCP = No; A2A = Yes; ACP = Yes
Tool calling: Pilot = via services; MCP = Yes; A2A = No; ACP = No
Streaming: Pilot = Yes; MCP = SSE; A2A = SSE; ACP = SSE
Offline/async: Pilot = inbox; MCP = No; A2A = polling; ACP = No
Dependencies: Pilot = stdlib only; MCP = SDK; A2A = HTTP stack; ACP = runtime
Transport: Pilot = UDP; MCP = stdio/HTTP; A2A = HTTP; ACP = HTTP

When to use what

Use Pilot Protocol when you need:

Agents communicating across networks, NATs, or organizations
Permanent agent identity that survives restarts and migrations
End-to-end encryption without relying on TLS termination
A trust model where agents explicitly approve peers
Lightweight networking with minimal infrastructure (no HTTP server, no cloud platform to manage)

Use MCP when you need:

An LLM to call external tools (databases, APIs, file systems)
Local tool integration within a single application
Standardized tool discovery and invocation

Use A2A when you need:

Interoperability between agents from different vendors
Structured task lifecycle (submit, progress, complete)
Agent capability discovery via agent cards

Use ACP when you need:

Multi-agent orchestration within a single runtime
Local agent coordination and workflow management
Framework-agnostic agent interop within one environment

Using them together

These protocols are designed for different layers and combine naturally.

Pilot + MCP

Run an MCP server on one machine and expose it over a Pilot tunnel. Remote agents connect to the MCP server's Pilot address - no public IP needed, encrypted end-to-end, trust-gated access.

# Agent A runs an MCP server, exposed on Pilot port 80
# Agent B connects from across the internet
pilotctl connect <agent-a-address> 80
# MCP JSON-RPC flows over the encrypted Pilot tunnel

Pilot + A2A

Agents advertise A2A agent cards with their Pilot address. Task requests and responses travel over Pilot tunnels instead of public HTTP endpoints. NAT traversal, encryption, and trust come for free.

# Agent card includes Pilot address instead of URL
{
  "name": "research-agent",
  "pilot_address": "1:0001.0000.0042",
  "skills": [{"name": "web-research"}]
}

Pilot + ACP

ACP runtimes on different machines connect via Pilot tunnels. Agents in runtime A can discover and communicate with agents in runtime B as if they were local - the Pilot tunnel handles routing, encryption, and NAT traversal.

The short version: MCP, A2A, and ACP define what agents say. Pilot Protocol defines how they reach each other.