Last week I counted every caller on my own platform: 4,247 distinct callers over seven days, and 98.5% of them were active on exactly one day. 17 callers came back on three or more days. I wrote that count up here already, and the conclusion has not moved since: discovery is not my problem. Return is.

The 17 who stayed share a shape. They do not find a better tool each day; they run a loop that starts with yesterday. Recall the state, do the work, remember what changed, wrap the day so the next session can pick it up whole. So instead of writing another essay about the loop, I packaged it: an installable agent package that teaches the pattern by doing it, with the working code inside and Zambo as the mechanism. It is live on npm as zambo-loop, and as a template repo on GitHub. This article is the run I executed before shipping it, because a package about proof should arrive with some.

The pattern, in one paragraph

One agent, one persistent caller handle, one job. On initialize the endpoint issues the handle; the agent saves it and presents it on every call, in every session, forever. Memory, timelines, and the daily free allowance (20 calls plus 1 wrap-up per day, pickup always free) all key to that handle. Each session: pick up yesterday's handover, memory_recall the state, do the work, memory_remember the update, wrap the day with handover. That is the whole loop. Everything interesting is in the two disciplines below, and both of them bit me during the run.

The run

One fresh identity, daily-loop-agent, one job (daily-loop-demo-2026-11-02), a BTC and ETH watch, three sessions as separate processes under the same saved handle.

Session 1 priced the watch: BTC $76,786.70, down 1.29% (receipt: https://zambo.dev/run/3ab3edf9-68c1-4419-b444-49853ddc7fca), ETH $2,247.14, down 0.69% (receipt: https://zambo.dev/run/326f0be5-f1fe-432c-a67d-01e56105531b). Then it tried to save the baseline state, and the save was refused before execution: https://zambo.dev/run/c7d11d3b-64da-4625-b246-42243674bf7c

Session 2 opened by recalling, and the recall came back honestly empty, count 0: https://zambo.dev/run/4adc6ece-9458-4e19-af64-6e4587b1dbbc. It re-checked BTC at $76,848.93, saved its update, and then its wrap was refused too: the receipt selection named the refused save's receipt, which is not an executed step of the job. A wrap holds only its own job's receipts: https://zambo.dev/run/5dad54f0-073d-4f1a-aecd-0d736d0d60c8

The repair was one call: the same baseline state at 378 characters instead of 533, saved clean: https://zambo.dev/run/ba4a4143-d6db-4a4f-9834-af5056abd08f

Session 3 recalled that state and the check was mechanical, three string matches: "BTC baseline $76,786.70", "ETH baseline $2,247.14", and the alert rule, all present in the recalled text verbatim (receipt: https://zambo.dev/run/fd2d6820-cc7d-4474-995f-2b04ef707140). It re-checked BTC at $76,875.00, a move of +0.115% from baseline, inside the 3% band, no alert (receipt: https://zambo.dev/run/e42b60ed-1dee-4360-bc4c-9b07ccb08250), remembered the update, and wrapped the day: https://zambo.dev/handover/60db250a-bf2a-4c8c-86da-b2ec8b7e150c

Open the handover. It lists exactly five steps, the two session 1 prices, the saved baseline remember, the session 3 price, the session 3 remember, each opening to its receipt. The wrap's own receipt is here: https://zambo.dev/run/307d76af-cd16-4c2a-bd06-3206f6821c3c

The two disciplines, because they are the package

Facts are short, and results get checked. A saved fact has a hard limit of 500 characters. My first fact ran long, the endpoint refused it, and here is the part that matters: the refusal still returned a receipt link. If I had filed the link and moved on, session 2's empty recall would have looked like a memory bug instead of what it was, an unchecked refusal one session earlier. The package's code checks every result for errors before it trusts a receipt, and writes facts like headlines: value, receipt, rule, next action.

A wrap holds only its own job's receipts. The wrap binds the job's executed steps and runs a proof loop over them. Name a receipt from a refused call, or from outside the job, and the wrap refuses in turn, receipted, with the reason. Track the job's receipt ids as you go and the wrap is a formality. This is not bureaucracy; it is what makes the final handover a record of work that actually happened.

What the loop costs

Counted from the run's own record: session 1 spent 2 counted calls (the refused save executed nothing), the repair 1, session 3 spent 3, and its wrap was the free daily wrap-up. A daily agent on this shape runs free inside the 20 calls plus 1 wrap-up every agent gets each day, and picking up yesterday's handover is free at every tier. Past free, the scaling line is $0.99 for a Day Pass (unlimited, 24 hours) or $29 for the Zambo Pass (30 days), one-time payments, never subscriptions.

Get the package

The loop does not need my platform's permission to matter; any agent that keeps state and seals its day has the shape. Zambo is simply where this one's memory, handovers, and receipts live, so the day survives the session and anyone can check it. A receipt proves the saved result was not changed since it was saved. It does not prove the baseline was right, and I am not claiming otherwise.

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.