A202: A Verifiable Agreement Protocol for Agent-Led Commerce

Abstract

Software agents can now discover each other, communicate, and initiate payments. What the current agent stack does not yet give two independent organisations is one shared way to form an agreement that either side can later verify, under authority that either side can later check. Communication and payment protocols answer how messages travel and how value may move; they do not by themselves answer who authorised a commercial commitment, what exactly was agreed, what disclosures the protocol interaction permitted, and what can be reconstructed when the outcome is disputed. A202 is an open, carrier-neutral specification of this missing layer. It defines typed objects for delegated commercial authority, explicit transaction and negotiation state, disclosure rules, and a deterministic verification procedure that an authorised party can run over a disclosed signed record with no privileged access to any operator. The specification is accompanied by an executable conformance suite of 148 fixtures, weighted deliberately toward refusal: most fixtures present something an implementation must reject. This paper describes the protocol's design, its threat model, its conformance methodology, and its relationship to adjacent protocols including A2A, MCP, AP2, ACP, and UCP. A202 is published under the Apache License 2.0 at https://github.com/a202-protocol/a202, with documentation at https://a202.org.

1. Introduction

Commerce between independent organisations rests on questions that are older than software: who is this counterparty, who inside it authorised this act, what exactly was agreed, and what happens when one side disputes the outcome. Between humans, these questions are answered by institutions: signatures, contracts, purchase orders, audit trails, and courts. Between software agents acting for independent organisations, the current agent stack does not provide one shared answer.

The infrastructure around this gap is maturing quickly. The Model Context Protocol gives a model structured access to tools and context [1]. The Agent2Agent protocol gives agents a common way to discover each other and exchange tasks across vendors and frameworks [2]. Payment protocols, including the Agent Payments Protocol, the Agentic Commerce Protocol, and x402, give agents ways to move value with user authorisation attached [3, 4, 5]. Commerce surfaces such as the Universal Commerce Protocol connect agents to merchant systems across the shopping lifecycle [6].

Each of these answers a communication, commerce, authorisation, or settlement question. These layers do not by themselves answer the commitment question. When two agents acting for different companies negotiate terms and reach an agreement, the stack still needs a shared, verifiable answer to four things:

• Authority. Who inside the counterparty organisation authorised this act, what exactly was the acting agent permitted to commit to, and was this act inside that permission?
• State. What state is this transaction in, and which signed event moved it there? A message is not a state change; a model output is not a state change.
• Disclosure. What was the other side permitted to receive through the protocol interaction, and what disclosures were recorded? In competitive settings, this question can carry as much value as the price. Side channels and communication outside the protocol remain outside this claim.
• Record. If the outcome is disputed a year later, what can be reconstructed, by whom, and from what, without trusting either party or any intermediary?

A202, the Verifiable Agreement Protocol for Agent-Led Commerce, is an open specification of this layer. It is carrier-neutral by construction: it defines what commercial objects mean, not how they travel, so the objects it defines can be carried by A2A, exposed to a model through MCP, or exchanged over plain HTTPS without changing what they mean. Its name is drawn from HTTP status 202 Accepted, and the specification makes the association literal: an accepted submission returns 202, and no carrier status is ever acceptance of an offer, because acceptance is a signed object rather than a transport outcome.

This paper is a companion to the specification rather than a substitute for it. Section 2 states the problem in more detail. Sections 3 through 8 describe the protocol's design: its principles, object model, authority chain, negotiation state, verification procedure, and conformance methodology. Section 9 summarises the threat model. Section 10 describes composition with carrier protocols. Section 11 relates A202 to adjacent work. Section 12 states the specification's current status and limitations plainly.

2. The missing layer

Consider a procurement transaction between two organisations that have never transacted before: a buyer's agent soliciting sealed bids for a freight contract, or committing to a calibration service under a spending limit set by a human principal. Three failure classes distinguish this setting from both consumer checkout and intra-organisational automation.

Unauthorised commitment. An agent holds legitimate credentials but acts beyond what its principal intended: it commits to a price above its ceiling, a scope outside its mandate, or a counterparty it was never permitted to bind. In current systems the counterparty has no way to check the boundary of the agent's authority, and the principal has no signed record proving where that boundary was.

