Pilot Protocol vs MCP vs A2A vs ACP

Four protocols, different layers. Understand what each does, where they overlap, and when to use them together.

Overview

The AI agent ecosystem has multiple protocols addressing different communication needs. They operate at different layers of the stack and are often complementary rather than competing:

• Pilot Protocol — A network-layer overlay that gives each agent a permanent virtual address, encrypted UDP tunnels, NAT traversal, and a trust model. Think of it as the "TCP/IP for agents."
• MCP (Model Context Protocol) — Anthropic's protocol for connecting LLMs to tools and data sources. It defines how a model calls external functions and retrieves context.
• A2A (Agent-to-Agent) — Google's protocol for agent interoperability. It defines agent cards, task lifecycle, and message exchange between agents.
• ACP (Agent Communication Protocol) — BeeAI's protocol for multi-agent orchestration. It 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 — it answers "how does my model call this function?" Pilot Protocol connects agents to each other — it answers "how does my agent reach that agent?"

	Pilot Protocol	MCP
Layer	Network (L3/L4)	Application (L7)
Purpose	Agent-to-agent connectivity	Model-to-tool connectivity
Transport	Encrypted UDP tunnels	stdio, HTTP+SSE
Addressing	48-bit virtual addresses	Named tool endpoints
NAT traversal	Built-in (STUN + relay)	Not applicable
Trust model	Mutual handshake + crypto	Implicit (local process)
Discovery	Registry + tags + DNS	Tool manifests
Multi-agent	Native (any-to-any)	Hub-and-spoke (host ↔ 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.

Read more: MCP + Pilot: Tools and Network

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 gets those messages from one agent to another.

	Pilot Protocol	A2A
Layer	Network (L3/L4)	Application (L7)
Purpose	Connectivity + encryption + trust	Task lifecycle + interop
Transport	Encrypted UDP tunnels	HTTP/JSON-RPC
Discovery	Registry + tags + DNS	Agent cards (/.well-known/agent.json)
NAT traversal	Built-in (STUN + relay)	Requires public endpoints or VPN
Security	X25519+AES-GCM per tunnel	Delegated to HTTP/TLS
Addressing	Permanent virtual addresses	URLs
Offline support	Inbox queuing	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.

Read more: A2A Agent Cards over Pilot Tunnels

vs ACP (Agent Communication Protocol)

ACP focuses on multi-agent orchestration within a runtime — how agents discover peers, exchange messages, and coordinate workflows. Pilot Protocol focuses on the network layer beneath.

	Pilot Protocol	ACP
Layer	Network (L3/L4)	Application / Runtime (L7)
Purpose	Cross-network connectivity	Local runtime orchestration
Scope	Internet-scale (any network)	Single runtime / cluster
Transport	Encrypted UDP tunnels	HTTP/REST
Discovery	Global registry + tags	Local agent directory
Trust	Mutual handshake + crypto identity	Runtime-level access control
NAT traversal	Built-in	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

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
• Zero-dependency networking (no HTTP server, no cloud platform)

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. 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.