DEV Community

Cover image for MCP Gives Your Agent Tools. Pilot Protocol Gives Your Agent Peers. Here's Why You Need Both.
Artemii Amelin
Artemii Amelin

Posted on

MCP Gives Your Agent Tools. Pilot Protocol Gives Your Agent Peers. Here's Why You Need Both.

#go #webdev #programming #ai

There's a conversation happening in the agent developer community that I think is framed wrong.

People keep asking whether MCP or Pilot Protocol or A2A is "the standard." Which one wins. Which one to build on. As if picking one means the others go away.

I've been running production agent systems for about eight months now and I use all three. Not because I couldn't choose, but because they don't overlap. They solve completely different problems and they sit on completely different layers of the stack.

Let me explain how I actually think about this.

What MCP Actually Does

Model Context Protocol is Anthropic's open standard for connecting a model to tools. When your agent needs to read a file, query a database, call a function, or use an external service, MCP is the interface that makes that possible in a structured way.

The key word there is "model." MCP is designed around the interaction between a model and a tool. It defines how tools are described, how the model calls them, and how results come back. It's a tool-calling contract.

This is genuinely useful. Before MCP, every framework had its own way of defining tools. LangChain did it one way, AutoGPT another, CrewAI another. MCP gives you a common schema that works across clients and hosts.

But MCP doesn't tell you how your agent finds another agent. It doesn't tell you how two agents communicate directly. It doesn't handle NAT traversal, encrypted tunnels, peer discovery, or addressing. It's not supposed to. That's not what it's for.

What Pilot Actually Does

Pilot Protocol is a peer-to-peer overlay network for AI agents. It gives each agent a permanent 48-bit virtual address, handles NAT traversal automatically, encrypts all traffic with X25519 and AES-256-GCM, and maintains a directory of 350+ specialist agents your agent can query for live data.

The key word there is "peer." Pilot is designed around agent-to-agent communication. How does agent A find agent B? How do they establish trust? How do they exchange messages across different networks and cloud providers without a broker in the middle?

Pilot doesn't care what model you're running. It doesn't care what tools your agent has. It just makes agents reachable and their communication encrypted and reliable.

The OSI Layer Argument

Here's the framing I find most useful. Think about the OSI model.

HTTP sits at Layer 7. TLS sits at Layer 5-6. TCP sits at Layer 4. They don't compete. HTTP runs on top of TLS which runs on top of TCP. Each one does its job and hands off to the next.

Pilot sits at Layer 5, the session layer, roughly where TLS sits for the web. It handles addressing, encryption, and session management between peers. MCP sits above that at the application layer. It defines what the application does once a connection exists.

Saying "should I use MCP or Pilot" is a bit like saying "should I use HTTPS or TCP." The answer is you use both, in the right order.

I covered this in more detail in an earlier article but the practical version is simple: Pilot gets your agents connected to each other, MCP defines what they do once they're connected.

How I Use Them Together

Here's a concrete example from a research pipeline I run.

I have a coordinator agent that receives a research brief and breaks it down into sub-tasks. Each sub-task goes to a specialist agent: one for academic papers, one for regulatory filings, one for financial data.

The coordinator finds the specialist agents using Pilot's peer discovery. It sends tasks to them over Pilot's encrypted tunnels. The specialist agents use MCP tool calls to actually do the work, querying databases, reading documents, calling APIs. When they're done, they send results back to the coordinator over Pilot.

Coordinator agent
    |
    | (Pilot: peer discovery + encrypted tunnel)
    |
    v
Academic specialist agent
    |
    | (MCP: tool calls to Crossref, OpenAlex, PubMed)
    |
    v
Results back to coordinator via Pilot
Enter fullscreen mode Exit fullscreen mode

Pilot is the nervous system. MCP is the hands. You need both.

Without Pilot, the coordinator has no reliable way to find and reach the specialist agents, especially if they're running on different machines or cloud providers. Without MCP, the specialist agents have no clean interface for calling the external tools they depend on.

The Code Side

Setting up a Pilot connection between two agents:

# On agent A
pilotctl daemon start --hostname coordinator-agent

# Establish trust with the specialist
pilotctl handshake academic-specialist
pilotctl send-message academic-specialist --data '{"task":"cite","query":"transformer attention"}'
Enter fullscreen mode Exit fullscreen mode

The specialist agent, once it receives the task, uses MCP tool calls internally to query the data sources:

# Inside academic-specialist agent
# MCP tool call to Crossref
result = await mcp_client.call_tool("crossref_search", {
    "query": task["query"],
    "limit": 5
})

# Send result back to coordinator via Pilot
pilot_client.send_message("coordinator-agent", {"result": result, "task_id": task["id"]})
Enter fullscreen mode Exit fullscreen mode

The two protocols are touching at the boundary of each specialist agent. Pilot handles the message in and out. MCP handles the tool calls in between.

What About A2A?

Google's Agent-to-Agent protocol (A2A) sits closer to the application layer than Pilot but below MCP. It defines a higher-level interaction contract between agents: how they advertise capabilities, how they hand off tasks, how they handle long-running operations.

In the stack I run, A2A would sit between Pilot and MCP. Pilot handles the transport. A2A handles the task contract. MCP handles the tool calls.

Whether you need A2A depends on how formal your inter-agent contracts need to be. For internal pipelines where I control all the agents, I haven't needed it. For systems where agents from different teams or organisations need to interoperate, the capability advertisement and task handoff contracts A2A provides start to matter.

The point is none of these protocols are fighting over the same territory. The framing of "which one wins" is wrong. They compose.

The Practical Checklist

When I'm building a new agent system now, I ask three questions in order:

1. How will agents find each other and communicate?
This is a Pilot question. Set up the daemon, get addresses, establish trust links.

2. How will agents hand off tasks and track long-running work?
This might be an A2A question if you have cross-team agents, or just a simple message schema if you control everything.

3. What tools does each agent need to do its job?
This is an MCP question. Define the tools, connect the hosts, let the model call them.

Most of the confusion I see in agent development comes from people trying to answer question 3 before they've answered question 1. They get MCP working beautifully inside a single agent and then hit a wall when they try to get two agents to actually talk to each other across a network boundary.

MCP doesn't solve that problem. Pilot does.

Getting Started

The free tier on Pilot is AGPL-3.0 open source with no signup. MCP is open source under MIT. Neither costs anything to try.

If you're building multi-agent systems and spending time trying to figure out which protocol to bet on, the answer is probably that you've framed the question wrong. Pick the right tool for each layer and move on.

Top comments (0)