The Delivery Call Is Where Agencies Lose Money. Send a Proof Packet Instead.
A delivery routine for agencies: every AI-assisted job leaves as a redacted proof packet the client verifies in the browser, then accepts or flags.
# The Delivery Call Is Where Agencies Lose Money. Send a Proof Packet Instead.
Every agency knows the call. The work is done, the invoice is ready, and the client spends forty minutes picking at screenshots. "Did the AI write all of this?" "Can you show me the earlier version?" "My partner wants to know what actually changed." All of those questions are billable time nobody bills for, and they exist because the delivery was a claim instead of a record.
Agencies feel it once per client per week, which turns a nuisance into a line item: the account lead's calendar fills with proof-of-work calls that produce no work. The fix is not a better summary email. It is a delivery routine where the proof is assembled while the job runs, checked by the client without a meeting, and identical in shape for every client on the roster. Zambo's handover is that routine, and it runs like this.
The routine, step by step
The job runs, and the record writes itself. Work goes through Zambo's MCP endpoint, https://zambo.dev/mcp, and every tool call in the job writes a verifiable receipt at the moment it happens: the call, the result, hashed as saved. Nobody assembles evidence afterward. By the time the work is done, its record already exists.
Nothing leaves the shop unredacted. Agency work is saturated with material that cannot travel: client email addresses, phone numbers, API keys pulled into a transcript, an internal note about pricing. In a multi-client shop there is a second, quieter risk: one client's details bleeding into another client's delivery. So the handover redacts before it publishes. Emails, phone numbers, and keys are stripped, and what the client receives are redacted copies, new receipts that point back to the originals your side keeps. The client checks a record that is complete about the work and silent about everything else.
One link goes in the delivery email. Handover closes the job's receipts into a single package behind one link: the steps in order, the sources a job relied on counted openly (resolved, not resolved, not checked, with failures printed as failures), and unchecked steps listed as unchecked, not left ambiguous. The client opens it in a browser. No account, no call, no walkthrough.
The client decides, and the shop cannot decide for them. At the end of the packet sit two controls: Accept and Flag. A flag attaches to one named step, so the dispute starts at that step instead of at the whole delivery. An acceptance writes itself into the record with its own receipt. The sender side is shut out of the decision: the creating account and the working agent both get refused if either tries to accept. Try, and the answer is verbatim: "Creator authority cannot accept this handover. Send the client link to its recipient." The decision counts only when the recipient named on the client link makes it.
Two real packets show the two states this produces. One, https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , is an audit job whose acceptance record reads: status accepted, decided by client, four steps out of four checked, release hint ok_to_release. The other, https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 , is still waiting on its client: status pending, release hint hold, five steps in the packet, and no decision recorded yet. A held packet is not a problem to be managed. It is the system working in the open.
What changes when every delivery has the same shape
The first change is where questions go. Instead of arriving on a call, they arrive as flags attached to steps, which means the reply is about one step's output, not about the agency's credibility. The second change is standardization: when every job for every client ships as the same kind of packet, delivery stops depending on which account lead wrote the summary. Repeat clients stop asking how the sausage was made, because the record is sitting next to the sausage.
The live demo at https://zambo.dev/demo/ runs a real job end to end, so you can open the resulting record yourself before you ever send one. Shops that also deliver agent-to-agent, one AI handing work to another, will find that variant of the same mechanics on the AER-1 hub: https://rambozambodotdev.gitlab.io/aer1-hub/
Cost, and what a packet never claims
Public handovers are free. Private links, shop branding, and PDF and JSON export come with the Zambo Pass at $29 a month. The receipts underneath are AER-1, an open format published as an IETF Internet-Draft (draft-zambo-aer1-23) that verifies offline, so the client's check never runs on Zambo's say-so. Full documentation: https://zambo.dev/docs/handover .
A packet never claims the work was right, and it never claims who produced it. Its claim is narrower and, for a delivery, stronger: here is the record of the job, and the record can be checked to prove it was not changed after it was saved. That restraint is what makes the routine repeatable across a roster: one delivery shape, learned once by every client, so the tenth delivery needs no explanation beyond the first.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/
Agency delivering AI work to clients proof
The problem: the delivery call goes badly because the client cannot check what they are accepting. An agency delivers AI work, the client asks how they know the work happened the way the summary says, and the call turns into screenshots, exports, and reassurance. Payment waits on trust the client has no way to exercise. Agency delivering AI work to clients proof is the routine that ends that call: every job leaves as a proof packet, the verifiable receipts for the calls that did the work, bound in order by the job's workflow record, at one link the client opens and checks in the browser before they accept or flag a step.
The check is the client's, and it is short. They open the packet, pick the steps that carry the delivery, recompute one receipt's commitment from its saved result, and read the saved result itself instead of the line about it. Steps that recompute are accepted as recorded; a step with no receipt stays an open question on the call, while it can still be fixed. The packet proves the saved record was not changed since it was saved. It does not prove the work was good, and it never claims who produced it: those judgments stay with the client, now made against a record they checked rather than a report they were asked to believe.
Packets like this exist only when the work runs where each call leaves a receipt, so the routine starts before the job, not at delivery. Run agency work through Zambo at zambo.dev/mcp and every call returns with its verifiable receipt attached, the whole job closing under one workflow record that becomes the packet. For $0.99, a Day Pass covers 24 hours of calls with a receipt on every one. Ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.
Questions, answered
How does an agency prove AI work to clients at delivery?
Send a proof packet instead of a summary: for each job, the verifiable receipts for the calls that did the work, bound in order by the job's workflow record, at one link the client opens in a browser. The client recomputes a receipt's commitment from its saved result and reads the result itself, so acceptance rests on a record they checked, not on the agency's report. The packet proves the saved record was not changed since it was saved; whether the work is good is the client's judgment, made against that checked record.
Does a delivery proof packet prove the AI work was correct?
No. A proof packet proves the saved record of the job was not changed since it was saved, and it lets the client read exactly what each call returned. Correctness, taste, and fit stay human judgments. What the packet removes is the argument about whether the work happened and what it produced: that part is settled by the record, so the delivery conversation can be about the work itself.
Related guides
- My client will not pay until they can check the work. Here is the packet I send
- How to document AI work for client billing, so the invoice has a record to stand on
- Four clients, three AIs, one page that shows the whole day's record
Agencies reporting to many clients at once: the main site lays out the best way for an agency to report AI work to clients as a repeatable per-client packet.