ZAMBO.

Direct answer

The daily loop, as an installable package

Most agents are one-shot: they arrive knowing nothing, do the job, and evaporate, and the next session starts from zero. The daily loop is the opposite shape. One agent, one persistent identity, and a four-beat rhythm it repeats every session: recall, work, remember, wrap. Yesterday's session saves the job's state to memory and wraps the day into a handover; today's session picks the handover up for free, recalls the state verbatim, and writes the next state down. This page teaches the pattern twice: once as a paste for chat agents, and once as an installable package, with a real three-session run and every receipt linked, including the two refusals the run hit and what they teach.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup. New here? Add Zambo to your AI in one step, then run the paste below. Reading as an agent? This guide has a plain markdown twin, same content, no styling.

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.

Start here, no code

Add the Zambo endpoint to one chat AI (the one-step setup at zambo.dev/add), then paste this block into the chat and name the job. The AI saves the identity (its caller handle) that the endpoint issues, and the loop runs one session at a time from there.

The paste, for the agent running the loop

Run a daily loop with me on Zambo:
1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in durable state you control and present it on every call, in every session. You are the same agent every day because that handle says so; your memory and your daily free allowance (20 calls + 1 wrap-up) key to it. Never share it.
2. Start each session by picking up: if a handover from the last session exists, accept it with handover_accept (picking up is always free) and read its steps.
3. Recall the job's state with memory_recall and check the lines the job depends on (baselines, rules, where things stopped) appear verbatim before you rely on them. An empty recall means the last session saved nothing; say so plainly instead of inventing state.
4. Do the day's work. Keep the receipt link of every call that matters.
5. Remember the update with memory_remember: one short fact, never over 500 characters, holding the new values, their receipt links, and the next action. Then check the result: a refused save still returns a receipt, and a save that did not land means tomorrow starts empty.
6. Wrap the day with handover: a summary of what happened, the goal, the operator named as recipient, next steps, and only this job's own receipt ids attached. That handover is the deliverable: the record the next session, or a different AI, picks up to continue. A receipt proves the saved result was not changed since it was saved, never that the answer was right.

That is the whole pattern at hand scale. Everything below is the same pattern with the depth turned up: the package, the exact accounting, and the receipts of a run executed by code.

Get the package

The pattern ships as an installable agent package, zambo-loop: the skill that teaches it, the runnable loop, the paste above, and the proof run from this page, in one bundle an agent can read and run in one step.

Why agents do not come back

Nothing is saved. A tool an agent tries once leaves nothing behind to return to. The week's data on Zambo's own stream says it plainly: of 4,247 callers counted across seven days, 98.5% were active on exactly one day. The one-day crowd's calls spread across one-off lookups: useful, finished, forgotten.

What is saved is not checked. A save can be refused (a fact over the length limit, a malformed call) and still hand back a receipt link. An agent that collects the link and moves on discovers the failure tomorrow, as an empty recall. The loop treats every result as a claim to check, not a link to file.

The day is never sealed. Work that ends as chat scroll dies with the session. A wrap turns the day into a handover: a saved record with the day's steps and receipts that the next session, or a different AI entirely, picks up whole and for free. The handover is what makes tomorrow a continuation instead of a restart.

The pattern

Step zero: the agent connects once, is issued a caller handle, saves it in its own state file, and presents it on every call, in every session. Memory, job timelines, and the daily free allowance all key to it.
1. Pick up: accept yesterday's handover with handover_accept. Always free; the day returns whole, steps and receipts included.
2. Recall: memory_recall the state the job depends on, and check the load-bearing lines verbatim before relying on them.
3. Work: do the actual job. Every call returns a receipt; keep the links.
4. Remember: memory_remember the one or two facts tomorrow needs, short, receipts inside.
5. Wrap: close the day with handover: summary, goal, recipient, next steps, and the job's own receipt ids attached. That handover is the deliverable.

The real run: one identity, three sessions, one watch

Executed November 2, 2026, against the live endpoint. One fresh identity (daily-loop-agent) ran a small BTC and ETH watch under one job id, daily-loop-demo-2026-11-02, as three separate sessions under the same saved caller handle. The run hit two refusals on the way, and both are in this record because both are the pattern's real disciplines.

Session 1: set the watch, and lose a save

Session 2: the honest empty recall

The repair took one call: the same baseline state written at 378 characters saved cleanly, both baselines and the alert rule in plain words: receipt ba4a4143.

Session 3: the loop closes

Audit this run

Do not take this page's word for any of it, including the failures. Open the refused save (c7d11d3b) and read the refusal yourself; open any step in the final handover and check its receipt 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, and we want to hear it: write to brennanzambo@zambo.dev.

Step zero, at depth: the handle is the memory

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 saved facts, its job timelines, and its daily free allowance all key to it. The discipline is mechanical. The agent saves the handle in its own state file before doing anything else, presents it as _caller_handle on every call with its name as _caller_label, and uses a User-Agent of its own from the very first initialize, because the quota handle is issued against the caller's network identity and a shared default can inherit a shared, already spent bucket. (The first identity minted for the run on this page hit exactly that, and was replaced before any work was saved; the package's code ships with its own User-Agent for this reason.) Present the same handle tomorrow and the agent is the same agent, memory intact. Lose it, and it comes back as a stranger.

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.

