HTTP turned 35 this year.

It has outlasted every prediction made about it. It survived the browser wars, the mobile revolution, the API economy, and the cloud. It is the most successful application-layer protocol ever written.

It was also designed for humans clicking links in 1991.

That was fine for a long time. And then we started building AI agents.

Give Agents their own Lane

AI agents are not humans. They do not click links. They do not browse. They execute complex, multi-step workflows, querying data, booking resources, delegating tasks to other agents, and escalating decisions to human principals at machine speed, with no supervision per transaction.

When an agent intends to summarize a document, it sends a POST request. When it intends to book a flight, it sends a POST request. When it intends to delegate a task to another agent, it sends a POST request.

Three completely different intentions. Three identical verbs. The server has no idea what the agent actually wants until it parses the request body, if it parses it at all.

That is an architectural challenge.

HTTP carries no native mechanism to distinguish agent traffic from human traffic at the infrastructure layer. It provides no protocol-level vocabulary for agent intent. It has no built-in concept of agent identity, authority scope, or attribution. Its method registry is frozen. Adding new semantic verbs to HTTP requires full IETF consensus and backward compatibility with every HTTP client, server, proxy, and middleware component deployed globally.

You cannot extend your way out of this. You need a new protocol.

What is the Agent Transfer Protocol (AGTP)

Today, I published the Agent Transfer Protocol, (AGTP), as an IETF Internet-Draft: draft-hood-independent-agtp-00.

AGTP is a dedicated application-layer protocol for AI agent traffic. It sits above TLS and below any agent messaging protocol. It is composable with MCP, ACP, A2A, and ANP. It does not replace those. It provides the transport layer they should run on.

The core of AGTP is three things:

Intent-based methods. AGTP replaces resource-manipulation verbs with agent-native intent verbs such as QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, and NOTIFY. These express what an agent is actually trying to do at the protocol level, rather than hiding meaning in a POST body. A three-tier method vocabulary extends beyond the core ten with standard extended methods such as FETCH, SEARCH, VALIDATE, TRANSFER, and MONITOR, along with industry-specific profile methods for healthcare, financial services, legal, and infrastructure use cases. You can read more about this premise at AgenticAPI.com.

Every AGTP agent has an identity. Agents are identified by a canonical 256-bit cryptographic identifier expressed as a URI:

agtp://3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d4e8b2a5f9c3d7e1b0a4f8c2d6e0b

For human readability, AGTP supports an optional hierarchical naming layer using the .agent or .nomo packaging format:

agtp://research-assistant.engineering.acme.agent
agtp://procurement-bot.finance.acme.agent
agtp://customer-experience.acme.nomo

Friendly names are aliases only. They resolve to the canonical identifier. The Agent-ID header always carries the cryptographic form. Organizations with thousands of agents can group them by department, role, and version without sequential numbering or brittle registries. Name registration is tied to the governed activation flow; only agents that have completed activation can claim a name.

Protocol-level identity. Every AGTP request carries Agent-ID, Principal-ID, and Authority-Scope. Infrastructure can determine who the agent is, who authorized it, and what it is permitted to do before the request reaches the application layer. An optional Agent Certificate extension provides cryptographic verification at the TLS handshake for deployments that require it.

Governance primitives. ESCALATE is a first-class method, not an error code. An agent that escalates appropriately is functioning correctly. Authority scope is declared and enforced at the protocol level. Delegation chains are tracked. Attribution records are built in. Accountability becomes part of the infrastructure, not an afterthought.

Why This Matters Now

The infrastructure for AI agents is being built right now. Most of it relies on HTTP because it already exists and because no better transport-layer alternative has been offered.

Decisions made in the next 12 to 24 months about how agent traffic moves across networks will be hard to reverse. Protocol choices tend to calcify quickly. The window for a better architecture to take hold is still open, but it will not stay open for long.

MCP, A2A, and ACP solve real problems at the messaging layer. None of them addresses what happens below that layer. All of them inherit HTTP’s limitations because they sit on top of it. That is not a flaw in those protocols. It reflects a gap they were never designed to fill.

AGTP is built to fill that gap.

The Stack

AGTP is transport-agnostic. It prefers QUIC for new implementations and supports TCP/TLS for compatibility. It is designed to be implemented alongside existing infrastructure, not to require a wholesale replacement.

The Positioning

The analogy I keep coming back to is SMTP and TCP.

SMTP is a messaging protocol that runs over TCP. It defines what email looks like and how mail servers communicate. It does not replace TCP. Saying “TCP is unnecessary because SMTP exists” is a category error.

The same logic applies to the current agent protocol landscape. MCP defines what agents say to tools. A2A defines how agents communicate with each other. Neither defines how agent traffic moves across a network. They assume HTTP as their transport protocol and inherit its limitations.

AGTP is TCP to their SMTP. Different layer. Different job. Compatible with all of them.

IP and Openness

The core AGTP specification, including all base methods, header fields, status codes, and IANA registrations, is dedicated to the public domain under CC0. It is open. Royalty-free. No license required.

Two optional extensions (the Agent Certificate extension and the ACTIVATE method for governed agent deployment) are subject to pending patent applications. Those extensions are also available under a royalty-free commitment, consistent with IETF RFC 8179 standards. The IP disclosures are filed with the IETF Secretariat.

The open core is the point.

What Comes Next

The Internet-Draft is the beginning of a process, not its end. The IETF community will stress-test the method definitions. Protocol engineers will challenge the transport model. Security researchers will probe the threat model. That process is how a draft becomes a standard.

What I am looking for right now:

Protocol engineers and AI infrastructure builders who want to build prototype implementations. Even a minimal AGTP server that speaks the headers is valuable; implementation reports strengthen the case for adoption by the working group.

IETF participants who can help identify the right working group home for this work. The DISPATCH mailing list is the starting point, and I will be posting there shortly.

AI developers building on MCP, A2A, or ACP who are already thinking about the transport layer questions AGTP addresses.

The infrastructure for agentic AI is being built right now, by default, on foundations designed for human users.

AGTP is a proposal to deliberately do that.

---

Links

IETF Internet-Draft: https://datatracker.ietf.org/doc/draft-hood-independent-agtp/

GitHub: https://github.com/nomoticai/agent-transfer-protocol

IPR Disclosures: https://datatracker.ietf.org/ipr/

---

If you find this content valuable, please share it with your network.

Follow me for daily insights.

Book me to speak at your next event.

Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, will be published in 2026.