I’ve been saying that the API is due for an evolution. An upgrade. A modernization that aligns more with what is needed in today’s systems, and specifically for AI agents. It’s not that APIs are bad. The API was one of the most consequential inventions of the internet era.

But, primarily, they were designed by humans, for humans. Even when machines were making the calls, humans wrote the code that enabled them. The entire vocabulary of endpoints, resources, HTTP methods, and status codes was optimized for human legibility. A developer could read a REST API like a sentence. GET /users/123. POST /orders. DELETE /sessions/active. The grammar was simple, the nouns were clear, and a reasonably experienced engineer could navigate an unfamiliar API in an afternoon.

And by the way, I fought for this standardization and design approach for well over 15 years.

That was the design assumption: a human in the loop, writing the code, reading the documentation, making the judgment calls.

That assumption is no longer universally true. I previously discussed experience-based design paradigm for APIs a few years ago. Even over the short span of two years, AI has impacted not only how humans communicate, but how systems communicate. This change requires APIs to evolve more than most are considering.

The Agent Has Entered the Building

AI agents do not read documentation. They do not browse API references or make judgment calls about which endpoint to call. They reason about what they need to do, form an intent, and attempt to execute it. They operate at machine speed, across dozens of services simultaneously, without supervision per transaction. And they do all of this using the same infrastructure that was designed for humans writing code in an afternoon.

The mismatch is architectural.

When an agent needs to summarize a document, it sends a POST request. When it needs to book a resource, it sends a POST request. When it needs to delegate a task to another agent, escalate a decision to a human, or notify a downstream system, the answer is POST, POST, POST again. Three completely different intentions. One generic verb. The server receives identical methods with meaningfully different purposes buried in request bodies, invisible to any infrastructure component that might want to route, govern, or monitor what is actually happening.

REST was not designed for this. HTTP was not designed for this. They were designed for humans clicking links and developers writing integrations. The vocabulary was always a translation layer, a mapping from what a system needs to do onto a small set of resource-manipulation primitives. For human developers, that translation was invisible, absorbed into the act of writing code. For AI agents, there is a friction between how they reason and how they must speak.

And this is now possible through the proposed Agent Transfer Protocol (AGTP).

The Method Name Is the Intent

The most important shift in the Agent Transfer Protocol is not a new header or a new status code. It is a different answer to a foundational question: what should a protocol method say?

REST methods describe operations on data. GET retrieves. POST creates. PUT replaces. DELETE removes. These are programmer primitives. They tell you what is happening to a resource. They do not tell you why.

AGTP methods describe agent actions. QUERY. SUMMARIZE. BOOK. SCHEDULE. LEARN. DELEGATE. COLLABORATE. CONFIRM. ESCALATE. NOTIFY. These are not just names. They are the natural language of agentic work expressed as protocol primitives.

When an LLM-based agent needs to summarize a document, it does not need to translate its intent into a foreign vocabulary. It does not need to map “I need to summarize this” onto POST /documents/process with a body that says {“operation”: “summarize”}. The method IS the intent. SUMMARIZE means summarize. BOOK means book. ESCALATE means escalate.

This matters for a reason that goes deeper than convenience. LLMs are language models. They plan in natural language. They reason in natural language. When they need to act in the world, REST forces a translation from their native reasoning layer into a vocabulary designed for something else entirely. AGTP eliminates that translation layer. The protocol speaks the same language the agent already thinks in.

The method vocabulary extends beyond the core ten. FETCH, SEARCH, VALIDATE, TRANSFER, MONITOR, PUBLISH, DELEGATE, REPORT. These are not arbitrary additions to a registry. They are the natural language of what agents do, codified as protocol-level primitives. The more complete the vocabulary, the less translation the agent needs to perform. The fewer translations, the fewer errors, the less hallucination, the more predictable the behavior.

This is not a minor optimization. It is a different philosophy of what a protocol is for.

From Authentication to Identity

Today’s APIs know a token. They do not know who is calling, why, or what they are authorized to do beyond the binary of valid or invalid. A token is a credential. It proves that someone, somewhere, at some point, generated a secret that matches. It says nothing about intent, accountability, or scope.

AGTP-era APIs know an agent. Every request carries an Agent-ID identifying who is acting, a Principal-ID identifying who authorized it, and an Authority-Scope declaring what it is permitted to do. These are not application-layer additions. They are protocol primitives, present on every request and visible to every infrastructure component along the path.

The difference between a token and an identity is accountability.

When something goes wrong with a token-authenticated request, you know a token was used. When something goes wrong with an AGTP request, you know which agent acted, under whose authorization, within what declared scope, and at what time. The attribution record is not a log you have to build. It is a protocol feature you get by default.

This matters more as agents become more capable. An agent that can book flights, execute purchases, modify records, and delegate to other agents can cause real harm if it acts outside its authority. A protocol that carries no identity cannot be governed.

From Documentation to Negotiation

A REST API is documented for a developer to read. The developer reads the documentation, writes the integration, and ships the code. The API and the caller are coupled at development time, by a human, through documentation.

AGTP introduces a new beginning. The Supported-Methods header returned at session establishment tells the caller what the server can do, at runtime, in machine-readable form. An agent connecting to an AGTP server does not need to have read the documentation in advance. It discovers the capability space at the moment of connection.

This is the first step toward APIs that negotiate with their callers rather than simply responding to them.

