Dev.to AI ๐Ÿค– Ai ๐Ÿ‘ 0 ๐Ÿ“– 8 min read

One job, one link, zero arguments: a delivery your client checks step by step

Client work rarely blows up over the work. It blows up over memory: what exactly was sent, when it was sent, and whether the version being argued about today is the version that was delivered then. I have watched "I sent

Client work rarely blows up over the work. It blows up over memory: what exactly was sent, when it was sent, and whether the version being argued about today is the version that was delivered then. I have watched "I sent it Tuesday" lose to a client's different memory too many times, so I built the delivery shape that takes memory out of it, ran it end to end on Zambo, the work layer I run for AI agents, and packaged it so any agent can deliver the same way.

The shape, in plain words: the whole job lives inside one record. Every step is saved as you do it, each with a verifiable receipt. The finished work is wrapped as a handover, one link the client opens to read the steps in order and check any receipt. The client picks the handover up under their own identity, and that pickup is the sign-off. After that, "did you actually deliver that?" has a boring answer: the link.

Start with no code at all

If you deliver client work through a chat AI, run this version first. Add the Zambo endpoint (https://zambo.dev/mcp) to your AI and to a second chat acting as the client. The two-minute setup is at https://zambo.dev/add/. Paste this into your chat:

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.

And this into the client's chat:

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 after this section is the same pattern run by code, with the receipts to inspect, and the two refusals that taught me its rules.

The run

November 2, 2026. Two fresh identities, one worker and one client, each with its own caller handle, one shared job id. The job is a labeled sample, landing page copy for a fictional bakery client, job reference SAMPLE-2043, every fact invented for the sample and marked SAMPLE in the records themselves, so the shape can be inspected without anyone's real work on display.

The worker opened the job with the brief: https://zambo.dev/run/96186fb5-daa6-4175-98ca-9f4fab592ac6

Then the steps, saved inside the job as the work happened. Research note: https://zambo.dev/run/f4c4621a-da05-4bf2-a5c0-16c5aeba07fd. Draft v1: https://zambo.dev/run/ed36d719-70e3-4519-a9b5-3456a013e786. Revision v2, the delivered version: https://zambo.dev/run/de873f15-31ad-4c5f-a08f-b9827fc6d7c9

The worker wrapped the delivery into one handover addressed to the client: https://zambo.dev/handover/31715914-80eb-438d-b01b-d2307cc4800e

Open that link. Its step list is the brief, the research note, the draft, and the revision, in order, plus the wrap's own proof-loop check. The client picked the handover up, read all three step receipts from the pickup record itself, and saved its sign-off in the same job: https://zambo.dev/run/307e0707-0f54-48c0-a135-aa1745d1aac5. The handover now reads back status accepted. The wrap's own receipt is here: https://zambo.dev/run/7b0cd0bd-f3c6-4c85-882e-9149531c05f7

The story of this run is the client side. The client never read a summary and never took the worker's word. It opened one link, walked the steps in the order the work happened, and its acceptance attached to that record, not to a chat thread.

Two refusals taught the pattern its rules

A wrap holds only its own job's record. My first wrap attempt passed a hand-picked list of receipt ids, the steps I wanted included. It was refused on the spot, with its own receipt: https://zambo.dev/run/1d25e082-32c6-4677-b29d-9dfc08d57243. The endpoint's message: one or more requested receipts do not belong to this job, nothing has been published, retry with the complete receipt selection. A partial or foreign selection does not publish. The shipped pattern passes no selection at all; the wrap's proof loop binds the job's complete record itself.

A refused call still returns a receipt. My first research step ran past the endpoint's 500 character cap on saved facts and was refused before execution, receipted here: https://zambo.dev/run/22ef6c40-5944-426f-b1db-1383c28e5e17. Read that again, because it is the trap: the refusal looks like a save if all you collect is receipt links. An integration built that way ships a delivery with a hole exactly where the research belonged, and finds out during the dispute. The package's code keeps every fact under the cap and checks the result's ok flag after every call, stopping on a refusal instead of papering over it.

What a delivery costs

The free tier is per identity: 20 calls plus 1 wrap-up free every day for each identity's own caller handle, and picking up in another AI is always free. Counted from this run's own calls, the worker spent 4 counted calls (the brief and the three steps) plus its free wrap-up, and the client spent 1 counted call (the sign-off save) with a free pickup: 5 counted calls across two separate allowances for a complete, signed-off delivery. A practice delivering this way stays inside free for its first several jobs a day.

When volume outgrows free, the scaling line is per identity too: a Day Pass is $0.99 and makes that identity unlimited for 24 hours; the Zambo Pass is $29 for 30 days. One-time payments, never subscriptions. And pickup stays free at every tier, so a client can always read the record of what they bought.

Do not take my word for it

Pick any step in the delivery handover, 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. It does not prove the copy was good or the headline was right, and I am not claiming otherwise. If a receipt from this run ever fails to verify, that is news and I want to hear it.

The pattern ships as an installable agent package, zambo-delivery, with the skill, the runnable delivery code, a checker that walks any delivered handover and lists every receipt, and this run inside it: https://pypi.org/project/zambo-delivery/ and https://www.npmjs.com/package/zambo-delivery, source at https://github.com/zambodotdev/zambo-delivery-proof. The full guide, with the accounting and the standing instructions at depth, is here: https://rambozambodotdev.gitlab.io/aer1-hub/delivery-proof-package.html

Your tools still do the work. Zambo is where the work lands, gets remembered, gets handed over, and gets proven. That is the whole pitch, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

๐Ÿ“ฐ Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.

Share ๐• Twitter โœˆ Telegram โ†— Reddit ๐ŸŸง HN
โ† News ๐Ÿค– Ai ๐Ÿ  Home