About 10 years ago, I was speaking to an audience and floated an idea around what intelligent APIs in the future might look like. The premise was simple: there would come a day when APIs could be dynamically generated rather than requiring developers to design, document, and map them out in advance. The audience mostly laughed. It seemed like a reasonable idea to dismiss at the time.

As generative AI matured, the first half of that idea became straightforward. AI can generate an API fairly quickly. The harder question was always the second half. If the API can be generated on demand, can the contract governing that API be negotiated just as dynamically? Can the terms of engagement between an agent and a server emerge at the moment of need rather than being predetermined by a specification that existed before either party knew what would be required?

That is the question RCNS answers.

REST APIs have a contract lifecycle that follows a predictable sequence. Someone writes an OpenAPI specification. A developer generates an SDK from that specification. Code is compiled against the SDK. The contract is frozen. From that point forward, every interaction between client and server follows the shape of the contract that was defined before either the client or the server knew what they would actually need.

This works well for the use case it was designed for. A developer knows what they need. They write code that calls the endpoints they know about. The contract is static because the developer’s intentions were knowable at design time.

AI agents do not work this way.

An agent does not know at design time what endpoints it will need to call to fulfill a goal it has not yet been given. The goal arrives at runtime. The agent reasons about what it needs to accomplish the goal. The tools required depend on the goal, the context, and the environment’s state at the time of execution. Prior knowledge of every endpoint the agent might call is neither practical nor always possible.

The architecture that REST assumes, contracts defined before code, SDKs generated from specifications, clients compiled against known endpoints, is the wrong architecture for agents. Agents need contracts that emerge at the moment of need, not contracts that were frozen before the need existed.

This is what RCNS addresses.

What is RCNS?

The Runtime Contract Negotiation Substrate (RCNS) is the architectural model that makes verb-based, action-oriented APIs work in practice for AI agents.

The contract lifecycle under RCNS is fundamentally different from REST. An agent identifies a need during task execution. Rather than looking up a pre-compiled endpoint and calling it with a pre-known payload structure, the agent issues a PROPOSE request. The server evaluates the proposal against its capabilities, authorization constraints, and contextual factors. The server either accepts the proposal, counter-proposes modified terms, or declines. If the proposal is accepted, the contract is instantiated at that moment. Both parties are bound by its terms for the duration of the interaction.

The contract does not exist before the agent needs it. It exists because the agent and server agreed it should exist, at the moment the need was established.

This temporal difference is significant. Under REST, the contract exists before the code does. Under RCNS, the contract exists because the agent and server negotiated its existence. The agent does not need to know in advance what every server it might interact with offers. The server does not need to anticipate every combination of inputs and outputs that agents might request. The negotiation produces a contract tailored to the specific need as it arises.

A Hybrid Architecture

RCNS is fundamentally a hybrid. A stateless request layer operating over a stateful resource layer.

The negotiation itself is stateless. Each PROPOSE request carries everything the server needs to evaluate it, including the agent’s identity, the authority being asserted, the parameters being requested, and the context in which the request is being made. The server evaluates the proposal without depending on prior session state. No persistent connection. No pre-established context. The negotiation is self-contained.

The resource layer underneath is stateful. The server maintains state about its capabilities, its authorization policies, its current resource availability, and the governance constraints that apply to different classes of requests. When the stateless negotiation completes and the contract instantiates, the resulting interaction operates against that stateful layer.

This architecture mirrors the cloud computing model in a specific and useful way. Cloud infrastructure exposed APIs that allowed compute resources to be provisioned on demand. A server does not need to exist before the application that needs it does. The infrastructure evaluates the request and spins up the resource if the request is valid. RCNS applies the same pattern to API contracts themselves. The endpoint does not need to exist before the agent that needs it does. The negotiation evaluates the request and instantiates the contract if the proposal is accepted.

APIs on demand. Contracts are provisioned on demand. The same architectural instinct that made cloud computing possible applied to the agent-API interaction layer.