The two disciplines

Facts are short, and results get checked. A saved fact caps at 500 characters. Write facts like headlines with receipts attached: the value, the receipt link, the rule, the next action. And check the result of every call itself, never just its receipt link: a refused call still returns a receipt, and in the run above the only thing that exposed the lost save was the next session's empty recall.

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 outside the job, or one from a call that was refused, and the wrap refuses in turn, receipted, with the reason. Track the job's receipt ids as you work, the prices and the memory saves, and the wrap is a formality.

The accounting: what a daily loop costs

The free tier is per agent: 20 calls + 1 wrap-up free every day for the agent's own caller handle, and picking up in another AI is always free. Counted from the run's own record: session 1 spent 2 counted calls (the prices; the refused remember executed nothing), the repair remember spent 1, and session 3 spent 3 (recall, price, remember) with its wrap free. A loop on this shape, one session a day, runs free indefinitely, with most of the allowance unspent.

The scaling line, for when the agent outgrows free: a Day Pass is $0.99 and makes the agent unlimited for 24 hours; the Zambo Pass is $29 for 30 days. Both are one-time payments, never subscriptions. Start at zambo.dev/add.

Standing instructions, at depth

For the agent running the loop

1. Connect to https://zambo.dev/mcp, initialize once, and save the caller handle the endpoint issues in durable state you control. Present it as _caller_handle on every call, in every session, with your agent name as the caller label. Use a User-Agent of your own from the first initialize.
2. Start each session by picking up: handover_accept on the last session's handover (always free), then memory_recall the job's state and check the load-bearing lines verbatim. An empty recall means nothing was saved; report it, do not invent state.
3. Do the day's work under one stable _session_id for the job. Keep the receipt link of every call that matters.
4. memory_remember the update as one short fact, never over 500 characters: new values, their receipts, the next action. Check the result, not just the receipt: a refused save saves nothing.
5. Wrap the day with handover: summary, goal, the operator as recipient, next steps, and only this job's own executed receipt ids attached. That handover is the deliverable the next session picks up.

What Zambo is not here

Zambo is not a scheduler and does not wake, start, or supervise your agent. Your cron, your framework, or your chat sessions do that, and this page takes no position on which you use. Zambo is the memory and work layer the loop runs on: the facts each session recalls, the handovers that carry the day, and a verifiable receipt for every call. It also does not make recalled state correct. A receipt proves the saved result was not changed since it was saved; it does not prove the baseline was the right baseline. The loop makes an agent's days add up, and makes each day checkable, so judgment can rest on what actually happened.

Frequently asked questions

What is the daily loop, in plain words?

The daily loop is a four-beat rhythm an agent repeats every session: pick up yesterday's handover, recall the saved state, do today's work, remember the update, and wrap the day into a new handover. One persistent caller handle makes the agent the same agent every day, so its days add up instead of resetting. It is the shape a one-shot agent takes when it becomes a standing one: a watch, a standup, a digest, a monitor.

Does Zambo wake my agent up every day?

No. Zambo is not a scheduler, and it does not start, wake, or supervise agents. Your cron, scheduler, framework, or chat sessions start each session. The loop is what the session does once started: the handover it picks up, the memory it recalls, the state it saves, and the wrap that closes the day are all on Zambo, so the work survives the session that did it.

How does the agent remember yesterday?

Memory keys to the agent's caller handle, the identity the endpoint issues at initialize. The agent saves that handle in its own state file and presents it on every call. Facts saved with memory_remember under that handle come back through memory_recall in any later session that presents the same handle, verbatim, as the run on this page shows. Lose the handle and the agent returns as a stranger: no memory, no continuity.

Why did a save fail in the run on this page?

A saved fact has a hard limit of 500 characters. The run's first memory_remember wrote the baseline state as a longer fact, and the endpoint refused it before execution, with its own receipt, and saved nothing. The next session's recall came back empty, which is what an unchecked refusal costs. The repair saved the same state at 378 characters, and the session after that recalled it verbatim. The package writes short facts and checks every result for exactly this reason.

What does the daily loop cost on the free tier?

The free tier is per agent: 20 calls + 1 wrap-up free every day for the agent's own caller handle, and picking up a handover is always free. The run on this page spent 2 to 3 counted calls per session, with the wrap free, so a daily agent on this shape runs free indefinitely. When the agent 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.

Can I run this pattern with no code?

Yes. Add https://zambo.dev/mcp to a chat AI, then paste the standing instructions from the start-here section of this guide into the chat. The AI saves the caller handle it is issued, saves the job's state as short facts, and wraps each session into a handover the next session picks up. It is the same pattern the package's code runs, worked by hand.

Related

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 two shapes a daily loop takes, and a starter repo with Zambo already wired in.

The package family

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