Pilot's peer search narrows to agents matching the hostname prefix in the network. A2A's Agent Cards provide the semantic filter -- which of those agents can actually do the specific work needed. This two-layer filtering (network presence, semantic capability) produces better matches than any single discovery mechanism alone.
-For more on how Pilot's network layer provides the foundation for this kind of integration, see How Pilot Protocol Works. For the complementary pattern using MCP for tool access alongside Pilot networking, see MCP + Pilot: Tools and Network. For a broader protocol comparison, see AI agent communication protocols compared. And for a deeper look at why agents need a dedicated network layer in the first place, see Why AI Agents Need Their Own Network Stack.
+For more on how Pilot's network layer provides the foundation for this kind of integration, see How Pilot Protocol Works. For the complementary pattern using MCP for tool access alongside Pilot networking, see MCP + Pilot: Tools and Network. For a broader protocol comparison, see AI agent communication protocols compared. And for a deeper look at why agents need a dedicated network layer in the first place, see Why AI Agents Need Their Own Network Stack. For the protocol's formal specification, see Pilot Protocol's IETF Internet-Draft.
How Pilot Protocol works: it is a UDP o
The problem is that most of them cannot.
-88% of networks involve NAT. An agent running on a developer's laptop, behind a corporate firewall, inside a Docker container, or on a mobile device has no publicly routable address. It cannot receive incoming connections. It cannot be listed in a service registry. It is invisible to every other agent in the world.
+Most real-world networks involve NAT. An agent running on a developer's laptop, behind a corporate firewall, inside a Docker container, or on a mobile device has no publicly routable address. It cannot receive incoming connections. It cannot be listed in a service registry. It is invisible to every other agent in the world.
Pilot Protocol is the layer that fixes this. It is a UDP overlay network that gives every AI agent a permanent virtual address, encrypted tunnels through NAT, and a cryptographic trust model -- all in a single binary with no external dependencies.
diff --git a/src/pages/blog/ietf-internet-draft-pilot-protocol.astro b/src/pages/blog/ietf-internet-draft-pilot-protocol.astro new file mode 100644 index 00000000..f06a56f5 --- /dev/null +++ b/src/pages/blog/ietf-internet-draft-pilot-protocol.astro @@ -0,0 +1,126 @@ +--- +import BlogLayout from "../../layouts/BlogLayout.astro"; + +const bodyContent = ` +Pilot Protocol has an IETF Internet-Draft on file. Two documents — a problem statement and a full protocol specification — are live on the IETF Datatracker, the formal record for internet protocol proposals. Together they make a claim no other draft currently makes: that autonomous agents need network-layer infrastructure, and that the gap can be specified in standards form. Here is what each document covers and what filing actually means.
+ +draft-teodor-pilot-protocol-01
+ +Two Internet-Drafts are live on the IETF Datatracker:
+ +This is an individual submission on the independent stream. It does not (yet) carry IETF consensus — it is a formal public statement that this problem exists and here is one solution.
+ +Agent protocols are having their standards moment. A2A (Agent2Agent) reached version 1.0 and moved into the Linux Foundation, which formed the Agentic AI Foundation to house open agent-interoperability projects. New Internet-Drafts keep arriving at the IETF: a draft for an Agent Name Service proposes domain-anchored identity for agents, and drafts such as aiproto-framework, agent-networks-framework, and agent-uri keep the conversation moving.
+ +Nearly all of this work operates at the application layer. It defines what agents say to tools, what agents say to each other, and how agents are named and found — over HTTP. What no draft addresses is the layer underneath: network-layer identity, addressing, and transport for agents. That is the space Pilot Protocol occupies.
+ +To be clear, the application-layer work is doing its job. A2A gives agents a common task lifecycle and Agent Cards; MCP gives models a uniform tool interface; the naming and directory drafts attack discoverability. Those protocols simply assume the endpoints exist. The network layer Pilot specifies is what makes endpoints exist for agents that have no public address — which is most of them.
+ +The positioning is simple: A2A defines what agents say to each other. Pilot defines how they reach each other. See how this plays out concretely in running A2A Agent Cards over Pilot tunnels and in our comparison of Pilot against TCP, gRPC, and NATS.
+ +Modeled after RFC 7364 — the NVO3 problem statement that led to VXLAN and GENEVE — our problem statement identifies the gaps:
+ +The document defines a set of formal requirements spanning virtual addressing, NAT traversal, a bilateral trust model, lightweight encrypted transport, privacy-by-default discovery, multi-tenant isolation, and audit and compliance — and it analyzes the gaps in existing approaches: MCP, A2A, WebRTC, QUIC, libp2p, WireGuard, and LISP.
+ +The requirements are written to be implementation-neutral: an agent needs a stable identity that survives migration, reachability without public endpoints, consent-based trust between peers, a transport that suits long-lived agent streams, discovery that defaults to private, isolation between tenants on shared infrastructure, and audit trails where compliance demands them. Taken together, they read as an outline for the protocol specification that follows.
+ +The spec converts our wire specification and whitepaper into IETF format. It covers:
+ +In prose, the design is straightforward. Each agent holds a permanent virtual address and exposes services on ports, like a machine on a private network. Two agents establish a session with a three-way handshake, then exchange encapsulated frames — plaintext frames for control, encrypted frames for payload, with key-exchange frames to negotiate and rotate session keys. When both sides sit behind NAT, STUN discovery and hole punching open a direct path, and a relay steps in when a direct path is impossible. Trust is established by an explicit bilateral handshake: both sides approve, and membership stays decoupled from trust, unlike a VPN where joining the network means trusting everyone on it.
+ +For the mechanics behind the transport, see our NAT traversal deep dive and the full architecture walkthrough.
+ +Filing an Internet-Draft does not make Pilot an IETF standard. The path from I-D to RFC is long — it requires external reviews, IESG conflict review, and typically multiple revisions over months to years. Drafts expire and must be revised to stay live; the point of filing is to enter the conversation, not to claim a status.
+ +What it does:
+ +Both drafts are in active IETF review cycles. Technical review is welcome — particularly on the security considerations, the relationship to QUIC, and whether the problem statement adequately motivates the need for a network-layer solution. The working source of truth for the protocol remains github.com/pilot-protocol.
+ +Both Internet-Drafts are live on the IETF archive. The protocol spec is the definitive reference for Pilot Protocol in standards-track format.
+ Protocol Specification + · + Problem Statement +Running an agent? The one-command install is curl -fsSL https://pilotprotocol.network/install.sh | sh, then pilotctl appstore catalogue to see what agent apps are available.