|
| 1 | +--- |
| 2 | +id: accordproject-agentic-commerce |
| 3 | +title: Agentic Commerce |
| 4 | +--- |
| 5 | + |
| 6 | +## The enforceable-terms layer for autonomous commerce |
| 7 | + |
| 8 | +As AI agents begin to transact on people's behalf, the ecosystem is converging on a layered architecture. Each layer solves a distinct problem, and no single layer solves them all: |
| 9 | + |
| 10 | +- **Identity & trust** — who is this agent, and is it legitimate? |
| 11 | +- **Authorization proof** — what did the user authorize the agent to do, and can we prove the agent stayed within those bounds? *(Verifiable Intent, AP2 credentials.)* |
| 12 | +- **Payment & checkout transport** — how does the agent create a checkout session and move payment credentials? *(UCP, ACP, Mastercard Agent Pay.)* |
| 13 | +- **The agreement** — what are the enforceable terms of the deal, and how do the obligations execute over its lifetime? *(Accord Project.)* |
| 14 | + |
| 15 | +Accord Project is the **agreement** layer. The others authorize and route a transaction; Accord Project defines the contract that transaction rests on — its terms, its computable obligations, and its remedies — in a form that is both machine-executable and legally interpretable. |
| 16 | + |
| 17 | +> **Verifiable Intent proves what an agent was *authorized* to do. Accord Project defines and executes the *agreement* it was authorized to enter.** |
| 18 | +
|
| 19 | +``` |
| 20 | +┌───────────────────────────────────────────────────────────────┐ |
| 21 | +│ IDENTITY & TRUST who is the agent? │ |
| 22 | +├───────────────────────────────────────────────────────────────┤ |
| 23 | +│ AUTHORIZATION PROOF what was authorized? did the agent │ |
| 24 | +│ Verifiable Intent, AP2 stay in bounds? (cryptographic proof)│ |
| 25 | +├───────────────────────────────────────────────────────────────┤ |
| 26 | +│ PAYMENT & CHECKOUT how is the transaction routed and │ |
| 27 | +│ UCP, ACP, Agent Pay settled? │ |
| 28 | +├───────────────────────────────────────────────────────────────┤ |
| 29 | +│ THE AGREEMENT what are the enforceable terms, and │ |
| 30 | +│ ▶ Accord Project how do obligations run over time? │ |
| 31 | +└───────────────────────────────────────────────────────────────┘ |
| 32 | +``` |
| 33 | + |
| 34 | +## What each layer does — and does not do |
| 35 | + |
| 36 | +Authorization protocols such as [Verifiable Intent](https://verifiableintent.dev/) (VI) are, by their own definition, a portable and independently verifiable record of *what a user authorized an agent to do* and proof that the agent stayed within those bounds. That is a different concern from the agreement itself. Reading the VI specification, its expressive vocabulary for "intent" is a set of transaction-scoped **constraints** — allowed merchants, allowed payees, an amount range, permitted line items, a spending budget, and recurrence limits. This is exactly what an authorization envelope needs, and deliberately no more. |
| 37 | + |
| 38 | +The substance of the deal lives outside that envelope — and inside an Accord Project contract: |
| 39 | + |
| 40 | +| Concern | Authorization layer (e.g. Verifiable Intent) | Accord Project | |
| 41 | +|---|---|---| |
| 42 | +| Proof an agent was authorized | ✅ Cryptographic delegation chain | — | |
| 43 | +| Key binding, selective disclosure | ✅ SD-JWT credential format | — | |
| 44 | +| Transaction-scoped spend/merchant limits | ✅ Signed constraints | Can model the same constraints as typed data | |
| 45 | +| Substantive terms (warranty, returns, SLA, delivery, liability, data use) | Treated as informational, not enforced | ✅ Typed model + court-readable text | |
| 46 | +| Obligations that run **after** settlement | Out of scope (flow ends at settlement) | ✅ Executable logic over the contract lifecycle | |
| 47 | +| Remedies and outcomes on breach | Audit *trail* only | ✅ Computable logic that determines the *outcome* | |
| 48 | +| Bilateral, negotiated agreement | Unilateral user→agent delegation | ✅ An agreement between parties | |
| 49 | + |
| 50 | +The clean division of labour: authorization proves the agent stayed in bounds; Accord Project defines what the deal *is* and enforces it over time. |
| 51 | + |
| 52 | +## How Accord Project plugs in |
| 53 | + |
| 54 | +Authorization frameworks are designed to be extensible, and they leave open exactly the slot Accord Project fills. AP2, for example, defines a Verifiable Digital Credential (VDC) trust mechanism but leaves the credential format open — which is the slot Verifiable Intent fills. The *enforceable-terms* slot is open in the same way. Three concrete integration patterns: |
| 55 | + |
| 56 | +### 1. A contract as the terms a mandate binds to |
| 57 | + |
| 58 | +Authorization credentials already bind to a checkout artifact by hash (for example, VI binds a `checkout_jwt` via a SHA-256 `checkout_hash`). An Accord Project contract — or its rendered [AgreementMark](markup-templatemark.md) form — can be bound the same way: the credential references the contract by hash, so the user is provably authorizing acceptance of **specific enforceable terms**, not just a list of line items and a merchant name. This gives the "what-you-see-is-what-you-sign" consent surface real legal substance, using the court-readable TemplateMark text as the human-facing artifact. |
| 59 | + |
| 60 | +### 2. Concerto as the schema language for the constraint registry |
| 61 | + |
| 62 | +Authorization constraints are, structurally, a typed-schema problem: dot-notation type discriminators, a versioned registry, namespaced extensibility, and validators that must run in every language a merchant, PSP, or payment network uses. [Concerto](https://concerto.accordproject.org/docs/intro) is built for exactly this. A constraint registry modelled in Concerto generates, from a single source of truth: |
| 63 | + |
| 64 | +| Target | Use case | |
| 65 | +|---|---| |
| 66 | +| **JSON Schema** | Validating credentials and constraint payloads | |
| 67 | +| **TypeScript** | Agent and verifier logic, frontend type safety | |
| 68 | +| **Java** | Enterprise backend / processor integration | |
| 69 | +| **Go** | High-performance network services | |
| 70 | +| **C#** | .NET integrations | |
| 71 | + |
| 72 | +Instead of hand-writing and re-validating constraint types per runtime, the polyglot verifiers a trust framework requires are generated and kept in lockstep. |
| 73 | + |
| 74 | +### 3. Contract logic for the terms authorization can't enforce |
| 75 | + |
| 76 | +Authorization layers explicitly treat descriptive fields (product description, brand, colour, size) and post-settlement behaviour as informational — not subject to automated verification. Accord Project [TypeScript logic](logic-typescript.md) can make many of these enforceable: delivery-date-within-window, total-including-tax-under-budget, warranty conditions, refund and return eligibility, milestone and SLA obligations. The compiler acts as a verification step between agent output and execution, so errors in agent-generated terms surface as compile failures rather than silent runtime bugs in a live contract. |
| 77 | + |
| 78 | +## Immediate vs. autonomous transactions |
| 79 | + |
| 80 | +Authorization frameworks distinguish **human-in-the-loop** transactions (the user confirms the final purchase) from **autonomous** ones (the user sets constraints and the agent acts independently). Accord Project is valuable in both: |
| 81 | + |
| 82 | +- **Human-in-the-loop** — the contract is the terms the user reviews and confirms; its logic computes the figures (totals, schedules, fees) shown at the point of consent. |
| 83 | +- **Autonomous** — the contract's typed model can express the same constraints the agent must honour, its logic can enforce the terms the authorization layer treats as informational, and its lifecycle obligations continue to execute long after the agent's authority to *initiate* the transaction has expired. |
| 84 | + |
| 85 | +## Relationship to agentic commerce protocols |
| 86 | + |
| 87 | +Accord Project is transport- and protocol-agnostic and complements, rather than competes with, the emerging protocol stack: |
| 88 | + |
| 89 | +- **[AP2](https://github.com/google-agentic-commerce/AP2)** (Agent Payments Protocol) — defines an abstract credential/mandate framework and leaves the credential format open. Accord Project supplies enforceable terms that a mandate can reference. |
| 90 | +- **[UCP](https://github.com/Universal-Commerce-Protocol/ucp)** (Universal Commerce Protocol) — a concrete checkout protocol aligned with AP2, with extension fields for mandate data. A contract reference can ride those fields without changes to core endpoints. |
| 91 | +- **[ACP](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)** (Agentic Commerce Protocol) — a REST checkout and payment-delegation protocol whose extension mechanism can carry a contract reference alongside standard checkout mechanics. |
| 92 | + |
| 93 | +## What Accord Project does not do |
| 94 | + |
| 95 | +To keep the boundary clear: Accord Project is **not** an identity, authorization, or payment layer. It does not issue credentials, perform key binding, or implement selective disclosure — those are the province of Verifiable Intent, AP2, and the payment networks. Accord Project provides the enforceable agreement those layers authorize and settle. |
| 96 | + |
| 97 | +## Status of these integration patterns |
| 98 | + |
| 99 | +The integration patterns above are illustrative of how Accord Project's format aligns with the agentic commerce stack; they describe technical fit, not partnerships or endorsements. Concrete adoption architecture for any specific protocol or trust framework should be developed in coordination with that project's maintainers. If you are working on agentic commerce and want to explore these patterns, [join the community](https://discord.com/invite/Zm99SKhhtA). |
| 100 | + |
| 101 | +## Further reading |
| 102 | + |
| 103 | +- [Overview](accordproject.md) — what Accord Project is |
| 104 | +- [AI & Agent Workflows](accordproject-ai.md) — computable contracts as agent infrastructure |
| 105 | +- [Smart Legal Contracts](accordproject-slc.md) — how machine-readable and machine-executable contracts work |
| 106 | +- [Concerto Documentation](https://concerto.accordproject.org/docs/intro) — the schema DSL and its code generators |
| 107 | +- [Template Logic in TypeScript](logic-typescript.md) — writing strongly-typed contract logic |
| 108 | +- [APAP Reference](ref-apap.md) — the agreement protocol API, including the MCP endpoint |
| 109 | +- [2024 Whitepaper: *An Introduction to Computable Contracts*](https://accordproject.org/whitepaper-2024/) |
0 commit comments