Unverifiable agreement. Two agents exchange messages and both sides' logs say a deal was reached, but the logs disagree, or one party's log was written after the fact. Without signatures over canonical bytes, an agreement is a claim about a conversation rather than an object either side can prove.

Uncontrolled disclosure. In any competitive process, the operator of the venue and each participant can learn things they should not: a rival's existence from a shared sequence number, a losing bid from an over-descriptive close reason, a budget from an agent that was permitted to negotiate but not to reveal it. These leaks are difficult to detect when nothing defines what a party was entitled to receive through the protocol interaction.

The common structure of all three failures is the absence of a shared, typed, signed record whose meaning both organisations agreed to in advance. That record is what a specification can provide, and what A202 specifies.

3. Design principles

Six principles govern the specification. They are stated normatively in the specification set; this section summarises them.

Fail closed. An unrecognised value, an unresolvable reference, an unreachable status endpoint, or an unregistered constraint type produces a refusal, never a permissive default. Unavailability is not permission.

Explicit typed state. Commercial meaning is carried by typed objects and named states, never by prose in a free-text field and never by the absence of an object. Only a signed, authorised event moves state. A message, a model output, an adapter callback, and a database write do not.

Assurance is reported, never inferred. An identity assurance level, a conformance grade, and a level of authority are each held because they were established and recorded, not because time passed or because previous transactions succeeded. Absence of an assessment reads as unassessed, never as a pass.

Disclosure minimalism. A party learns what it needs in order to act and to verify, and nothing more. Disclosure is a declared policy with a default of revealing nothing across counterparties, every disclosure is a recorded event, and a refusal must not itself become a disclosure. Structures are allowlists rather than denylists, because a denylist refuses only the leaks somebody anticipated.

Deterministic verification. Every claim the specification makes is checkable by replaying signed records and recomputing hashes, by an authorised party with no privileged access to any operator. Replay of the same valid inputs produces the same result. No model output serves as deterministic authority.

Carrier neutrality. The specification defines commercial meaning independently of any transport, agent framework, identity provider, payment rail, or enterprise system. The kernel contains no field that is meaningful in only one commercial domain, and that property is tested by a fixture rather than asserted.

4. Protocol overview

The specification set is organised in three layers.

Commercial objects. Delegated authority is carried by a standalone signed commercial mandate. Transaction objects carry commercial meaning on a common envelope: the terms of a deal as an offer and an agreement, what is owed as an obligation, what was proven as evidence, and what was decided as a determination. Enveloped objects declare their specification version, permanent identifier, type, version, predecessor, creation time, author, transaction, content hash, and signatures. Objects are never edited: a new version points at the one it replaces, and both remain verifiable. Objects canonicalise to exact bytes under RFC 8785 JSON canonicalisation, and every commitment is an ES256 signature over those bytes, checked against a declared purpose. Monetary amounts are base-10 strings with ISO 4217 currencies, never floating point.

Transaction state. Two state machines govern movement. A transaction aggregate carries the overall commercial request across all counterparties. In an operated negotiation, each bilateral conversation runs in its own negotiation session with its own event stream and sequence. Direct bilateral formation shares a session identifier but does not require a venue-ordered stream or ordering service. Operated streams are separated for confidentiality rather than tidiness: a single shared sequence counter across concurrent negotiations leaks rival activity through sequence numbers and timing, so no such counter exists. Guarded transitions define which signed events may move which states; replay rules define how a party reconstructs state from the available record; and rule versions are immutable, so a record made under an earlier rule set replays against the rules that were in force when it was appended.

Verification and conformance. Underneath both layers sits the machinery that makes claims checkable: canonicalisation, signing, a seven-step evidence verification procedure, and an executable conformance suite. Domain vocabulary enters through transaction profiles, which add fields, evidence requirements, and execution mappings under their own schemas without changing the kernel; the kernel's domain neutrality is enforced by a fixture that validates a second, structurally different profile against the unchanged kernel schema.

Settlement is deliberately out of scope. The specification defines a settlement instruction as an authorised object and an adapter receipt as evidence of an external system's response; moving money belongs to payment rails. A rail can report whether value moved. A202 lets a verifier check what the signed record says was owed under the protocol rules.

