Direct answer
My client says I never delivered the work. Here is the record that answers.
The delivery argument is unwinnable from a sent folder: it proves a message left, not which version was inside it, and the client's memory of what arrived is just memory. The fix is to make the delivery a record at the moment it happens: the job worked inside one shared record on Zambo, every step saved with a verifiable receipt, the finished work wrapped as a handover the client opens and checks step by step. When the claim comes, you do not argue. You send the link.
pip install zambo-delivery or npm install zambo-delivery.Updated November 2, 2026. First published November 2, 2026. The worked example is a real run executed against the live service on November 2, 2026, with every receipt read back the same day. The client in the run is fictional and labeled a sample in the records themselves, so the shape can be inspected without anyone's real work on display.
New to this? Start here, no code
Add the Zambo endpoint (zambo.dev/add) to your chat AI, then paste this block. Work the job inside it, and the delivery record builds itself while you work.
The paste
Work this client job with a delivery record on Zambo: 1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. 2. Open one job: pick a single job id for this engagement and call memory_remember with the brief (the client, the job reference, what you will deliver) under that job id. Keep the receipt. 3. Save each step with memory_remember under the same job id as you finish it: draft, revision, the version you send. Keep each fact under 500 characters. After every call, check the result says ok before you treat the step as saved. 4. When you deliver, wrap the job with handover: a summary naming the job, the client, and each step with its receipt; a goal; the client as the recipient; next steps telling the client to read the steps and check any receipt at https://zambo.dev/verify/. 5. Send the client the handover link, not just the files. The link is the delivery record: what you sent, when, step by step. If the client ever says a piece never arrived, open the link together and walk the steps.
Why this argument is unwinnable the usual way
Your sent folder proves you sent something, not what it contained. An email timestamp shows a message left. It does not bind the exact revision inside it to a record the client can check today, and attachments get saved, renamed, and edited on the other side.
The client's memory is not lying, it is just memory. Three weeks and four projects later, the version they remember approving is the one they saw last. Arguing memory against memory burns the relationship even when you win it.
The fix is to make the delivery a record at the moment it happens. Work saved step by step inside one job, wrapped into one handover link, means the question "did you deliver it" stops being a debate. It becomes a link you open together.
The pattern
Step zero: connect once, save the caller handle the endpoint issues, and present it on every call. The client holds a separate handle; the sign-off only means anything because it comes from a different identity.
1. Open: save the brief under one job id, receipted.
2. Work inside the job: draft and revision saved as steps under the same job id, each with its own receipt.
3. Wrap the delivery: one handover addressed to the client, its proof loop binding the job's steps.
4. The client picks it up: pickup is always free, returns the steps from the record itself, and the client's sign-off step closes the loop.
The real run: a delivery the client later questioned
Executed November 2, 2026, against the live endpoint. One worker and one client, separate identities, one shared job id, uc-delivery-2026-11-02. The job is a labeled sample: homepage copy for Marina Cole Studio, a fictional sample client, job UC-1043, marked SAMPLE in the records themselves. The worker opened the job with the brief: receipt 084b67dd. The draft v1 step: receipt 74bb7b07. The revision v2, the version that left the worker's hands: receipt 23c0730f.
The worker wrapped the delivery: the delivery handover, or its JSON twin. It lists 4 steps and its own proof loop has checked 4 of 4 step receipts, none unchecked. The client picked it up, read the steps from the record, and saved a sign-off: receipt e1a7e6b7. The handover reads back status accepted.
Now the dispute this page exists for. Suppose next month the client says the revision never arrived. Nobody re-argues the thread. The worker sends the handover link, opens the revision step, and checks its receipt: the saved record shows exactly which version was saved as the delivered one, and the receipt proves that saved record has not changed since. The conversation moves from "did you send it" to the work itself, which is where it belonged all along. The pattern also ships as an installable agent package: pip install zambo-delivery or npm install zambo-delivery, and the full pattern guide is the delivery proof guide.
Audit this delivery yourself
Do not take this page's word for it. Open the delivery handover, pick the revision step, open its receipt, and check it at zambo.dev/verify. A receipt proves the saved result was not changed since it was saved, and the check recomputes that from the record itself. If a receipt from this run ever fails to verify, that is news: write to brennanzambo@zambo.dev.
What this costs
The free tier is per identity: 20 calls + 1 wrap-up free every day for each identity's own caller handle, and picking up in another AI is always free. Counted from the run: the worker spent 3 counted calls (brief, draft, revision) plus its free wrap-up; the client spent 1 counted call (the sign-off), pickup free. Total 4 counted calls across two allowances. When the work outgrows free, a Day Pass is $0.99 per identity, unlimited for 24 hours, and the Zambo Pass is $29 per identity for 30 days; both are one-time payments, never subscriptions. Start at zambo.dev/add.
What Zambo is not here
Zambo does not write the copy, price the job, or decide whether the client should love it. It proves what was saved as delivered, and when, and that the record has not moved since. Quality stays a judgment call; delivery stops being one.
Frequently asked questions
My client says I never delivered the work. How do I prove what I actually sent?
Deliver inside a record, not a thread. Work the job on Zambo under one job id, save the brief, the draft, and the exact revision you send as steps, each with a receipt, and wrap the job as a handover to the client. When the claim comes, send the handover link: it lists the delivered version as a saved step whose receipt anyone can check at zambo.dev/verify, proving the saved record has not changed since delivery.
Does the receipt prove the client received it?
The pickup does. The client picks the handover up under their own identity, and the handover reads back status accepted, with the client's sign-off saved in the same job. Delivery and acceptance are both steps in one record, so the record answers both halves of the argument.
Does a receipt prove the work was good?
No. A receipt proves the saved result was not changed since it was saved. It settles what was delivered and when, and that the record did not move afterwards. Quality stays the client's judgment call, and it can finally be a judgment about the work instead of about whose memory is better.
What does this cost?
The run on this page used 4 counted calls across two free allowances. The free tier is 20 calls + 1 wrap-up free every day per identity, and picking up is always free. Past free, a Day Pass is $0.99 for 24 unlimited hours and the Zambo Pass is $29 for 30 days; both are one-time payments, never subscriptions.