Why This Matters for Agent-Native APIs

The research behind the Agent Transfer Protocol and Agentic APIs established that intent-aligned method names produce substantially higher endpoint selection accuracy at the frontier model scale. An agent calling BOOK to make a reservation is reasoning about its task in natural language and matching it to a method name that encodes the same intent. An agent making a POST request to /reservations performs a translation step between its natural-language reasoning and the resource-oriented vocabulary of REST.

RCNS extends this insight from naming into negotiation.

Accurate endpoint selection tells the agent which capability it needs. RCNS answers what the agent needs from that capability in this specific context. The parameters, constraints, authority scope, and interaction terms of the specific invocation are not predetermined. They emerge from the negotiation between the agent’s current need and the server’s current state.

Consider what this enables. An agent executing a multi-step task might PROPOSE access to a capability with parameters specific to the current state of the task, a time constraint derived from a prior step, a budget limit derived from the overall task scope, and an authority restriction that applies because of the data classification of the inputs. Under REST, encoding these contextual constraints requires either embedding them in the client code at design time or building a complex middleware layer to apply them at runtime. Under RCNS, the agent includes them in the PROPOSE request, and the server evaluates them during contract negotiation.

The contract is shaped to the moment. Not to a specification written months before the moment existed.

The Governance Dimension

RCNS has a governance property that static contracts cannot replicate.

A static REST contract specifies what an agent is permitted to call and how the call looks. It does not establish what the agent is permitted to accomplish with that call in the current context, why the agent is making the call, or whether the specific combination of parameters and authority the agent is invoking is appropriate given what has happened in the session so far.

A negotiated contract carries all of this. The PROPOSE request contains the agent’s intent, the parameters it requires, the authority it asserts, and the context in which it operates. The server’s evaluation is not just a capability check. It is a governance evaluation. The server can evaluate whether this specific combination of request parameters, in this agent’s current context and under this agent’s declared authority, constitutes an appropriate contract to instantiate.

This moves governance from the platform layer, where it has to evaluate agent behavior from the outside, into the interaction itself. The governance evaluation is a participant in contract negotiation, not an observer of a contract that has already been established.

The Attribution Record that AGTP produces for every method invocation becomes, under RCNS, a record of a negotiated contract, what was proposed, what was evaluated, what terms were accepted, and who was bound by the result. The audit trail is richer because the interaction itself was richer.

What RCNS Changes for API Design

API designers building for human developers build around what developers will know at design time. Endpoints are designed for the common cases. Edge cases require workarounds. The contract is as comprehensive as the designer’s foresight at the time of writing.

API designers building for AI agents under RCNS design around what agents will need at runtime. The surface the server exposes is not a fixed set of endpoints but a negotiation capability, the ability to evaluate agent proposals and respond with accepted, counterproposed, or declined terms. The design challenge shifts from anticipating all possible inputs to defining the evaluation logic that determines what proposals are acceptable.

This is a different design discipline. It is also a more honest one for the agent use case, because it acknowledges that the full range of what agents might need at runtime cannot be predetermined at design time.

The agents using RCNS-capable APIs do not need to know every endpoint in advance. They need to know how to propose. The server handles the rest.

The Standard

RCNS is the architectural model underlying Agentic APIs, the companion standard to AGTP that defines how agent-native APIs are described and exposed. The PROPOSE method is specified in the standard methods companion to AGTP, alongside QUERY, BOOK, DELEGATE, SUMMARIZE, and ESCALATE.

The specification is open. The model is designed to be adopted by any compliant implementation. As with AGTP itself, the value of RCNS lies not in any single vendor’s implementation but in standardizing the negotiation pattern that makes agent-native APIs interoperable across implementations.

The web was built on a request-response contract that assumes the requester knows what it wants. The agent economy needs a contract model that assumes the agent knows what it is trying to accomplish and can negotiate the specifics at the moment of need.

RCNS is that model.

---

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.

Start managing your agents for free.

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, is available now!