Proof before payment: check the work before the money moves.

Paid is not accepted

Three different records get blurred into one in agent commerce, and only one of them answers the payer's question:

• The payment receipt proves money moved, and that the server claims it delivered. It is a record about the payment.
• Execution receipts prove what ran and what came out, step by step, in a form anyone can re-check. They are records about the work.
• An acceptance records that a receiver opened the delivery, checked it, and said yes, with a receipt of its own. It is the record about the decision.

Escrow and upfront flows commit the money before any of the second or third records exist, and the payment layer has no built-in way to ask for them. So the check has to happen on the work side: before release, read the acceptance. If there is no acceptance, there is nothing to release against yet.

The check-before-release pattern, with what exists today

1. The work runs as recorded calls. The working agent does the job through Zambo, so every tool call leaves a verifiable receipt: the tool, the inputs, the saved output, the time.
2. The job is handed over as one link. The agent asks Zambo to hand the work over to the buyer. The handover gathers the session's receipts, redacts emails, phone numbers, and keys, and publishes one page: every step, what was not checked, and a summary receipt closing the set. The receiver needs no account to open it.
3. The receiver checks, then decides. On the handover page the receiver presses Verify all to re-check every step in their own browser, can try to break a step, and then accepts or flags the delivery. The answer mints its own receipt, pinned to the handover's original Merkle root, and the status flips to accepted. An agent receiver can do the same through the handover_accept tool.
4. The payer reads before releasing. Fetch the handover's acceptance record at /handover/<id>/acceptance.json and read the release_hint. It reads hold while the handover is pending, and still reads hold when the work is flagged. It reads ok_to_release only when a client has accepted, with decided_by: "client" and the decision time in decided_at. A machine can gate a release on that one field; a person reads the same answer on the handover page. The release decision stays with whoever holds the funds.

The full mechanics are documented at zambo.dev/docs/handover, including the respond API a buyer agent uses at /api/v2/handover/<id>/respond.

Two live handovers, two different answers

Both pages are public and live. Open them, run Verify all, and read the events yourself. The difference between the two states is the entire pattern.

What a paying agent reads

Every handover has a dedicated acceptance record at /handover/<id>/acceptance.json, readable with no account, built for exactly this read. Its fields are the plain ones:

• status: pending, accepted, or flagged.
• release_hint: hold for pending and flagged; ok_to_release only after a recorded client acceptance.
• decided_by and decided_at: who the record says decided ("client"), and when. Both null while nobody has decided.
• steps_total, steps_checked, steps_unchecked: how much of the delivery carries checked receipts, plus the check_scope the record prints about itself: "Receipt bytes only; not accuracy or human review of every step."
• receipt_urls: a link to every step's receipt, openable by anyone.
• aer1_version: the receipt format revision the record runs on, "draft-zambo-aer1-23".

The fuller record sits behind it: the handover's JSON twin at /handover/<id>.json carries the steps, the events list (each answer with its action, its timestamp, its own receipt id, and the original Merkle root it pins to), and the not_checked and not_proven lists.

One rule the record enforces on itself: the agent that created the handover cannot set it accepted. Ask through the MCP handover_accept tool from the creating session and the call is refused, error code "forbidden": "Creator authority cannot accept this handover." The web respond path under creator authority returns HTTP 403 with the same refusal. Only the client side can move release_hint to ok_to_release.

A person reads the same facts on the page in a browser. The record does not care which side of the transaction is software and which is human; the check is the same check.

What Zambo is not, in this pattern

Zambo never holds funds. It is not an escrow, it does not release or reverse payments, and it does not decide disputes. The money moves on the rail the buyer and seller chose; Zambo produces the work record and the acceptance record that the payer reads first. The acceptance also does not prove the work is correct, and the record says so itself: every handover prints a not_proven list (outside timestamp, issuer identity, result correctness), and the acceptance event carries the notice that the visitor's identity was logged by Zambo, not identity-verified. A verifiable receipt shows the saved result has not changed since it was recorded; it does not prove the result was right. What the pattern removes is the blind spot, paying against a claim. What it never removes is the payer's judgment.

Questions, answered