5. Commercial authority

Authority in A202 is a chain, and every link must verify. An organisation's principal issues a root commercial mandate; mandates may be delegated, and delegation only narrows. A child mandate cannot exceed its parent in scope, ceiling, validity, or permitted actions, and narrowing is checked structurally rather than assumed. A mandate carries a constraint vocabulary with typed operators; a constraint the evaluator cannot evaluate denies. Suspension and revocation reach relying parties through a status endpoint and a signed revocation record, and a chain with a missing, expired, suspended, revoked, or scope-incompatible link fails closed.

Two constructions distinguish this model from credential-based delegation alone.

Approval binding. Where an act requires a human decision, the approval is a signed object bound to the hash of one action in one transaction. Changing one byte of the action invalidates the approval, and an approval cannot be reused across actions or transactions. This keeps the human commitment visible and specific at exactly the moments where agent autonomy is least appropriate.

Custody without authority. An operator may custody keys for a party that was invited into a single transaction and has no infrastructure of its own. A custodied party's act nonetheless requires an approval bound to that party's principal, enforced whether or not the mandate restates the rule, and the operator never appears in the invited party's authority chain. Registration is not authority; an invitation grants participation in one named transaction, and authority is issued only by the invited party's own principal.

The mandate also governs disclosure. An agent may be permitted to negotiate a price and forbidden to reveal a budget; both the permission and the prohibition are checkable properties of the record rather than hopes about behaviour.

6. Negotiation state and disclosure control

The transaction aggregate and the per-counterparty sessions are governed by explicit transition tables. Three distinctions the specification enforces are easy to blur in informal systems and expensive to blur in commerce.

Acceptance is not selection. Choosing a counterparty's offer, in ranking or in an award, is not agreement.

Selection is not agreement. An agreement exists only when both parties have signed the same canonical content hash. One signature is a proposal; a hash mismatch is nothing.

A carrier acknowledgment is not anything. Delivery receipts, HTTP statuses, and adapter callbacks carry no commercial meaning. An accepted submission returns HTTP 202, and any status asserting an outcome is forbidden, because the outcome of a commercial act arrives only as a signed object.

For competitive processes, the specification defines experimental auction event semantics with a stated isolation property: a participant in a sealed-bid event should not be able to determine a rival's existence, activity, or terms from content, sequence numbers, reason codes, refusal shapes, or response timing. Event rules freeze when bidding opens; every bid is an ordinary offer under an ordinary mandate; exactly one award appends per award unit; and ranking may order offers but must not award. This work is scoped to synthetic, non-binding validation. The property is established for an implementation only through the required tests, and no independent implementation or external security review currently exists.

7. Evidence and verification

The record's value is that an authorised reviewer can verify disclosed claims later. The specification defines a seven-step verification procedure over an evidence bundle: resolving references by content hash, checking canonical bytes against recorded hashes, checking signatures against declared purposes and key status at signing time, replaying the event chain against the rules version in force, and checking version chains for forks and gaps. The verifier needs the disclosed bundle, referenced schemas and rule versions, and the declared keys. It does not establish the truth of external identity assertions or legal enforceability.

The verification output is deliberately three-valued per check: verified, failed, or not checkable, and there is no overall boolean. A gap in what could be checked is reported as scope rather than rounded up to a pass, and a verifier that could not check something states what it could not check. Selective disclosure is supported: a bundle may omit private material and must say so, and a report over a partial bundle is a report about the disclosed part.

Every step of the procedure runs with no privileged access to any operator. A verifier working with a partial bundle reports the scope it could and could not check. This is the specification's answer to the venue-trust problem: the record-level properties it states are designed to be checked rather than accepted on an operator's assertion.

8. Conformance as an executable artifact

A specification that cannot be tested divides implementations into those that claim conformance and those that do not, with no way to tell them apart. The A202 specification set therefore versions together with an executable conformance suite: 148 fixtures at v0.1, of which 32 are positive and 116 are negative, each classified by a manifest and checked by a normative runner. The weighting toward refusal is deliberate. Most of what the specification promises is that certain things cannot happen: an unauthorised act does not proceed, a leak-shaped event does not validate, a forged agreement does not verify. Each such promise is a negative fixture, and each negative fixture is minimal: removing the single offending element leaves a document that validates cleanly, so each fixture tests exactly one rule.