The next step is already technically feasible. An agent that does not find the capability it needs could request it. A capability-construction layer, operating within the agent’s declared Authority-Scope, could synthesize the endpoint, spin up the handler, and make it available within seconds. The agent DELEGATEs to a construction service. The construction service PUBLISHes the new capability. The agent calls it. The entire exchange is traceable, scoped, and revocable.

This sounds like science fiction. It is not. The components exist today: language models that can generate API specifications from natural-language descriptions, serverless infrastructure that deploys in milliseconds, and orchestration layers that wire capabilities together at runtime. The missing piece was a protocol to govern this exchange rather than leave it chaotic. AGTP provides the governance primitives. On-demand capability creation becomes safe not because the agent cannot create arbitrary APIs, but because the agent can only create capabilities within its declared authority scope, every action is attributed, and the ESCALATE method exists for the cases where the agent should not proceed alone.

The API That Does Not Exist Yet

There is a scenario that REST cannot handle and that nobody has seriously designed for: an agent that needs a capability that does not exist.

In the current model, this is a dead end. The agent hits a 404 error, then waits for a human to build the missing integration. That model assumed the caller was a human writing code once and running it many times. It assumed capability gaps were rare and that the right response to them was human intervention. Both of those assumptions are breaking down.

An AI agent executing a complex workflow may encounter capability gaps constantly. It needs to summarize a document in a format no existing endpoint produces, validate data against a schema defined this morning, or route a task to a service that did not exist when the agent was deployed. It cannot stop and wait.

The components for creating an on-demand API already exist. A language model can generate an API specification from a plain-language description of the requirements. Serverless infrastructure deploys handlers in milliseconds. Orchestration layers wire new endpoints into existing capability spaces. What has been missing is the governed exchange layer that makes this safe rather than anarchic.

AGTP provides that layer. The Authority-Scope declaration constrains what an agent can request, an agent with documents:summarize in its scope can request a new summarization capability, but not one that requires payments:transfer. The DELEGATE method provides the exchange primitive, allowing an agent to request a capability from a construction service within its declared authority. The attribution record closes the accountability loop ensuring every step is logged, traceable, and auditable.

This is not a model where agents create arbitrary APIs with arbitrary permissions. It is a model where agents request capabilities that fit within their existing authority, fully attributed, within a governed exchange. The difference between those two things is the difference between an autonomous system that can adapt and one that can do anything it wants.

The boundary between the APIs that exist and the APIs an agent can use becomes dynamic. Not unlimited. Not ungoverned. Dynamic. An agent deployed today can operate effectively in an environment it was not explicitly programmed for, as long as the capabilities it needs fall within its declared authority and the infrastructure can construct them.

Whether this exchange gets standardized as part of AGTP or a companion specification remains an open question. The technical primitives are in place. The governance model exists. The only thing left to decide is whether we design this capability deliberately or wait for it to emerge without guardrails.

From Error Codes to Governance Signals

HTTP 404 means not found. HTTP 403 means forbidden. These are protocol states, things that went wrong at the technical layer.

AGTP 451 means something different. It means an agent attempted to take an action outside its declared authority scope. That is not a technical error. It is a governance event.

The distinction matters for how you respond to it. A 404 triggers a retry or a fallback. A 451 triggers an audit entry, a review, and possibly a policy change. The same number in a different protocol carries a completely different operational meaning.

ESCALATE sharpens this further. In REST, escalation to human oversight is application logic that someone has to build, wire, test, and maintain. It is an edge case in most codebases. In AGTP, ESCALATE is a first-class protocol method. An agent that fires ESCALATE when it should, because its confidence is below threshold, because the action is outside its scope, because the instruction is ambiguous, is not failing. It is functioning correctly.

This reframes what governance means in agent systems. It is not a layer you add on top. It is a vocabulary you build from the start. The protocol either has primitives for accountability or it does not. REST does not. AGTP does.

From Stateless to Contextually Aware

REST is stateless by design. Each request carries everything the server needs to respond. There is no memory of what came before, no awareness of why the data is being requested, no understanding of where the result is going.

AGTP’s session model changes this. A persistent session carries context throughout an agent’s task lifecycle. The LEARN method explicitly writes to the agent’s context. Every method accepts a context parameter that carries session state forward. An agent summarizing a document knows what it has already summarized, what it is trying to accomplish, and who will read the result.

But the more important contextual shift is the one already described: the method name itself carries context. An API that receives SUMMARIZE knows more about the caller’s intent than an API that receives POST. The verb is not just a routing instruction. It is a semantic signal about what kind of response is appropriate, what kind of processing makes sense, and what the caller actually needs.

This creates a more natural relationship between agent and API. Not the caller and endpoint. Not developer and documentation. Something closer to a task and the capability that fulfills it.

The Window Is Closing

The history of APIs is largely a history of bolting security on after the fact. REST was designed for openness and convenience. Authentication, authorization, rate limiting, abuse prevention all came later, added layer by layer as the threats materialized. The result is the security surface that enterprise organizations spend enormous resources defending today.

We are at an earlier moment with agentic APIs. The infrastructure is being built right now, largely by default, largely on the REST patterns that already exist because those patterns are familiar and available. The agents are already calling these APIs. The volume is already growing. The defaults are already solidifying.

AGTP is not a finished standard. It is a proposal, a draft submitted to the IETF as draft-hood-independent-agtp-00, with a working reference implementation and an open invitation for the protocol engineering community to stress-test it. It is an argument that the transport layer for agent traffic deserves deliberate design rather than an inherited assumption.

The question worth sitting with is this: what governance primitives are you assuming will exist in your agent infrastructure that nobody has actually built into the protocol yet?

---

Links

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

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.