When an agent pays an agent, the deal can still go wrong — wrong result, partial result, no result. Two agents that met at runtime have no chargebacks and no courts. Something has to hold the funds and arbitrate. What that something is.
A payment rail and a commerce layer are not the same thing, and the gap between them is the whole subject here. A rail moves money: it gets value from one party to another, fast and cheaply, and a stablecoin rail does that for agents very well. A commerce layer does something the rail does not — it survives the deal going wrong. The two get conflated because a working rail feels like a finished system right up until the first transaction that does not go cleanly, and then the missing layer is suddenly the only thing that matters.
Picture the failure concretely. Agent A pays agent B to perform a task. B returns something. Now walk the ways “something” can be wrong: the result is incorrect; the result is partial; the result is fine but arrives past the point it was useful; or B took the payment and returned nothing at all. In human commerce there is a thick, accreted layer of recourse for every one of these — chargebacks, merchant reputation that took years to build and can be lost, small-claims court, the card network’s structured dispute process. Two agents that discovered each other at runtime, settled in stablecoins, and will in all likelihood never transact again have access to none of it. There is no network to appeal to, no court with jurisdiction, no reputation either side has staked.
So the question agent commerce has to answer before it can be trusted with anything of value is plain and unglamorous: when the deal goes wrong, who holds the money, and who decides? This essay is about that layer — escrow and dispute resolution for agent-to-agent commerce. It sits directly on top of the payment rail that the stablecoin-rails essay describes, and without it the rail can move money but cannot support a deal.
There are two obvious ways to settle an agent-to-agent deal without any intermediating machinery, and the instructive thing is that they fail in opposite directions — so neither one is a refinement of the other, and no amount of tuning either gets you to safe.
The first is pay-first, on trust: A sends the money, and then B does the work. This collapses the moment B is dishonest or simply broken. B keeps the funds, the work never arrives, and A is left with no recourse against a counterparty it cannot locate again and never had a relationship with. All of the risk sits on the payer.
The second is pay-last, on proof: B does the work, and then A pays. This fails the other way around. B delivers in good faith, and now A is the party that can simply walk — close the connection, leave B unpaid for work already completed and already delivered. All of the risk sits on the provider.
The symmetry is the lesson. These are not a safe option and an unsafe one; they are two unsafe options, each of which loads the entire risk of the deal onto one side of a transaction between parties with no relationship, no shared history, and no common enforcement authority. Whichever party does not hold the money is exposed, completely, to the other’s choice to defect. The fix is the one human commerce converged on centuries ago and for the same reason: do not let either party hold both the money and the leverage at the same time. Put the funds somewhere that neither side controls, and release them only when an agreed condition is met. That somewhere is escrow, and the rest of the design is about what the condition is and who gets to judge it.
The cleanest current design for agent commerce is verify-then-pay with escrow, and TessPay (arXiv 2602.00213) is a worked instance of it. The structure is worth tracing carefully, because each element answers a specific weakness of the two trust-based defaults.
A’s funds are locked in an escrow contract — not sent to B, and equally not retained by A. That single move neutralizes both failure directions at once: B cannot abscond with funds it was never given, and A cannot withhold funds it no longer controls. B then executes the task and produces cryptographic evidence of having done so — a Proof of Task Execution, assembled from artifacts such as TLS-notarized outputs or trusted-hardware attestations, evidence whose validity does not depend on B’s honesty about it. The escrow contract releases the funds to B only when that proof satisfies a set of verification predicates, and refunds A deterministically if it does not. Every step along the way leaves a tamper-evident audit trail, so the history of the deal is itself non-repudiable.
A's funds ──► [ escrow contract ] B executes task
│ │
│ produces Proof of Task Execution
│ │
▼ ▼
predicates satisfied? ◄── verify proof
│ │
yes ── ▼ no ── ▼
release to B refund to A
└──── tamper-evident audit trail ────┘The property that makes this work for agents specifically — and not merely for humans willing to wait on a process — is that the release decision is deterministic. There is no human in the path, no negotiation, no discretionary judgement: the contract checks the proof against the predicates and either releases or refunds, and the outcome is a function of the evidence. Determinism is what lets the mechanism run at machine speed and machine volume. A dispute process that needs a person does not scale to thousands of small deals an hour; one that resolves to a predicate does.
A tighter variant collapses the escrow into the payment itself. A402 (arXiv 2603.01179) uses trusted-hardware-assisted adaptor signatures to build atomic service channels, in which the payment cryptographically finalizes only on correct delivery — there is no separate escrow contract because the atomicity has been pushed down into the payment primitive. It is the same principle with fewer moving parts, and it is available whenever the delivery can be bound to the payment that tightly. When it cannot, the explicit escrow contract is the more general tool.
Verify-then-pay works when “did B do the task correctly” is a question a predicate can actually answer — a computation that can be deterministically re-run and compared, an output that can be checked against a machine-readable spec, a proof that either validates or does not. A large fraction of agent commerce is exactly that mechanical: fetch this data, run this transformation, return a result with these checkable properties. For all of it, escrow plus deterministic verification is the entire answer, and nothing more elaborate is needed.
But not every deal reduces to a predicate. “Was this research summary actually good.” “Did the generated design meet the brief.” “Is this analysis sound.” These are real agent tasks, increasingly common ones, and none of them resolves to a boolean a contract can compute. When the release condition is a judgement call, escrow on its own reaches an impasse: it is holding the funds correctly and it has no way to decide whether to release them, because the condition it would check is not checkable. Something has to adjudicate — supply the judgement the predicate cannot.
The model that exists for this is decentralized arbitration. Kleros is the worked example: a smart-contract-based dispute system in which jurors are selected by staking a token, decisions are driven by game-theoretic incentives rather than by a trusted central authority, and there is a structured appeals mechanism for contested outcomes. It is not a thought experiment — it has been analyzed as a real, operating arbitration system in a peer-reviewed case study (Bergolla, Seif & Eken, Ohio State Journal on Dispute Resolution, 2022). An escrow contract that cannot decide a release on its own can defer that specific decision to an arbitration oracle of this kind — escalating, exactly as the human-in-the-loop essay describes for agent gates, only when the deterministic path has genuinely run out, not as a routine step. On-chain, ERC-8004’s Validation Registry provides the generic hook for precisely this: a standard place to request and record an independent validator’s check, whether that check turns out to be a re-execution, a zero-knowledge proof, or an arbitration result. The escrow does not need to know in advance which kind of judgement it will need; it needs a place to send for one.
Both escrow and arbitration rest on one thing being unambiguous, and it is the thing most likely to be quietly assumed: what the deal was. If A and B disagree about what B was actually engaged to do, then no escrow predicate can be evaluated and no arbitrator can rule, because the object being judged is itself in dispute. A predicate checks a result against a specification; if the specification is contested, the predicate has nothing fixed to check against. An arbitrator weighs delivery against what was promised; if what was promised is contested, the arbitrator is guessing. Escrow and arbitration both need the terms of the deal to be settled fact before they can operate on it.
That settled record is what the agent-payments mandate model supplies, and it is worth being precise about what it does and does not do. Google’s Agent Payments Protocol — AP2, the google-agentic-commerce/AP2 specification — chains three cryptographically signed mandates: an Intent Mandate, in which the user delegates authority to the agent; a Cart Mandate, approving a specific deal at a specific price; and a Payment Mandate. It explicitly targets three questions — Authorization, Authenticity, and Accountability — and the chain of signatures means each of those is answerable after the fact from the record rather than from anyone’s recollection. The work on secure autonomous agent payments (arXiv 2511.15712) adds on-chain intent proofs and an immutable audit trail linking authorization to outcome, so the whole arc from “what was authorized” to “what happened” is one tamper-evident object.
Now the distinction that the strongest designs get right and the weak ones collapse: this is the evidence layer, and it is not the adjudication layer. The two are different jobs and different components. Signed mandates give an arbitrator a non-repudiable record of what was authorized and agreed — they make the terms of the deal an established fact rather than a he-said-she-said. They do not themselves decide a dispute, and they do not reverse a transaction. AP2 tells you, unforgeably, what the deal was. Kleros, or an ERC-8004 validator, decides whether that deal was honoured and what to do if it was not. A design that conflates the two has built an excellent evidence trail and then mistaken it for a dispute process — and the gap shows up at the worst possible moment, the first contested deal, when the system can prove exactly what was promised and still has no mechanism to decide whether it was delivered. Evidence is the input to adjudication. It is not a substitute for it.
There is a temptation, once escrow and arbitration and a mandate chain are all on the table, to run the full apparatus on every deal. That is the wrong default, and seeing why sharpens what the layer is actually for. Cryptographic proof generation, on-chain validation calls, and staked-juror arbitration all cost something — in latency, in fees, in complexity — and a two-agent deal worth a fraction of a cent cannot bear the cost of an arbitration process designed to resolve a contested judgement. Run heavyweight adjudication on a micro-payment and the dispute machinery costs more than the thing in dispute, which is its own kind of failure.
The principle that resolves this is that the strength of the trust mechanism should scale with the value at risk. A small, low-stakes deal can settle on a lightweight verify-then-pay predicate, or even on a fast atomic-channel primitive, and accept that the rare bad outcome is cheaper to absorb than to litigate. A large deal — one where a wrong or withheld outcome is a real loss — is where the escrow contract, the independent validation call, and a path to arbitration earn their cost. The design is not one fixed pipeline applied uniformly; it is a graduated set of mechanisms, and the deal’s value selects which one runs. A commerce layer that treats every deal identically has either overbuilt the small ones into uneconomic friction or underbuilt the large ones into unacceptable exposure. Matching the mechanism to the stake is what keeps both ends viable.
A rail that only moves money has built for the deal that goes right. The commerce layer is built for the other one — and between two agents that met a second ago and will never meet again, the other one is not the exception.
Our taxonomy argued prompt injection is a vulnerability class you contain, not a bug you fix. Here is the quantitative half — against the strongest published defenses, indirect-injection attack success stays high, and for agents that can act it stays alarming.
10 min →
A quality-ascending curriculum beats random shuffling — until a decaying schedule delivers your best data exactly when the learning rate is too small to absorb it. The same coupling flips proxy-model ablations: which dataset wins depends on the schedule, not the data alone.
13 min →
An agent workflow that pauses for human approval and then resumes looks safe — a person clicked approve. But the approval decision and the authority the resumed step runs under are two different objects, and most systems conflate them by carrying the approval as an in-band signal the resumed call trusts. That is a confused-deputy bug: a forged resume, a replayed request, or an approval granted at one gate authorizes an action it was never meant to. The fix is to stop transporting approval and start deriving authority from the trusted approval record at resume time, scoped to the exact suspended step — capabilities enforced at the tool boundary, fail-closed by default.
14 min →