In early 2025, I set out to build something simple: an agent that could shop on behalf of a customer. At that point, only MCP existed. You could wire an agent to tools, and that was the whole stack for agent commerce.
The first thing I ran into wasn't a discovery problem or a payment problem. It was a negotiation problem.
A gap hiding in plain sight
Merchants wanted to sell. They had surplus capacity, tiered pricing, off-peak slots, inventory they'd rather move at a small margin than not sell at all.
Customers wanted to buy. They had flexibility on timing, willingness to accept a different seat or room or SKU for a better price, priorities that weren't a flat "cheapest."
But between them — in the agent era — no mechanism existed to actually let that conversation happen. The list-price, take-it-or-leave-it model works when human attention is the bottleneck. It doesn't need to keep working that way once agents handle the conversation.
What 2025 added — and didn't
Through 2025, the agent commerce stack filled in fast:
- MCP (Anthropic) — agent discovery and tool invocation.
- ACP (OpenAI + Stripe) — agent-initiated checkout and payment.
- UCP (Google) — a universal commerce envelope.
- A2A (Google) — agent-to-agent transport.
- TAP, Agent Pay, and adjacent standards — more payment rails for agents.
You could now send a buyer agent to browse merchant offerings via MCP or UCP, and you could settle a purchase via ACP or TAP or Agent Pay. Discovery and settlement got genuinely better.
The negotiation gap stayed.
That's when it became clear this wasn't going to solve itself as a side effect of someone else's protocol. The existing stack answers how does an agent find a merchant? and how does an agent pay a merchant? — but skips the step where they agree on terms. When two agents have different views of what's fair, there's no standard to arbitrate that without building a bespoke solution that tends to favor whoever built it.
What the agent era can bring back
Before the digital era, people negotiated. Markets, small business, direct sales — anywhere a customer and a merchant met in person, some form of negotiation happened as a matter of course. Digital scale made that economically impossible: merchants couldn't run individual negotiations with every customer, so they posted list prices and everyone took them. Efficiency won, optionality lost.
AI agents dissolve that constraint. An agent can run thousands of negotiations in parallel, at near-zero marginal cost. The question isn't "can we afford to negotiate at scale?" anymore — it's "what are the rules of negotiation in the agent era?"
That question is what OANP answers.
Why this needs its own protocol
Three reasons this layer deserves its own spec rather than being folded into MCP, ACP, or UCP.
Different semantics. MCP is about making tools discoverable and invocable. ACP is about completing a transaction. Negotiation is about reaching agreement. The data model is different (sessions, rounds, constraints, concessions) and the failure modes are different (impasse, bad faith, asymmetric information). Shoehorning negotiation into a discovery or payment protocol produces awkward fits in both directions.
Arbitration is a trust boundary. Payment protocols assume the parties have already decided to transact. Negotiation is the phase where they decide. For that phase to be trusted, it generally needs a third party who is structurally neutral — not the buyer, not the merchant, and not chosen by either. That's a different trust topology from the one MCP or ACP assume.
Fairness has to be mechanically checkable. A negotiation outcome can be reviewed after the fact only if the full message history is preserved, canonicalized, and signed against a known set of rules. A protocol that specifies those rules — and specifies them precisely enough that a third party can test conformance — is a protocol that turns "fair" from a marketing claim into a verifiable property.
What we're publishing today: OANP v0.1
The Open Agent Negotiation Protocol (OANP) is the draft specification for this layer. As of today, v0.1.0 is published. The specific mechanisms are novel enough that we've also filed a patent on the implementation technique — but the protocol itself is Apache 2.0. The patent covers how you might build it; the spec covers what a conformant session must look like from the outside. Anyone implementing against the observable semantics is free to do so under the open license.
Three files in the spec, about 600 lines total:
- Message format (
spec/v0.1/message-format.md). Seven message types, plain JSON with atypediscriminator. JWS detached signatures on the finalsession.agreeartifact only. JCS canonicalization for anything hashed. - Arbitration flow (
spec/v0.1/arbitration-flow.md). A three-role state machine (Buyer, Arbiter, Merchant) with a happy path, a fairness-violation path, retry/idempotency rules, and a worked flight-negotiation example. - Fairness invariants (
spec/v0.1/fairness-invariants.md). Seven invariants (I1–I7) that a conformant session must satisfy — bounded rounds, symmetric information to the arbiter, constraint immutability within a session, monotonic concession, per-round fairness verdict, signed final artifact, auditable history. A default fairness profile with a scoring function.
OANP is designed to coexist with, not replace, the existing stack:
- MCP-carried OANP — negotiation messages can travel inside MCP tool calls. Agents already speaking MCP add a new tool namespace, not a new transport.
- ACP-compatible output — the signed
session.agreeartifact slots cleanly intocheckout_session.createmetadata. The agreement becomes the authorization for payment. - Protocol-neutral roles — Buyer, Arbiter, Merchant are defined independent of any specific implementation. The arbiter role can be filled by the merchant, the buyer, or an independent party, provided the party commits to the invariants.
The three-role model
Two-party negotiation has a structural problem: each party's view of "fair" is self-interested. OANP assumes a third role, the arbiter, whose job is not to win but to judge.
The arbiter receives every message both parties send. It runs a fairness function (either the default default/v0.1 profile or a custom one agreed at session open) against each round. It publishes a verdict per round. If either party's move breaks an invariant, the arbiter rejects the round and the session is either retried or closed.
Crucially, the arbiter's rules are not a policy document — they are a mechanically checkable specification. Anyone with the full message log can verify, post hoc, whether the arbiter did its job correctly. That's what distinguishes OANP from a dispute-resolution service.
We expect arbiters to be fulfilled by many parties: by platforms (who want to certify their own marketplace), by independent non-profits, by merchant consortiums, by specialized startups. The same pattern as DNS resolution or TLS certificate issuance — multiple implementations, one protocol, one set of invariants.
What's explicitly out of scope for v0.1
So the spec stays readable in under an hour:
- Multi-merchant sessions. Negotiation between one buyer and many merchants simultaneously. v0.1 is one buyer, one merchant, one arbiter.
- Zero-knowledge proofs on merchant constraints. Merchants may want to prove "my floor price constraint was respected" without revealing the floor. Great idea, not in v0.1.
- On-chain arbiter registries. Distributed arbiter discovery / reputation scored on a public chain. Interesting, not urgent.
- Arbiter ranking / reputation. How arbiters build trust and get chosen. Part of the protocol's long-term success, but not a v0.1 problem.
These are candidates for v0.2 if the community agrees they're important enough.
What we want you to break
OANP is a draft. We want critique, specifically:
- Where we've over-fit the envelope to the domain we came from (flight bookings)
- Gaps in invariant coverage — sessions where all seven invariants are satisfied but fairness still intuitively isn't
- Transport-level awkwardness when embedding in MCP or ACP flows
- Alternative fairness profiles for non-price domains (support escalations, compute scheduling, supply negotiation)
Issues on github.com/oanp-protocol/spec are the front door. We're also reachable as @oanpdev on X.
Why travel as the testbed
We chose travel as the first domain to prove the protocol's mechanics. Not because travel is the biggest agent commerce market — it isn't — but because travel has the highest friction in commerce: booking commissions, change fees, premium-class markups, opaque pricing, fare-class surplus. If the protocol survives travel's margin structure, the mechanics translate down to general ecommerce, where service fees are much lower.
Starting with ecommerce would have been the opposite move: the margins wouldn't have left room to validate the negotiation economics, and any design choice would read as over-engineered. Travel gave us the margin headroom to prove the thesis. Ecommerce is the scale expansion once the thesis holds.
You'll see that reflected in the worked example on the docs site — an SFO → JFK negotiation. The protocol itself is domain-agnostic; flights are the first proof point.
Governance
The protocol is Apache 2.0. The organization on GitHub is oanp-protocol. Governance is deliberately left placeholder in v0.1: as contributors arrive, we'll formalize into something closer to a working group with published decision records.
The reference implementation lives at oanp-protocol/reference. Alternative implementations in any language are welcome; the conformance checklist and invariants are the source of truth, not any single implementation.
What happens next
- v0.2 takes the feedback that arrives over the next few weeks and picks the highest-impact extensions — likely multi-merchant sessions and a richer set of default fairness profiles.
- Integration examples for MCP and ACP will be written against the reference implementation, showing end-to-end discovery → negotiation → payment flows.
- Second domain — beyond travel, the reference implementation will extend to a general ecommerce example to validate that the mechanics translate to lower-margin categories.
The gap was real. The layer is specifiable. Here is v0.1.
— Madhav Ravipati, maintainer.