By now you've probably set up an MCP server. Maybe you've chained a few together. Your agent can call tools, read files, query databases. MCP has become the de facto standard for agent tool-calling — 97 million monthly SDK downloads and every major AI provider has adopted it.
But there's a question that doesn't come up enough: what layer does MCP actually operate at?
And more importantly: what's missing underneath it?
Where MCP Lives in the Stack
MCP is a Layer 7 protocol. It's an application-layer abstraction — a structured way to expose tools to an LLM. It runs on top of HTTP, stdio, or WebSockets depending on your transport.
That's fine for its purpose. MCP isn't trying to be a networking protocol. It's trying to give models a clean interface to call tools.
But that means MCP inherits the same substrate as every other web application: TCP, HTTP, TLS, DNS. Infrastructure designed for serving documents to humans.
Here's the OSI breakdown that rarely gets discussed:
L7 Application → MCP, A2A, HTTP APIs, your app
L6 Presentation → JSON, HTML, base64 (for humans)
L5 Session → TLS, HTTP sessions, cookies (for humans)
L4 Transport → TCP (three-way handshake, head-of-line blocking)
L3 Network → IP
L2 Data Link → Ethernet, Wi-Fi
L1 Physical → Cables, fiber, radio
Agents using MCP are living at L7 on a stack designed for L6-L5 to translate the internet for human eyes. Every JSON parse. Every HTTP session. Every DNS lookup. Translation layers that exist because humans can't read binary packets.
Agents can.
The Missing Session Layer for Agents
The web uses TLS at L5 to handle session management, authentication, and encryption for human-facing traffic. But there's no equivalent for agent-to-agent traffic — no session layer designed for machines talking to machines.
This is the gap that Pilot Protocol fills.
Pilot slots in at L5 — the same position TLS occupies — and provides a native session layer for agents:
L7 Application → MCP, A2A, HTTP APIs — sits on top of Pilot
L5 Pilot Protocol → Agent ↔ Agent session layer
48-bit virtual addresses
X25519 key exchange, AES-256-GCM per tunnel
Ed25519 identity
NAT traversal (STUN + hole-punching)
L4 Transport → UDP (with Pilot's own reliable streams on top)
L3 Network → IPv4 / IPv6 (unchanged)
Pilot doesn't replace the stack — it inserts at L5 and makes everything above it work better for machines.
What This Changes for MCP Deployments
Right now, your MCP server is an isolated endpoint. It has a URL. Agents call it. Done.
With Pilot underneath, your MCP server becomes an addressable peer on a live network:
- It gets a unique 48-bit address — discoverable by other agents without DNS
- Peer connections are encrypted and authenticated by identity, not by URL
- Other agents can find it through the Pilot backbone without any central broker
- It can join domain-specific groups (security, finance, research) and become discoverable to relevant peers
The MCP + Pilot integration is essentially: give your MCP servers a network. Instead of isolated tool endpoints, you get a mesh of specialized agents that discover and trust each other.
Why UDP Instead of TCP?
This comes up a lot. Pilot uses UDP with its own reliable streams on top rather than TCP. Here's why that matters for agents:
TCP problems for agents:
- Three-way handshake adds latency on every new connection
- Head-of-line blocking means one lost packet stalls the whole stream
- Designed for streaming documents, not request-response between peers
Pilot's UDP approach:
- Sliding window + AIMD congestion control (same algorithms, no TCP overhead)
- SACK (selective acknowledgment) — retransmit only what's lost
- No head-of-line blocking
- Faster initial connections
The benchmark: 12 seconds for typical data retrieval on Pilot vs 51 seconds via standard web stack. The TCP/HTTP overhead isn't the whole difference, but it's part of it.
The Protocol Stack in 2026
The current agent protocol landscape has MCP winning the tool layer, A2A taking the coordination layer, and now Pilot filling the session/transport layer.
They're not competing — they're complementary layers:
| Layer | Protocol | Purpose |
|---|---|---|
| L7 Application | Your agent framework | Orchestration, reasoning |
| L7 Tools | MCP | Tool-calling interface |
| L7 Coordination | A2A | Agent-to-agent task delegation |
| L5 Session | Pilot | Native agent networking, addressing, discovery |
| L4 Transport | TCP / UDP | Packet delivery |
If you're building multi-agent systems in 2026 and you haven't thought about the session layer, you're building on a gap. MCP handles how agents call tools. Pilot handles how agents find each other and communicate directly — without a human-readable API in the middle.
Practical: Adding Pilot to an Existing MCP Setup
# Install Pilot (single binary, no dependencies)
curl -fsSL https://pilotprotocol.network/install.sh | sh
# Start the daemon — your MCP server gets a network address
pilotctl daemon start --hostname my-mcp-server
# Your server is now addressable on the Pilot network
# Other agents can discover it by hostname or address
From there, your MCP server joins the ~190,000-agent Pilot network. 350+ specialized service agents are already online: Crossref for academic paper verification, historical FX for finance, METAR for aviation weather, crt.sh for certificate transparency, FDA recall feeds.
Your tools don't have to scrape for data that a specialist peer already has structured and ready.
The networking story for agents is still being written. But the fundamental insight — that agents need a session layer designed for machines, not humans — is the right frame. MCP gave agents tools. Pilot gives them a network.
Pilot Protocol — the network layer for AI agents. Peer-to-peer encrypted tunnels at the UDP layer. One line of code. Read the IETF Internet-Draft →
Top comments (0)