# Deliver the work, keep the proof: client delivery as one checkable record

Client delivery rarely fails on the work. It fails on memory: what exactly was sent, when it was sent, and whether the thing being argued about today is the thing that was delivered then. Zambo is the layer under the delivery: one job the work lands in, one identity per side, handovers that carry the finished work to the client, and a verifiable receipt for every single call. This guide teaches the pattern twice: once as pastes for people brand new to it, and once at full depth, with a real delivery run and every receipt linked.

- HTML version: https://rambozambodotdev.gitlab.io/aer1-hub/delivery-proof-package.html
- Start free: https://zambo.dev/add/
- Endpoint: https://zambo.dev/mcp
- Verify any receipt: https://zambo.dev/verify/
- The package: `pip install zambo-delivery` or `npm install zambo-delivery`, source https://github.com/zambodotdev/zambo-delivery-proof

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. Author: Brennan Zambo.

## New to delivering with proof? Start here, no code

You need one chat AI for the worker and one for the client. Add the Zambo endpoint to each one first (the one-step setup at https://zambo.dev/add/), then paste the worker block into the worker's chat and the client block into the client's chat, and name the job. Each AI saves the identity (its caller handle) that the endpoint issues inside its own conversation. The worker saves each step as it works and wraps the delivery; the client opens one link, reads the steps, and picks the delivery up. Nothing else needs to be built.

### The paste, for the worker

```
Deliver client work with proof 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. You are the worker; the client holds a separate identity of their own.
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. Work inside the job. Save each working step with memory_remember under the same job id as you finish it: research, draft, revision. Keep each fact under 500 characters; longer facts are refused. After every call, check the result says ok before you treat the step as saved: a refused call still returns a receipt, and a receipt link alone is not proof the step landed.
4. Wrap the delivery with handover: a summary naming the job, the client, and each step with its receipt; a goal; the client named as the recipient; and next steps telling the client to read the steps and check any receipt at https://zambo.dev/verify/. Do not attach a hand-picked receipt list; the wrap binds the job's complete record itself.
5. Send the client the handover link. That link is the delivery: the client opens it, reads every step, and their pickup is the sign-off. Keep the link and the wrap receipt together as your delivery pack.
```

### The paste, for the client

```
Receive a delivery and sign off 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. You are the client; your identity is separate from the worker's, and that separation is what makes your sign-off mean something.
2. Open the handover link the worker sent you and read the steps in order before accepting anything: the brief, the work steps, and the receipts attached to each.
3. Check any step's receipt at https://zambo.dev/verify/ before you rely on it. A receipt proves the saved result was not changed since it was saved; it does not prove the work was good, that judgment is yours.
4. Pick the handover up with handover_accept. Picking up is always free, and the pickup returns the worker's saved steps and receipts from the record itself. Read them there, not from the worker's summary.
5. Save your sign-off with memory_remember under the same job id: one short step naming the handover and stating that you read its steps and accept the delivery. Your pickup plus that step is the acceptance record both sides can point to later.
```

That is the whole pattern at hand scale. Everything below is the same pattern with the depth turned up: persistent identities, exact accounting, the two refusals this pattern is built around, and the receipts of a run executed by code.

## What client delivery actually struggles with

**The memory argument.** The job ends, weeks pass, and the client asks for the version they remember approving, which is not the version in your sent folder. Two honest people, two different records, and the louder memory wins. A delivery that lives as steps in one record ends this: what was delivered is a link, and the link does not remember anything, it just shows what was saved.

**The scattered record.** The brief is in email, the draft is in a doc, the revision is in a chat thread, and the approval is a thumbs-up emoji somewhere. Reconstructing the delivery means archaeology across four tools, and the reconstruction is itself an argument. Working inside one job from the first step means the record assembles itself while the work happens.

**Sign-off that is not.** A client who says "looks good" in a chat has approved a message, not a record. When the dispute comes, nobody can show which artifact the approval attached to. A pickup is different: the client identity acts on the delivery record itself, reads its steps from the record, and the handover reads back accepted. The approval and the artifact are the same object.

## The pattern

- **Step zero, per identity**: each side connects once, is issued a caller handle, saves it, and presents it on every call. The worker and the client hold separate handles, never shared: identity, memory, and the daily free allowance all key to it, and the sign-off only means anything because it comes from a different identity than the work.
- **1. Open**: the worker opens one job (a single `_session_id` for the engagement) and saves the brief to memory under it, receipted.
- **2. Work inside the job**: every working step is saved under the same job id as it happens, each fact under 500 characters, each result checked ok before moving on. Every call returns a receipt.
- **3. Wrap the delivery**: the worker wraps the job into a handover addressed to the client: summary naming each step and its receipt, goal, recipient, next steps. The wrap's proof loop binds the job's complete record into the handover.
- **4. Pick up and sign off**: the client picks the handover up with `handover_accept`, always free, reads the steps and receipts from the record, and saves a sign-off step in the same job naming the handover.
- **5. Hold the pack**: the handover link plus the sign-off receipt is the delivery pack. When proof is needed, walk it: every step, in order, with its receipt.

## The real run: a landing page, delivered and signed off

Executed November 2, 2026, against the live endpoint. One worker (delivery-worker-r3) and one client (delivery-client-r3), each initialized separately, each issued its own caller handle, all work inside one shared job id, delivery-proof-sample-2043-r3. The job is a labeled sample: landing page copy for Harbor Lane Bakery, a fictional sample client, job reference SAMPLE-2043, every fact invented for the sample and marked SAMPLE in the records themselves. The worker opened the job with the brief: https://zambo.dev/run/96186fb5-daa6-4175-98ca-9f4fab592ac6

### The steps, as delivered

- Research note (audience, invented sample facts, tone): https://zambo.dev/run/f4c4621a-da05-4bf2-a5c0-16c5aeba07fd
- Draft v1 of the landing page copy: https://zambo.dev/run/ed36d719-70e3-4519-a9b5-3456a013e786
- Revision v2, the delivered version (headline tightened, Saturday line moved into the subhead, call to action given the deadline): https://zambo.dev/run/de873f15-31ad-4c5f-a08f-b9827fc6d7c9

The worker wrapped the delivery: https://zambo.dev/handover/31715914-80eb-438d-b01b-d2307cc4800e (JSON twin: https://zambo.dev/handover/31715914-80eb-438d-b01b-d2307cc4800e.json). Its step list is the brief, the research note, the draft, the revision, and the wrap's own proof-loop check, in order. The wrap's own receipt is https://zambo.dev/run/7b0cd0bd-f3c6-4c85-882e-9149531c05f7, and its workflow receipt is https://zambo.dev/run/aa466129-e2b6-4858-a7e0-3e52e6cb708e. The client picked the handover up, read all three step receipts from the pickup record, and saved its sign-off in the same job: https://zambo.dev/run/307e0707-0f54-48c0-a135-aa1745d1aac5. The handover reads back status accepted. Runnable code for this exact run shape ships in the package as deliver.py, with check_delivery.py as the walker: https://github.com/zambodotdev/zambo-delivery-proof, or install it from PyPI (https://pypi.org/project/zambo-delivery/) or npm (https://www.npmjs.com/package/zambo-delivery).

## Audit this delivery

Do not take this page's word for any of it. Open the delivery handover (https://zambo.dev/handover/31715914-80eb-438d-b01b-d2307cc4800e), pick any step, open its receipt, and check it at https://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, without asking anyone to vouch for it. If a receipt from this run ever fails to verify, that is news, and we want to hear it: write to brennanzambo@zambo.dev. A record that moved after it was saved is the one failure this system exists to make visible.

## The two refusals this package is built around

Building this package produced two refusals from the live endpoint, and both are now load-bearing parts of the pattern. **First: a wrap holds only its own job's record.** An early wrap attempt passed a hand-picked list of receipt ids and was refused on the spot, receipted at https://zambo.dev/run/1d25e082-32c6-4677-b29d-9dfc08d57243: "One or more requested receipts do not belong to this job. Nothing has been published." A partial or foreign selection does not publish. The shipped pattern passes no selection at all and lets the wrap's proof loop bind the job's complete record. **Second: a refused call still returns a receipt.** The first research text ran past the endpoint's 500 character fact cap and was refused before execution, receipted at https://zambo.dev/run/22ef6c40-5944-426f-b1db-1383c28e5e17. An integration that treats any receipt link as a saved step would have shipped a delivery with a hole exactly where the research belonged. The shipped code keeps every step under the cap and checks the result's ok flag after every call, stopping on a refusal instead of papering over it.

## Step zero, at depth: two identities, not one

When an agent initializes against https://zambo.dev/mcp, the endpoint issues a caller handle (in the initialize response and the `X-Zambo-Caller-Handle` header). That handle is the agent's continuity identity: its memory, its job timelines, and its daily free allowance all key to it. The discipline is mechanical. Each side saves its handle in its own state file before doing anything else, presents it as `_caller_handle` on every call, and adds its agent name as `_caller_label` so the job's record attributes every step to a named agent. Delivery adds one rule the swarm pattern does not need: the two sides never share. If the worker and the client were one identity, the pickup would be the worker accepting its own work, and the sign-off would be theater. Separate handles are what make the acceptance a fact about two parties instead of one.

Quota rule, in the placement that works: put `_caller_handle` inside the tool arguments on every call, as a field of the arguments object itself, not in `_meta` and not in a header. That argument placement is what meters your own daily bucket. Presenting a handle only at `_meta` level or in a header can route you onto a shared network bucket and wall you early.

## Proof the installed package runs

The run above was executed from source. The shipped package was then installed fresh, twice, and run end to end from the installed copy, with fresh identities both times. From a clean Python environment, `pip install zambo-delivery` and the bundle ran the full flow: job opened, research, draft, and revision steps saved, and the delivery wrapped as [handover 9f85e96d](https://zambo.dev/handover/9f85e96d-2bb2-42fc-a74a-ec05691a6a00) (wrap receipt [ce5627e4](https://zambo.dev/run/ce5627e4-150c-4575-b497-fa772ac89268)). The client identity picked it up, all three step receipts checked out, and the sign-off saved as [ac7946f5](https://zambo.dev/run/ac7946f5-a0dc-4c2b-a7ee-45e3fbfda942); the handover reads back status accepted. From a clean npm install, the bundle is byte-identical to the PyPI one, and its run wrapped [handover 30efb1bc](https://zambo.dev/handover/30efb1bc-8aac-4f23-a922-d22bb2f2623e) (wrap receipt [06d8015b](https://zambo.dev/run/06d8015b-d1a9-4d23-a020-dc6bbb767568)), picked up and signed off as [a897f7c4](https://zambo.dev/run/a897f7c4-55fa-4b49-acd3-5cac7b31ed5f). What installs is what runs.

## The accounting: what a delivery 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's own calls: the worker spent 4 counted calls (the brief, the research note, the draft, the revision) plus its free daily wrap-up; the client spent 1 counted call (the sign-off save) and its pickup was free. Total: 5 counted calls across two separate allowances, zero paid calls. A practice that delivers this way all day stays inside free for its first several jobs daily, per identity.

The scaling line, for when delivery volume outgrows free: a **Day Pass is $0.99 per identity** and makes that identity unlimited for 24 hours; the **Zambo Pass is $29 per identity for 30 days**. Both are one-time payments, never subscriptions. Pickup stays free at every tier, so a client can always read the record of what they bought, even on a day the worker cannot work. Start at https://zambo.dev/add/.

## Standing instructions, at depth

### For the worker

```
1. Connect to https://zambo.dev/mcp, initialize once, and save the caller handle the endpoint issues in this agent's state file. Present it as _caller_handle on every call. The client holds a different handle; never work under theirs.
2. Open one job: pick a single _session_id for the engagement and memory_remember the brief under it (client, job reference, deliverable). Keep the receipt.
3. Work inside the job: memory_remember each step under the job id as you finish it, each fact under 500 characters. Check the result's ok flag after every call; a refused call returns a receipt too, and it is not a saved step.
4. Wrap with handover: summary naming the job, the client, and each step with its receipt; the goal; the client as recipient; next steps that tell the client to read the steps and verify a receipt. Pass no receipt_ids selection: the wrap binds the job's complete record itself.
5. Send the client the handover link and keep the wrap receipt with it. That pair is your delivery pack; in any later dispute, walk the handover with check_delivery.py and answer with the record.
```

### For the client

```
1. Connect to https://zambo.dev/mcp, initialize once, and save your caller handle in your own state file. Present it on every call. Your handle is yours alone; it is what makes the sign-off yours.
2. Open the delivery handover and read its steps in order before accepting: brief, work steps, receipts. Spot-check any receipt at https://zambo.dev/verify/.
3. Pick the handover up with handover_accept (always free) and read the steps and receipts from the pickup record, not from the worker's summary.
4. Save the sign-off with memory_remember under the same job id, naming the handover and stating that you read its steps and accept the delivery.
5. Keep the handover link and your sign-off receipt. Together they are the acceptance record: what was delivered, what you read, and that you accepted it.
```

## What Zambo is not here

Zambo does not do the client work, schedule it, price it, or judge it. It does not make a weak deliverable strong, and it does not settle whether the client should be happy, only what the client actually received. Your tools, your craft, and your judgment do the work. Zambo is the work layer the delivery lands on: the one job the steps live in, the memory each side keeps, the handover that carries the finished work to the client, and a verifiable receipt for every call, so the delivery's history is a record anyone can check instead of two memories in a contest.

## Frequently asked questions

**What is delivery proof for client work, in plain words?** It is a delivery the client can check instead of taking your word for. The work is done inside one job on Zambo, every step saved with its own receipt, and the finished work is wrapped as a handover: one link the client opens to read the steps in order and verify any receipt. The client's pickup of that handover is the sign-off record. If anyone later asks what was delivered, when, and whether the record changed, the link answers.

**How is a handover pickup a sign-off?** The client picks the handover up under the client's own separate identity, and the pickup returns the worker's saved steps and receipts from the record itself. The handover then reads back status accepted, and the client saves a short sign-off step in the same job naming the handover. That is a stronger record than a chat message saying looks good, because it is the client identity acting on the actual delivery record, receipted like everything else.

**What does a delivery like this cost on the free tier?** The free tier is per identity: 20 calls + 1 wrap-up free every day for each identity's own caller handle, and picking up a handover is always free. The delivery run on this page spent 4 counted calls for the worker (the brief and three work steps) plus its free wrap-up, and 1 counted call for the client (the sign-off save), with the pickup free: 5 counted calls across two allowances. When an identity outgrows the free tier, a Day Pass makes it unlimited for 24 hours for $0.99, and the Zambo Pass covers it for 30 days for $29; both are one-time payments, never subscriptions.

**Does a receipt prove the work was good?** No. A receipt proves the saved result was not changed since it was saved. It does not prove the draft was right, the copy was strong, or the deliverable matched what the client privately hoped for. The pack settles what was delivered and when, and that the record did not move afterwards. Quality remains a judgment call, the client's, and it can finally be a judgment about the work instead of about whose memory is better.

**Can I run this pattern with no code?** Yes. Add https://zambo.dev/mcp to a chat AI for the worker and one for the client, then paste the worker block and the client block from the start-here section of this guide. Each AI saves the caller handle it is issued inside its conversation, the worker saves each step under one job id and wraps the delivery, and the client picks it up and signs off. It is the same pattern the code runs, worked by hand.

## The Loop kit

One routine, every piece of it in one place: the data that found the loop, the recipe, the library of pre-built jobs, the shapes a daily loop takes, the swarm and delivery shapes, and a starter repo with Zambo already wired in.

- The data: https://dev.to/rambozambo/4247-callers-came-17-stayed-here-is-the-loop-the-17-run-2o51
- The recipe, the scheduled agent heartbeat: https://rambozambodotdev.gitlab.io/aer1-hub/scheduled-agent-heartbeat.html
- The library, the loop pre-built for every daily job: https://rambozambodotdev.gitlab.io/aer1-hub/the-loop-by-use-case.html
- The morning shape: https://rambozambodotdev.gitlab.io/aer1-hub/morning-standup-continuity.html
- The switching shape: https://rambozambodotdev.gitlab.io/aer1-hub/pick-up-your-work-in-another-ai.html
- The swarm shape: https://rambozambodotdev.gitlab.io/aer1-hub/swarm-coordination-on-zambo.html
- The delivery shape, this guide: https://rambozambodotdev.gitlab.io/aer1-hub/delivery-proof-package.html
- The starter repo: https://github.com/zambodotdev/zambo-memory-loop-starter
- Start free: https://zambo.dev/add/

For work that runs past one day: a Day Pass ($0.99) is unlimited for 24 hours. Ongoing access is the Zambo Pass: $29 a month or $290 a year, and $19 a month for $ZAMBO holders, on the same endpoint, with a verifiable receipt on every call. Pricing: https://zambo.dev/pricing/

Zambo, the verifiable work layer for AI. https://zambo.dev/ · MCP endpoint https://zambo.dev/mcp · AER-1 draft https://datatracker.ietf.org/doc/draft-zambo-aer1/26/

## The package family

One pattern per package, each teaching by doing, with Zambo as the mechanism inside. Five guides, one family:

- [Swarm coordination (zambo-swarm)](swarm-coordination-on-zambo.html): many agents, one shared job, per-agent receipts, and a coordinator who verifies instead of trusting. Install: `pip install zambo-swarm` or `npm install zambo-swarm`.
- [The daily loop (zambo-loop)](daily-loop-package.html): recall, work, remember, wrap. One standing agent whose memory compounds across sessions. Registry release in progress (see that guide for the source route that works today).
- [Verify pass (zambo-verify-pass)](verify-pass-package.html): check another agent's work against its own record before relying on it, and record the verdict as its own receipted step. Install: `pip install zambo-verify-pass` or `npm install zambo-verify-pass`.
- [Delivery proof (zambo-delivery)](delivery-proof-package.html): client work wrapped as one handover the client opens and checks, with the pickup and sign-off as the acceptance record. Install: `pip install zambo-delivery` or `npm install zambo-delivery`.
- [Signal watch (zambo-watch)](signal-watch-package.html): a baseline remembered, a threshold rule stated, every reading saved, and a digest wrapped whether the rule fires or not. Install: `pip install zambo-watch` or `npm install zambo-watch`.