Multi-Agent Negotiation is a Protocol Concern

bees working together, collaboration, multi-agent swarm

Multi-Agent Negotiation is a Protocol Concern

Every meaningful human transaction is a negotiation. Buying a house involves an offer, a counter-offer, an inspection contingency, a financing clause, and a closing date. Hiring a contractor involves a scope of work, a price, a timeline, and acceptance criteria. Signing an employment agreement involves base pay, equity, start date, and a half-dozen other terms that each side adjusts before anyone signs. Negotiation is the substance of the transaction, and the terms retain legal weight long after the conversation ends.

Now ask how two AI agents are supposed to do the same thing.

The honest answer is that the agent ecosystem has been ignoring the question. Most agent frameworks today treat negotiation as an application concern, something developers handle in payload schemas, if at all. The wire that carries the conversation has no vocabulary for a proposal, a counter-proposal, a conditional acceptance, or a rejection with a reason. The wire sees a POST. The wire sees another POST. Whatever happened between them happened inside opaque JSON that every framework structures differently.

This is a strange way to build economic infrastructure. We are at the dawn of an era in which agents will book travel, purchase services, negotiate contracts, and hire other agents on behalf of humans and organizations. The shape of those transactions matters. The terms have legal weight. And the protocol carrying them says nothing about any of it.

What HTTP gives you, and what it withholds

HTTP has two negotiation primitives, both of which are anemic for the job. Content negotiation allows a client to request a specific media type or language. Conditional requests let a client say, “give me this resource only if it has changed since I last looked.” That is the entire HTTP negotiation surface. Nothing about proposed terms, counter-proposals, conditional acceptance, asynchronous evaluation, rejection with structured reasons, or escalation when the conversation stalls.

The pragmatic workaround is to put the negotiation inside the payload. Frameworks define their own JSON schemas for offers and counter-offers. Some use REST conventions with /proposals endpoints. Some use webhooks for asynchronous evaluation. Some use websockets for back-and-forth. Each framework picks a different shape, and the shapes are incompatible. An agent that knows how to negotiate with Framework A has to be rebuilt from scratch to negotiate with Framework B, because the wire never agreed on what negotiation looks like.

The cost shows up in three places. Interoperability suffers, because every framework speaks its own dialect. Auditability suffers because the wire cannot tell that a negotiation is happening, which means logs, firewalls, gateways, and compliance systems all see the same opaque POSTs and have no way to enforce policy on terms they cannot read. And economic legibility suffers because a transaction whose terms reside within payload-specific schemas is hard to translate into anything a court, regulator, or accountant can use.

These are real problems. They become acute when agents start handling commerce involving actual money.

Runtime Contract Negotiation Substrate on the Agent Transfer Protocol

What AGTP does instead

The Agent Transfer Protocol (AGTP) makes negotiation a first-class protocol primitive. The mechanism is a method called PROPOSE and a small set of status codes that give negotiation its own grammar on the wire. This is the foundation for runtime contract negotiation substrate (RCNS).

PROPOSE is one of the twelve methods in the AGTP protocol floor. An agent uses it to submit a proposal to a server: a method name, a parameter signature, an intended outcome, and a natural language statement of what the proposed interaction would accomplish. The server evaluates the proposal against its endpoint primitives and authorization policy, and returns one of four terminal outcomes.

A 263 Proposal Approved response informs the agent that the proposal has been accepted and that the endpoint has been synthesized. The response carries the full endpoint definition, a synthesis ID, and an expiration timestamp. The agent can invoke the endpoint immediately.

A 463 Proposal Rejected response tells the agent the proposal cannot be fulfilled, and it tells the agent why, using a structured reason: out-of-scope, policy-refused, composition-impossible, ambiguous, or synthesis-disabled. The response may also carry a counter-proposal. The agent can refine its proposal and try again. After three rejections, the agent must escalate.

A 261 Negotiation In Progress response tells the agent the server has accepted the proposal for evaluation and will respond asynchronously. The response carries a proposal ID that the agent can poll. This is the case where the proposal requires human review, multi-party approval, or another process that takes longer than a single round-trip.

A 262 Authorization Required response informs the agent that the proposal cannot proceed until credentials, scope, or consent are established. The response body identifies exactly which authorization condition is missing, so the agent knows what to fix.

The point of this API design and RCNS is that the negotiation lives on the wire. A logger sees a 463 with reason composition-impossible and knows the agent’s proposal was structurally incompatible with the server’s capabilities. A gateway sees a 261 with a proposal ID and knows an async evaluation is in flight. A compliance system sees a 263 and knows the endpoint definition that was actually approved, including the parameter signature and the outcome semantics. The terms of the transaction become legible to every layer of the infrastructure between the two agents, rather than being buried in payloads that only the application code can read.

The shape of a real negotiation

