Introducing A202: verifiable agreements for agent-led commerce

Software agents can discover services, exchange messages, and initiate payments. A202 addresses a different question: how can two independent organizations verify who authorized a commercial commitment, what was agreed, and what record remains if the outcome is disputed?

We are publishing A202 v0.1 as a pre-release working specification for verifiable agreements in agent-led commerce. Plural Worlds created the protocol and released its specification, schemas, conformance fixtures, runner, reference implementation, and threat model for public review.

Why agents need an agreement layer

When software acts inside one company, internal policy and access controls can decide what it may do. The harder case begins when an agent acting for one organization meets an agent acting for another. Neither side should need access to the other's internal systems. Both still need reliable answers to four commercial questions:

• Authority: who permitted this agent to act, and what limits apply?
• State: which offer is current, and which signed event changed the transaction?
• Disclosure: what was this counterparty permitted to receive through the protocol interaction?
• Record: what can an authorized reviewer verify later from the disclosed evidence?

A message is not a state change, and a model output is not an agreement. A202 turns these commercial facts into typed, signed objects with explicit rules for how state moves.

What A202 is

A202, the Verifiable Agreement Protocol for Agent-Led Commerce, is an open and carrier-neutral specification. It defines commercial meaning rather than transport. An A202 object can travel over A2A, appear as a tool result through MCP, or move over ordinary HTTPS without changing what its authority, state, or signatures mean.

The name refers to HTTP 202 Accepted. The association is limited and intentional: a carrier may acknowledge that it accepted a submission for processing, but that acknowledgment never means a commercial offer was accepted. Commercial acceptance is a signed A202 object.

How A202 works

A202 separates probabilistic agent reasoning from deterministic commercial controls. An agent may search, compare, and negotiate. Authority checks, state transitions, signatures, and verification follow explicit rules.

A concrete example

Consider a food manufacturer buying an annual calibration service. A procurement manager gives an agent a mandate: request offers from approved suppliers, negotiate within a defined scope, and commit up to EUR 50,000 before a stated expiry time.

The buyer agent sends a signed offer. A supplier proposes different service dates and issues a new version that points to the offer it replaces. The buyer agent can accept only if the revised terms still fall inside its mandate. If the action requires human approval, that approval is signed and bound to this exact action in this exact transaction.

An agreement forms only when both organizations sign the same canonical content hash. If the parties disagree later, an authorized reviewer can inspect the disclosed evidence, resolve the referenced versions, verify signatures and key status, and replay the relevant state transitions. The result is not a blanket claim that everything is valid. Each check is reported as verified, failed, or not checkable.

How A202 fits with other agent protocols

A202 is designed to compose with the agent stack rather than replace it. Different layers answer different questions.

A202 carries the commercial record up to a settlement handoff. It can record an authorized settlement instruction and the receipt returned by an external adapter, but it does not move money. A payment system can report whether value moved. A202 lets a verifier check what the signed record says was owed.

Design principles

• Fail closed. Missing authority, an unknown rule, or an unresolvable reference produces a refusal. Unavailability is not permission.
• Use explicit typed state. Commercial meaning lives in named objects and states, not free text or a model's interpretation of a conversation.
• Minimize disclosure. Cross-counterparty data is allowed deliberately, with recorded policies and events. A202 does not claim to prevent learning through side channels outside the protocol.
• Make verification deterministic. Given the same disclosed records, schemas, rules, and keys, a verifier should reach the same scoped result.
• Stay carrier neutral. The commercial kernel does not depend on one transport, model provider, identity system, payment rail, or commercial domain.

Conformance and security

A202 ships with an executable conformance suite because a protocol claim is useful only when an implementation can be tested against it. As of 8 August 2026, the suite contains 148 fixtures: 32 valid examples and 116 negative cases that implementations must refuse. The weighting is deliberate. Many of the protocol's important promises concern what must not happen, such as accepting an unauthorized act, validating mismatched agreement terms, or exposing data through a refusal.

The public threat model assumes strategic counterparties, overreaching agents, hostile evidence, compromised operators, malicious implementers, supply-chain tampering, and network observers. It also states its limits. A202 does not establish the truth of an external identity assertion, prevent collusion outside the system, execute settlement, or determine legal enforceability.

What A202 does not do

A202 is not a marketplace, ranking system, negotiation strategy, payment rail, token, or court. It does not require parties to share a platform, ledger, model provider, or operator. It specifies a portable commercial record and the rules for checking it.

Current status

A202 v0.1 is public and pre-release. No version has been tagged. There is no independent implementation or external security review, and several areas remain deferred. The governance is currently single-maintainer. These are material limitations, not footnotes.

Publishing now makes the design reviewable while changes are still inexpensive. The project welcomes concrete criticism of the authority model, state machines, disclosure rules, verification procedure, threat model, and conformance methodology.

Explore and contribute

• Read the A202 documentation.
• Inspect the specification, schemas, fixtures, and reference code.
• Read the full A202 technical paper.
• Contact Plural Worlds to discuss implementation, review, or collaboration.

Frequently asked questions