Independent structured records passing through aligned protocol planes.

A202 / v0.1

When an agent says yes, prove what it means.

Verifiable Agreement Protocol for Agent-Led Commerce

A202 gives independent organizations one checkable language for authority, offers, approvals, disclosure, commitment, and the evidence left behind.

The common ground

A deal is more than a message. It is a chain of authority, state, and acceptance.

Messages move quickly. Commercial meaning does not. A202 makes the facts both organizations must agree on explicit, signed, and independently checkable.

Spoken “A two-oh-two.” The number refers to HTTP 202 Accepted, because acceptance is the primitive the specification builds on.

01

Signed actions

Offers, approvals, awards, revocations, and commitments identify their author, context, creation time, content hash, and signatures.

02

Versioned state

A new object points to the one it replaces. The current state stays explicit while every earlier version remains verifiable.

03

Portable evidence

Either organization can replay the signed sequence without depending on the other party's internal system or the original interface.

One agreement, end to end

01 / Propose

An agent proposes an agreement.

A buyer agent sends a commercial action. The message alone is not enough. The counterparty needs to know who authorized it, what it may bind, and which terms it contains.

offer
obj_19c2
shared recordproposed
BuyerNordica Foods
ValueEUR 184,000
Termssha-256: 8f2c…9a1d
A proposal exists. No obligation exists yet.

02 / Verify

Authority travels with the action.

A202 verifies the chain from the organization to the agent, including scope, financial limits, validity, and revocation. Missing authority stops the action before shared state changes.

authority check
mnd_08a4
shared recordverified
Principalorg_nordica
Actionoffer.submit
Limit≤ EUR 250,000
The proposed action is inside the mandate.

03 / Version

Every change creates a new object.

The current offer is explicit. A revision points to the version it replaces, while both remain available for verification. No email thread or application screen decides which terms are current.

offer revision
obj_19c2:v3
shared recordcurrent
Version3
Supersedesobj_19c2:v2
Content hashsha-256: 31b7…0e4c
Version 3 is current. Versions 1 and 2 remain provable.

04 / Accept

Both sides accept the same terms.

A commitment forms only when the required approvals and signatures point to the same final object. A unilateral claim, a stale signature, or mismatched terms cannot silently become an agreement.

agreement
agr_7dd1
shared recordaccepted
Terms hashsha-256: 31b7…0e4c
Buyer signaturevalid
Supplier signaturevalid
Two signatures. One version. One shared commitment.

05 / Preserve

The evidence outlives the interface.

The signed sequence can be replayed by either organization or a later reviewer. Verification depends on the record and the specification version, not on hidden service state or access to the original application.

evidence bundle
evd_c032
shared recordreplayable
Objects12
Chain continuityverified
Specificationa202-commercial/0.1
The commercial history can be reconstructed independently.

Try the authority gate

A signature proves who signed. A202 proves whether they could.

Switch the mandate status. The signed offer stays identical. Only the authority changes, and that is enough to change the outcome.

Authority chain

1Organization
2Mandate
3Agent key
4Signed offer

Action

offer.submit

Amount

EUR 184,000

Limit

EUR 250,000

accepted

The action enters shared state.

The mandate is active, the proposed action is in scope, and EUR 184,000 is below the EUR 250,000 limit.

HTTP 202 / ACCEPTED SUBMISSION

Rules every compatible implementation must preserve.

These principles define how a governed commercial exchange should behave across different implementations. They keep authority, disclosure, state, and verification consistent even when the organizations use different technology.

Fail closed

If authority is missing, expired, revoked, or ambiguous, the proposed action is rejected before it changes the shared commercial state. The system does not treat incomplete evidence as permission.

Explicit typed state

Offers, approvals, awards, revocations, and commitments are represented as signed, versioned objects. The current commercial state is derived from those objects rather than inferred from messages or application screens.

Assurance is reported, never inferred

An assessment result states what was tested, against which version, and with what outcome. If a control was not assessed, the record says unassessed rather than allowing a reader to interpret silence as a pass.

Disclosure minimalism

A participant receives only the fields and events explicitly allowed for its role and the current commercial state. This avoids relying on a denylist that can block only the disclosures someone anticipated in advance.

Deterministic verification

The verification rules operate on the signed record, not on hidden service state. Two reviewers using the same specification version and the same record should reach the same result.

Carrier neutrality

The commercial meaning of an A202 object does not depend on the messaging network, agent framework, cloud provider, or payment rail used to carry out the work.

What A202 refuses to do.

A202 is limited to the shared commercial record between independent organizations. It deliberately leaves discovery, strategy, settlement, reputation, and custody to the systems already responsible for them.

No marketplace or matching.

A202 does not discover suppliers, rank counterparties, or decide who should trade. Another system can perform discovery. A202 begins when an identified party is invited into a named event.

No settlement execution.

A202 records the commercial obligation and the evidence supporting it. A bank, payment provider, or other settlement rail remains responsible for moving value and reporting whether settlement completed.

No reputation scores.

The specification does not convert commercial history into a counterparty score, rating, or recommendation. Each organization remains responsible for its own supplier qualification and risk decisions.

No token.

A202 does not define a token, settlement asset, wallet, or custody model. Commercial amounts can refer to existing currencies, while value moves through the payment rails selected by the organizations.

No commercial strategy.

An agent, buyer, supplier, or separate optimization system decides how to pursue terms. A202 defines the authority, state, disclosure, and commitment rules that determine what the resulting offers can bind.

Open specification

One specification. No required platform.

A202 specifies meaning, not transport. Its objects can move over A2A, plain HTTPS, or another carrier without changing what authority, acceptance, or evidence means.

Plural Worlds initiated and sponsors A202 and holds the mark. A. A. Musse created and maintains the specification. Its governance is designed to support independent stewardship as participation grows.

versiona202-commercial/0.1
sponsorPlural Worlds
maintainerA. A. Musse