Schema validity is necessary and not sufficient. Cross-field and registry-dependent rules that JSON Schema cannot express, including interval ordering, profile resolution, delegation narrowing, and disclosure rules, are enforced by the runner, and the runner asserts not only that a negative fixture is refused but that it is refused for the reason code the manifest declares. The project requires each negative fixture to isolate one offence so that a fixture tests one rule rather than failing incidentally.

Conformance claims are scoped. Role scopes name the surface a claim covers: a bilateral scope two parties can adopt with no operator present, and an operated scope for venue functions. Grades are earned per dimension from assessment, never inferred, and the published fixture set is the floor rather than the claim: higher bands require held-out material, because an implementation can be written to any published test set, and a fixture that enters the published set never returns to a held-out one.

A reference implementation in Python accompanies the specification: canonicalisation, schema validation, object emission, signing, and the full verification procedure, with 34 tests that route the suite's evidence fixtures through the verification procedure independently of the runner. A reference MCP server exposes, as tools, the seven capabilities two organisations need in order to transact directly: issue a mandate, check what an agent may do under it, approve an act that needs a person, form an agreement, exchange obligations, verify a record, and read the transaction record back.

9. Threat model

The specification is developed against a stated threat model, published with the specification set. Eight adversaries are assumed, each presumed to have read every published document: the strategic counterparty that analyses everything it is sent and everything it is refused; the forging counterparty that signs arbitrary objects with keys it legitimately holds; the over-reached agent acting beyond its principal's intent; the hostile evidence author crafting free text to influence a human approver or a downstream agent; the venue operator that sees every object and custodies keys; the malicious implementer that passes the published suite and behaves differently off it; the supply-chain adversary that tampers with schemas or fixtures in transit; and the network observer.

The operator's presence in this list is the design's centre of gravity. Defended record-level properties are defined over what a participant can observe and replay, so the protocol is designed to make violations of those stated properties observable and testable at participant boundaries without disclosing the operator's internals.

Equally deliberate is the list of what is not defended, stated so that a reader finds a boundary rather than discovering a gap: collusion agreed outside the system, traffic analysis on the carrier, key compromise beyond its recorded consequences, the truth of external identity assertions, settlement execution, and legal enforceability in any particular jurisdiction. The record is designed to be reconstructable and attributable; whether a court enforces what it records is a question for counsel, not for a schema.

10. Carriers and composition

A202 composes with the existing agent stack rather than competing with it.

Over A2A. A published carrier binding states how A202 objects travel between agents over the Agent2Agent protocol: objects ride as parts of A2A messages, unchanged; the carrier envelope carries delivery metadata and commercial meaning stays inside the signed objects; support is declared through an A2A extension declaration; and every failure mode of the capability check produces one refusal code, so a counterparty that cannot verify never half-participates.

Over MCP. The reference MCP server gives a model runtime structured access to A202 capabilities as tools, with the specification's rules enforced at the tool boundary: an act outside the mandate's constraints is refused, and verification replays the signed record rather than trusting the caller's summary.

Over plain HTTPS. A minimal binding defines a capability check, a request, and a refusal for a party that runs no agent stack at all, because the counterparty that most needs verifiable commerce may be the one with the least infrastructure.

Payment protocols sit on the far side of the settlement handoff. The handoff is one rail-agnostic instruction, one trigger rule, one receipt, and one idempotency rule, and informative annexes map it onto AP2 and other rails. The layers are complementary by construction: payment protocols authorize or execute payment, depending on the protocol; A202 verifies what the disclosed signed record says about the underlying agreement and authority under its own rules.

11. Related work

Agent communication. MCP standardises model-to-tool access [1]; A2A standardises agent-to-agent discovery and task exchange, and is now developed under the Linux Foundation [2]. Both are carriers from A202's perspective: they move messages between parties, and A202 defines the commercial objects those messages may carry. The A2A carrier binding makes this composition concrete.

