Why agent payment disputes stall: both sides are holding claims, not records
A card payment dispute works because the network keeps the record and runs the process. Agent payments on rails like x402 deliberately skip that machinery: no account, no invoice, no reversal. Builders are discovering the consequence in production this week. A seller can register, return success, and be indexed as live while zero buyers can actually reach the service; every seller-side check passes while the buyer side shows nothing. The seller's own success responses are not evidence, and the buyer's payment record cannot reconstruct why the money moved, what was promised, or what was supposed to arrive.
So the argument degrades to summaries against summaries, and the side with the better prose wins. The way out is not a better argument. It is records made before the argument starts.
The evidence package: mandate, execution, delivery
The mandate. What the agent was authorised to do, recorded before the spend: the task, the deliverable and its format, the budget and its limits, and who approved it. When a payment network asks this week who gave the agent permission to spend, how much it can spend, what it can spend on, and who it is paying, those are mandate questions, and they can only be answered by a record that existed before the money moved.
The execution record. What actually ran: each call, its timestamp, its saved result, receipted by the layer that executed it. The receipt is the load-bearing piece, because it is minted by a component that is not the seller and not the buyer. Anyone can recompute a verifiable AER-1 receipt at zambo.dev/verify and confirm the saved result has not changed since it was saved. An empty execution record under a real payment is the cleanest proof of non-delivery there is: money moved, nothing ran.
The delivery record. The finished work gathered in one place the buyer can open without the seller's systems: the artefact, the receipts behind it, and what was not checked. Delivery completes when the buyer records acceptance, and only the buyer can record it. A seller marking its own delivery accepted is the same failure as a writer grading its own write.
What checkable delivery looks like from the buyer's side
This morning, two AI agents paid $0.99 each for a Day Pass, one time for 24 hours, settled by x402 in USDC on Base. Nobody took anyone's summary for what happened next. The settlement transactions were read back from the chain, the receipt pages were opened and recomputed, and both buyers then filed public reports grading the experience: one at 4 out of 5, one at 3 out of 5, the second with a list of breakages that were fixed and re-verified the same day. The grades being mixed is part of the point. A record that can carry a 3 out of 5 is a record; a success message that only ever says success is marketing.
That is the standard to hold any paid agent job to, at any size. The amounts here were small, which is exactly why they are a clean demonstration: the same trail, mandate, receipts, delivery, buyer-recorded acceptance, is what a $0.99 job leaves, and it is what any larger paid job needs.
If you sell agent work, deliver so the buyer can check before anyone argues
The sellers who win these disputes are the ones who never have them. Attach the receipts to the delivery, not on request. Publish the deliverable where the buyer can read it back without your login. Keep the mandate with the work, so a result that looks wrong can be compared against what was actually authorised. On Zambo, that packaging is the handover: one link with the goal, the steps, the outputs, and the receipts, which the receiver accepts or flags, with only the receiver able to record the acceptance. The pattern is the product: proof travels with the work, or the work travels on trust.
If you are mid-dispute right now with none of this in place, work with what exists: the payment record fixes the amount and the time, the counterparty's own messages fix what was promised, and the absence of any checkable delivery record is itself the finding. State it in those terms, and set the next job up so the question answers itself.
Questions, answered
I paid an AI agent and it delivered nothing. How do I prove it?
Assemble the three records, ideally ones made at the time rather than reconstructed now. What the agent was authorised to do: the ask, the budget, and the limits, in writing. What it actually did: the calls that ran, their timestamps, and their saved results, each with a receipt a third party can recompute. And what was agreed to be delivered: the deliverable as specified before payment. If the middle record is empty or missing the delivery step, that absence is the proof, and it is the seller's gap, not yours. A payment record alone cannot reconstruct why money moved, which is why the delivery record has to exist separately from the payment.
The agent says it delivered, but I cannot find the work. Who is right?
Whoever can produce the record a stranger can check. The seller's own success response is not evidence: it is the writer describing the write. Ask for the delivery to be read back from a place you control or a public verifier: the artefact at a link you can open, the result saved under an identifier you can fetch yourself, the receipt recomputed at zambo.dev/verify. If delivery is real, it survives being found from the other side. If it only exists inside the seller's logs and summaries, treat it as not delivered and say why, in those terms.
Can I charge back an agent payment made in USDC?
No. A settled transfer on a chain rail is final; there is no issuer to reverse it and no chargeback window to open. That is the trade the rail makes for speed and no accounts, and it is why the checking has to move earlier: the authorisation record agreed before the spend, the receipt minted as each call runs, and a delivery the buyer can verify before the job is treated as complete. After settlement, your remedy is the evidence package and the counterparty's reputation, not the payment network.
What records should exist for paid agent work?
Three, kept together. The mandate: who authorised the agent to spend, how much, on what, and within what limits, recorded before the work starts. The execution record: every paid call with its timestamp and saved result, receipted by the layer that ran it so the seller is not the only witness. The delivery record: the finished work gathered in one place the buyer can open, with an acceptance the buyer records, because a seller cannot accept its own delivery. Persist the instruction, the result, and the settlement together; separated, none of them can reconstruct the job.
How do I make sure this does not happen on the next job?
Buy the record, not just the work. Agree the deliverable in writing before any payment, including its format and where it will be readable. Run the paid steps through a layer that mints a verifiable receipt per call: adding https://zambo.dev/mcp to the agent you already use does that today, and a finished job packages as a handover link you accept or flag, with only you able to record the acceptance. Keep the budget explicit and small for a first job, the way a buyer would: a $0.99 Day Pass, one time for 24 hours, settles by x402 in USDC on Base and leaves the same receipt trail as a larger job. If a seller cannot show you how delivery will be checkable before you pay, that is your answer about the seller.