Agentic commerce needs a failure path

Disclosure: I co-founded People’s Court, which works on dispute resolution and interoperability tooling for agentic commerce. People’s Court is a founding member of the A-Comm Evidence Protocol consortium.

Agentic commerce is getting very good at the happy path. An agent can discover a service, obtain authorization, make a payment, and receive a result without a human touching the transaction. On October 6, AAIF published There Is No One Agentic Commerce Protocol, which put that progress in the right frame: UCP, AP2, x402, and A2A each play different roles in commerce, from discovery and authorization to payment and coordination. Commerce is a relay race. Those separate responsibilities make the interfaces between protocols especially important.

But there’s a missing piece. What happens when a transaction goes through perfectly, but the buyer and seller disagree about whether the seller delivered what was promised? Existing protocols can facilitate the transaction, but they don’t yet provide a common way to carry that disagreement across systems — from the initial complaint and supporting evidence to a decision and its execution.

Payment finality is not commercial finality

Imagine a buyer agent pays $20 for “last week’s shipping prices.” The payment clears. The file arrives a minute later. The buyer’s agent then objects because the timestamps run back three weeks. The seller’s agent answers that the timestamps mark when each shipment was priced, not when the file was compiled, and the file was compiled yesterday.

Nobody is lying. Every record is authentic. From the payment layer’s perspective, everything worked. From the commercial perspective, there is a dispute.

Traditional commerce already knows this distinction. Returns, chargebacks, escrow, mediation, and arbitration exist because a payment system can answer whether value moved without answering whether the recipient was entitled to keep it. Agentic commerce makes the gap sharper. Disputes may become more frequent at machine scale, often too small for weeks of lawyer time, and often too fast for a support ticket invented after the fact.

Agentic commerce therefore needs a machine-readable failure path — not as an afterthought humans invent when something breaks, but as part of the transaction architecture.

Standardize the handoff

A dispute interface can take many forms. A marketplace may use an internal review. Two businesses may mediate. Another transaction may use arbitration, human or AI-assisted. A decentralized system may prefer something else. Those choices should stay open.

The interoperability problem comes one layer earlier. Whatever resolves the dispute needs a coherent way to receive it. The resolver needs to know which transaction is challenged, who may open it, which terms governed, what evidence belongs to the record, what remedy is requested, how the other side answers, which system may decide, and what happens after it does.

These are not merely legal questions. They are interoperability questions.

Existing protocols already produce useful inputs. An optional x402 extension supports signed offers and receipts. AP2 mandates record what a user authorized and can serve as dispute evidence, while leaving resolution itself out of scope. A2A moves tasks and artifacts between agents. A draft A-Comm Evidence Protocol (AEP) proposes wrapping records like these into a tamper-evident chain and exporting a dispute-grade bundle. AEP is a witness, not a judge: it records what happened and assigns no outcome.

None of those artifacts answers the freshness dispute by itself. A receipt shows money moved. A mandate shows what was authorized. A delivered file shows what was sent. The handoff has to carry the disagreement — not just the transaction with the disagreement removed.

A worked example

Take the same $20 purchase as a developer-facing walkthrough.

1. Before payment, the seller advertises a recourse profile the buyer can discover: filing window, evidence expectations, available remedies (refund, partial refund, reperformance, release), and which mechanisms are in scope — for example, merchant review, mediation, or arbitration. The profile names a resolver reference. It does not, by itself, create an enforceable arbitration agreement or prove that the agent had authority to accept one. Protocol design and legal consent are different jobs. A machine-readable pointer is not a signed submission agreement.
2. After delivery, the buyer agent files a claim: the dataset fails the freshness term as it stood at purchase. The claim points at the order, the term version, the delivered file, the payment artifacts, and a short statement of the timestamp dispute. The seller answers with its reading of the timestamps. A missing compile log is listed as missing, not silently omitted. The point is that an unfamiliar resolver should be able to receive this package, understand what each side is arguing, and identify the relevant evidence without having participated in the original transaction.
3. The evidence package that travels is more than a dump of logs. Each artifact carries who submitted it, which transaction it concerns, what it is offered to prove, integrity information, and whether the other side can see it. That matters because dispute infrastructure cannot assume cooperation. A participant may omit a damaging record. Two systems may present inconsistent logs. A party may contest the meaning of a timestamp. Interoperability usually assumes cooperation. Recourse has to remain reliable when participants disagree.
4. A verifier can check that bytes match a digest and that a signature verifies under a key. That is not the same as proving the signer was authorized, the record is complete, or the seller performed. Cryptographic verification is not commercial truth.
5. The outcome comes back as a machine-readable result, not only a PDF someone has to notice. It names the record version considered, who decided, the disposition (for example a partial refund), whether the result is final under the procedure, and which system is authorized to execute. Decision and execution stay separate. If funds sat in escrow, an escrow provider may release or return them. If payment already settled on a final rail, someone may need to send a new payment. Calling the decision a “refund” reverses nothing by vocabulary alone. The system also needs to track whether the remedy was actually carried out, rather than assuming that issuing a decision means the dispute is resolved.
6. Timeouts and retries are part of the interface. If the executor may have acted before a connection dropped, a blind retry can pay twice. The integration needs reconciliation, and an unresolved execution has to stay visible.

What the community could map and test first

AAIF’s Agentic Commerce Working Group already covers post-purchase interfaces and dispute initiation while leaving each domain system’s internals to its owners. Building on existing capability-map contributions, one useful area for exploration would be to compare how existing protocols handle a contested post-purchase transaction: what information they preserve, how disputes and supporting evidence can move between systems, and how resolution outcomes reach the systems responsible for carrying them out. The goal would not be to propose a new specification or a universal machine judge, but to identify where existing capabilities interoperate, where they do not, and what gaps remain.

A shared synthetic test case could make that exercise concrete. Using the freshness dispute above, the community could compare how x402, AP2, A2A, AEP, and neighboring work represent the same transaction and its subsequent disagreement, without requiring any agreement on the merits or on a common resolution mechanism. Here are some potential questions to answer:

1. Can an unfamiliar resolver match every artifact to the right transaction and say what each side disputes?
2. Does missing material produce an explicit incomplete-record state?
3. Can the system represent failed notice and a late evidence supplement?
4. Does a corrected decision stop a stale execution instruction?
5. Does a duplicate callback produce one remedy, or two?

If the answer to any of those questions is no, the gap is not merely legal. It is an interoperability defect.

Recourse as infrastructure

Open agent ecosystems will not stay inside one company’s support queue. Counterparties will be unfamiliar. Mandates will be delegated. Values will often be too small for ordinary legal escalation and too fast for improvised process. Under those conditions, credible recourse is part of trust.

Don’t standardize the merits. Standardize the handoff. Make disagreement discoverable before the transaction, portable when it happens, answerable by the other side, and executable afterward — across refunds, internal review, mediation, arbitration, and whatever else parties choose.

Agentic commerce needs protocols for what happens when everything works. It also needs a failure path for when it does not.