Agent payments. AP2 introduces cryptographically signed intent and cart mandates, carried as verifiable credentials, creating a non-repudiable audit trail from user intent to payment [3]. The Agentic Commerce Protocol, maintained by OpenAI and Stripe, standardises the agent-to-merchant checkout flow [4]. x402 revives HTTP 402 for machine-native payments [5]. These protocols answer payment authorisation and execution, largely in the consumer purchase setting where a merchant's catalogue fixes the terms. A202 addresses the stage before and after payment in the organisation-to-organisation setting: negotiated terms, delegated authority with ceilings and scopes, obligations that outlive the payment, and dispute-grade evidence. The settlement handoff maps onto these rails rather than replacing them.

Commerce surfaces. The Universal Commerce Protocol connects agents to merchant systems across discovery, purchase, and post-sale support [6]. Its scope is the shopping lifecycle on merchant infrastructure; A202's scope is the commitment layer between independent organisations, including settings with no merchant catalogue at all, such as solicited bids and negotiated service agreements.

Legal context. The Legal Context Protocol, launched by the American Arbitration Association and industry partners, attaches legal terms, jurisdiction, and recourse paths to agent transactions [7]. LCP and A202 approach the same institutional gap from different directions: LCP supplies a legal frame an agreement may carry; A202 supplies a cryptographic record of what the parties signed and under what recorded authority. The two could complement each other, but no published binding currently establishes interoperability. A determination in A202 is an appealable, signed object intended to work alongside external dispute institutions rather than replace them.

Older lineages. Inter-organisational document standards, from EDI through ebXML and UBL, standardised orders, invoices, and other trade documents across the commercial lifecycle. Ricardian contracts bound legal prose to cryptographic hashes. Smart contract platforms made some agreements executable on shared ledgers. A202 draws on these lineages while requiring no shared ledger, token, custody arrangement, or common platform.

12. Status and limitations

A202 is a pre-release working specification at v0.1. No release has been tagged, and pre-1.0 versions may make breaking changes with migration notes. The specification, schemas, fixtures, runner, and reference implementations are published under the Apache License 2.0, with an express patent grant. As of 8 August 2026, seventeen numbered public proposals record why the specification says what it says.

Its limitations are stated in its own documents and repeated here. No external security review has taken place. No independent implementation exists yet, and the conformance suite tests the specification's own reading of itself: the reference implementation and the runner were built against the same documents by the same project, so their agreement is a consistency check rather than independent confirmation. Turn-taking discipline, impasse rules, and several payload definitions are recorded as deferred. The governance is single-maintainer and says so, with stated conditions under which it is reviewed and expanded.

External review is the purpose of publishing at this stage. The specification's security posture, its isolation property, its verification procedure, and its conformance methodology are all stated as checkable claims, and readers who find a way through any of them are asked to report it through the coordinated disclosure process the repository defines.

13. Conclusion

The agent ecosystem has standardised conversation and payment. Commitment, the layer where organisations bind themselves to each other, has remained informal exactly where informality is most expensive. A202 makes that layer explicit: authority as a checkable chain, agreement as dual signatures over canonical bytes, disclosure as declared policy, and the entire record as something any authorised party can verify with no privileged access to anyone's infrastructure. It composes with the protocols agents already use, refuses the categories that belong to rails, venues, and courts, and ships with the executable means of holding any implementation, including its own, to what it says.

The specification set, conformance suite, reference implementations, and proposal record are at https://github.com/a202-protocol/a202. Documentation is at https://a202.org, and the schemas resolve at https://schemas.a202.org.

References

[1] Anthropic. Model Context Protocol. https://modelcontextprotocol.io, 2024.

[2] Google and the Linux Foundation. Agent2Agent (A2A) Protocol. https://a2a-protocol.org, 2025.

[3] Google. Agent Payments Protocol (AP2). https://github.com/google-agentic-commerce/AP2, 2025.

[4] OpenAI and Stripe. Agentic Commerce Protocol. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol, 2025.

[5] Coinbase. x402: An open standard for internet-native payments. https://www.x402.org, 2025.

[6] Google. Universal Commerce Protocol. https://ucp.dev/, 2026.

[7] American Arbitration Association. Legal Context Protocol. https://www.adr.org/news-and-insights/introducing-the-legal-context-protocol/, 2026.

[9] A202 specification set, v0.1 working documents. https://github.com/a202-protocol/a202, 2026.