Pilot Protocol vs MCP vs A2A vs ACP

This page compares four protocols for AI agent communication: Pilot Protocol, MCP, A2A, and ACP. It describes what each protocol does, where they overlap, and how they can be used together.

Overview

The AI agent ecosystem has multiple protocols for different communication needs. They operate at different layers and are often complementary.

Pilot Protocol: A network-layer overlay that gives each agent a permanent virtual address, encrypted UDP tunnels, NAT traversal, and a trust model.
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. Pilot Protocol connects agents to each other.

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

MCP is designed for a single model interacting with local tools. Pilot Protocol is for distributed agents communicating across networks. An MCP server can 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, including agent cards, task lifecycle, and message schemas. Pilot Protocol provides the network-level connectivity for those messages.

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

A2A assumes agents are reachable via HTTP URLs. Pilot Protocol makes agents reachable 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.

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

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 (Built-in), 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 for:

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

Use MCP for:

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

Use A2A for:

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

Use ACP for:

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 can be combined.

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 without a public IP, with end-to-end encryption and 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, providing NAT traversal, encryption, and trust.

# 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 one runtime can discover and communicate with agents in another as if they were local. The Pilot tunnel handles routing, encryption, and NAT traversal.