v0.1 working documents
A202¶
The Verifiable Agreement Protocol for Agent-Led Commerce
An open, carrier-neutral specification of commercial authority, negotiation state, and verifiable conformance for transactions between independent organisations, including transactions conducted on their behalf by software agents.
Five questions every transaction must answer¶
Two organisations that have never transacted before need a shared answer to a small number of questions. Existing agent, payment, and identity specifications answer parts of the first and none of the rest. A202 specifies the missing layer.
-
Authority
Who is this counterparty, and who inside it authorised this act? What exactly was that party permitted to commit to, and was the act inside that permission?
-
State
What state is this transaction in, and what changed it? Only a signed, authorised event moves state. A message, a model output, and a database write do not.
-
Disclosure
What did the other side learn, and what did it not? Disclosure is a declared policy with a default of revealing nothing across counterparties, and every disclosure is a recorded event.
-
Record
If this is disputed a year from now, what can be reconstructed, by whom, from what? Every claim is checkable by replaying signed records, with no privileged access to anyone's infrastructure.
Three layers¶
The specification set is organised in three layers that work together, and each layer is checkable on its own.
flowchart TB
subgraph objects ["Commercial objects"]
direction LR
M[Mandate] ~~~ O[Offer] ~~~ AG[Agreement] ~~~ OB[Obligation] ~~~ EV[Evidence] ~~~ D[Determination]
end
subgraph state ["Transaction state"]
direction LR
TA[Transaction aggregate] ~~~ NS[Negotiation sessions] ~~~ SE[Signed events] ~~~ DR[Disclosure rules]
end
subgraph verify ["Verification and conformance"]
direction LR
CB[Canonical bytes] ~~~ SG[Signatures] ~~~ RP[Replay] ~~~ CS[Conformance suite]
end
objects --> state --> verifyTyped objects carry commercial meaning: who may act, what was offered, what was agreed, what is owed, what was proven, what was decided. Two state machines govern how those objects move a transaction, one for the aggregate and one for each bilateral session inside it. Underneath both, every object canonicalises to exact bytes, every commitment is a signature over those bytes, and an executable suite of 148 fixtures decides whether an implementation agrees with the specification.
Meaning, not transport¶
A202 is carrier-neutral by construction: it defines what objects mean, not how they travel. Objects defined here may be carried, wrapped, or referenced by another protocol without changing what they mean.
- A2A carrier binding: how A202 objects travel between agents over the Agent2Agent protocol, with a declared extension and closed failure modes.
- A202 MCP server: a reference server giving an agent, over the Model Context Protocol, the seven capabilities two organisations need in order to buy and sell from each other directly.
How A202 composes with A2A and MCP
Where to go next¶
-
Specification
The canonical commercial model, the object families, and the state machines, each marking its own normative sections.
-
Conformance
An executable fixture set and a normative runner. Schema validity is necessary and not sufficient, and grades are earned per role scope.
-
Proposals
Every normative change lands under a numbered proposal, so the record of why the specification says what it says is public.
-
Governance
How the project is run, what the sponsor does and does not control, and when the governance is reviewed.
Status: pre-release. No release has been made. The contents are v0.1
working documents under the release policy in RELEASES.md,
and the specification is licensed under the
Apache License, Version 2.0.