When agent work is disputed, evidence beats argument.

The two disputes

Almost every fight over agent work is one of two shapes:

• Did it happen? The client doubts the agent did what was billed: the research, the checks, the runs. The vendor insists it did. Both sides are working from memory and summaries.
• What actually happened? Everyone agrees the agent ran, but the result is wrong, incomplete, or different from what was promised. Now the fight is over what the agent really produced versus what it claims it produced.

Both disputes share a root cause: the only record of the work is controlled by one of the parties arguing about it.

Why transcripts and screenshots lose

Most of what people bring to an agent dispute would not survive a skeptical third party:

• The chat transcript. It is the agent describing its own work, in its own words, after the fact. It can be wrong, selective, or invented, and nothing in the transcript lets anyone tell.
• Exported logs. Logs are written by the same system being argued about. Editing a log after the fact is trivial and undetectable.
• Screenshots. A picture of a result proves the result existed on a screen at some point. It proves nothing about when it was produced, by what, or whether it was altered.
• "The agent said it was done." A status string is a claim, not evidence. It attests to nothing checkable.

The common thread: every one of these requires trusting the party whose work is being disputed. Evidence has to survive distrust, or it settles nothing.

The evidence hierarchy

When a third party has to decide, evidence ranks itself. Strongest first:

1. A contemporaneous verifiable record. Captured at execution time, bound to the exact bytes with a SHA-256 commitment, tamper-evident. Neither party can rewrite it after the fact, and anyone can verify it independently. This is what settles disputes.
2. Timestamped append-only logs. Better than a transcript, weaker than a verifiable record: they show sequence and timing but can still be edited by whoever controls the system.
3. Chat transcripts and summaries. Useful for understanding intent, worthless as proof of what happened.
4. Verbal claims. "The agent did the work" versus "no it did not." This is where disputes go to stalemate.

The practical lesson: if you want to win a dispute you cannot predict, you need level one evidence from the moment the work runs. You cannot reconstruct it afterward.

What to collect before you dispute

Whether you are the client or the vendor, assemble the same packet before the conversation starts:

• The verifiable receipt for the run. Run ID, timestamp, result, and the SHA-256 commitment. If the other side cannot produce one, that fact alone usually ends the "did it happen" dispute.
• The exact bytes delivered. Not a summary of the deliverable: the deliverable itself, so its hash can be checked against the receipt.
• The agreed acceptance criteria. What "done" and "correct" meant before the work started. Most correctness disputes are really scope disputes wearing a costume.
• The timestamps. When the work ran versus when it was claimed. A receipt captured at execution time answers this; a reconstructed timeline does not.

Run the receipt through an independent check first: zambo.dev/verify verifies a receipt with no signup. If it checks out, the result you are holding is the result the tool actually returned. Argue from there, not from the transcript.

Verify the work, then pay

The cheapest dispute is the one that never starts. Make verification a condition of payment, not a post-incident investigation tool: every unit of billed agent work ships with a verifiable receipt, and payment clears when the receipts verify. Freelancers, agencies, and internal teams can all comply with the same open format, AER-1, an IETF Internet-Draft (draft-zambo-aer1), which means the check does not depend on any one vendor's dashboard or goodwill.

This protects the vendor too. A client cannot credibly claim work never happened when independent receipts exist. Symmetric evidence is what makes the pattern fair: it constrains the biller and the payer equally.