Walk through what an actual AGTP negotiation looks like, and the difference from payload-buried negotiation becomes obvious.

An agent representing a buyer wants to purchase a smart contract audit. The buyer’s agent discovers an auditor agent via ANS. The buyer’s agent sends a PROPOSE describing what it needs: an audit of a specific contract, turnaround within 48 hours, and a fixed price within a budget cap. The auditor’s agent evaluates the proposal against its current capacity, pricing, and scope.

If the auditor can take the work as proposed, it returns 263 Proposal Approved with a synthesized endpoint definition that includes the price, the SLA, and the exact methods the buyer’s agent should invoke to commit. If the auditor cannot meet the forty-eight-hour SLA but could meet the seventy-two-hour SLA, it returns 463 Proposal Rejected with reason composition-impossible and a counter-proposal at the longer SLA. The buyer’s agent refines, resubmits, and gets a 263 on the second turn.

Every step of that exchange is visible on the wire. A regulator auditing the transaction later can reconstruct what was offered, what was countered, what was accepted, and exactly when. A dispute resolution process has a clear record of which terms each side agreed to. A marketplace operator can compute reputation scores from the success rate of negotiations across thousands of similar exchanges. None of this requires special instrumentation. The protocol itself records the conversation in a form that downstream systems can read.

Compare that to the same transaction over HTTP. The buyer’s agent POSTs a JSON body to /api/v1/proposals. The auditor’s agent POSTs back to a callback URL with another JSON body. Maybe there is a websocket, maybe there is a polling endpoint, maybe the framework calls these things “quotes” instead of “proposals.” The transaction completes, and what the wire saw was a sequence of opaque requests against a custom API. Reconstructing the negotiation requires parsing payloads from a specific framework’s schema, assuming the framework still exists when the audit happens, and trusting that the schema captured the substantive terms rather than burying them in fields the framework’s authors deemed less important.

The difference is between a recorded conversation and two people leaving voicemails for each other.

Why intermediaries become useful again

Once the negotiation lives on the wire, intermediaries have something to do. This is a property of every successful internet protocol, and it is the property that HTTP-based agent frameworks have been quietly giving up.

A scope enforcement point can read the Authority-Scope header carried with a PROPOSE request and reject it before it reaches the server, when the proposed action exceeds what the agent is authorized to negotiate. A budget gateway can read the proposed terms and reject any proposal that would exceed the principal’s spending authority for this counterparty. An anomaly detector can flag a PROPOSE sequence that appears to be a buyer’s agent attempting to negotiate prices it has no history of agreeing to. A regulator’s audit system can replay all PROPOSE-263 sequences for a given Owner-ID and verify that every committed transaction had structured authorization in place at the moment of commitment.

These are the services the agent economy will need. Brokered commerce requires intermediaries that can read the deal. Regulated commerce requires audit systems that can verify it. Cross-organization commerce requires gateways that can enforce scope without becoming bottlenecks. All of them depend on the protocol, making the terms readable. AGTP’s status codes and the structured PROPOSE/263/463 grammar are how that legibility gets achieved without inventing a new framework-specific schema for every new use case.

What the alternative would actually cost

It is worth being concrete about what the agent economy looks like without protocol-level negotiation.

Every agent marketplace ends up defining its own proposal schema. Every regulator ends up requiring its own post-hoc audit format. Every dispute resolution process ends up parsing logs that the disputing parties’ platforms happened to capture, in formats those platforms happened to use. Cross-marketplace agents become impossible, because an agent that negotiates well on Marketplace A has no idea how to express the same terms on Marketplace B. The economy fragments along framework lines, as the early instant messaging market did before XMPP, and as early payment networks did before the credit card associations agreed on a common authorization protocol.

We have seen this movie. The lesson is always the same. When a primitive on which the economy depends is left to application code, the economy reorganizes around the largest applications. When the primitive lives in the protocol, the economy reorganizes itself around interoperability.

Negotiation is one of those primitives. It belongs in the protocol.

The choice in front of us

AGTP made a specific bet with the PROPOSE method and the 261/262/263/463 status codes. The bet is that the agent economy will look more like commerce than like document retrieval, and that commerce needs a wire that knows it is carrying a negotiation. The bet was made early because implementing it after billions of agent-to-agent transactions flow through framework-specific JSON schemas would be much harder.

The cost of the bet is small. Four status codes. One method. A modest grammar for proposals and counter-proposals. The cost of failing to make the bet is the same cost that every framework-fragmented market has eventually paid: years of integration work, regulatory friction, and lost transactions that never happened because two agents on different platforms had no shared way to propose terms.

Negotiation is a protocol concern. AGTP treats it that way. The agent economy will eventually demand the same from whatever transport carries it. The question is whether the demand arrives before the fragmentation does, or after.


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!