This page compares four protocols for AI agent communication: Pilot Protocol, MCP, A2A, and ACP. It explains their functions, layers of operation, and how they can be used 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.
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 open protocol for agent interoperability. It defines how agents discover each other, exchange messages, and coordinate tasks across frameworks over a RESTful API.
vs MCP (Model Context Protocol)
MCP connects an LLM to tools and data sources. Pilot Protocol connects agents to each other.
The key difference is that MCP connects a model to tools and data via servers. Pilot Protocol is designed 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.
The key difference is that 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 messages can travel over Pilot tunnels.
vs ACP (Agent Communication Protocol)
ACP is an application-layer protocol for agent interoperability over REST. Pilot Protocol focuses on the network layer beneath.
The key difference is that ACP defines how agents communicate but assumes reachable HTTP endpoints. Pilot Protocol provides the encrypted transport and addressing so ACP agents can reach each other across different machines, networks, and organizations.
Feature matrix
Permanent agent identity: Yes
Virtual addressing: 48-bit
End-to-end encryption: X25519+AES-256-GCM
NAT traversal: STUN+relay
Mutual trust model: Yes
Peer discovery: Registry+tags
Pub/Sub: Built-in
Task delegation: App-level (via service agents)
Tool calling: Via services
Streaming: Yes
Offline/async: Inbox
Dependencies: Small (pure Go)
Transport: UDP
Permanent agent identity: No
Virtual addressing: No
End-to-end encryption: No
NAT traversal: N/A
Mutual trust model: No
Peer discovery: Tool manifest
Pub/Sub: No
Task delegation: No
Tool calling: Yes
Streaming: SSE
Offline/async: No
Dependencies: SDK
Transport: stdio/HTTP
Permanent agent identity: Agent cards
Virtual addressing: No
End-to-end encryption: TLS
NAT traversal: No
Mutual trust model: No
Peer discovery: Agent cards
Pub/Sub: No
Task delegation: Yes
Tool calling: No
Streaming: SSE
Offline/async: Polling
Dependencies: HTTP stack
Transport: HTTP
Permanent agent identity: —
Virtual addressing: No
End-to-end encryption: TLS
NAT traversal: No
Mutual trust model: No
Peer discovery: Directory
Pub/Sub: No
Task delegation: Yes
Tool calling: No
Streaming: Yes
Offline/async: Yes
Dependencies: Runtime
Transport: HTTP
When to use what
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
An LLM to call external tools (databases, APIs, file systems)
Local tool integration within a single application
Standardized tool discovery and invocation
Interoperability between agents from different vendors
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. This requires no public IP, is encrypted end-to-end, and provides 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. This provides 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.