# 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 guide 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.

- HTML version: https://rambozambodotdev.gitlab.io/aer1-hub/daily-loop-package.html
- Start free: https://zambo.dev/add/
- Endpoint: https://zambo.dev/mcp
- Verify any receipt: https://zambo.dev/verify/

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

## Start here, no code

Add the Zambo endpoint to one chat AI (the one-step setup at https://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.

- Registries: npm is live: `npm install zambo-loop` (https://www.npmjs.com/package/zambo-loop). The PyPI listing is on its way; until it lands, the pattern is runnable today from the starter repo and the template below.
- GitHub (template repo, use it as your starting point): https://github.com/zambodotdev/zambo-daily-loop
- The sibling pattern, swarm coordination: https://pypi.org/project/zambo-swarm/ and https://github.com/zambodotdev/zambo-swarm-coordination

## 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

- `live_price` BTC: $76,786.70, down 1.29 percent in 24 hours, at 20:46:29 UTC: https://zambo.dev/run/3ab3edf9-68c1-4419-b444-49853ddc7fca
- `live_price` ETH: $2,247.14, down 0.69 percent, at 20:46:32 UTC: https://zambo.dev/run/326f0be5-f1fe-432c-a67d-01e56105531b
- `memory_remember` the baseline state: **refused before execution**. The fact ran over the 500 character limit for a saved fact; the endpoint rejected it and issued the refusal its own receipt: https://zambo.dev/run/c7d11d3b-64da-4625-b246-42243674bf7c. Nothing was saved.

### Session 2: the honest empty recall

- `memory_recall` for the watch state returned status empty, count 0, because session 1's save had never landed: https://zambo.dev/run/4adc6ece-9458-4e19-af64-6e4587b1dbbc
- `live_price` BTC again: $76,848.93 at 20:46:52 UTC: https://zambo.dev/run/dc2f54b4-aaa0-460d-b823-f951724bb102. Its update, written inside the limit, saved: https://zambo.dev/run/43a95682-e2dc-4833-8dbe-cc43bd605670
- The wrap attempt: **refused**, because its receipt selection named the refused remember's receipt, which is not an executed step of this job. A wrap holds only its own job's receipts, and nothing was published: https://zambo.dev/run/5dad54f0-073d-4f1a-aecd-0d736d0d60c8

The repair took one call: the same baseline state written at 378 characters saved cleanly, both baselines and the alert rule in plain words: https://zambo.dev/run/ba4a4143-d6db-4a4f-9834-af5056abd08f

### Session 3: the loop closes

- `memory_recall` returned the baseline fact, and the check was mechanical: the strings for the BTC baseline ($76,786.70), the ETH baseline ($2,247.14), and the alert rule all appear in the recalled text verbatim, exactly as saved: https://zambo.dev/run/fd2d6820-cc7d-4474-995f-2b04ef707140
- `live_price` BTC: $76,875.00 at 20:49:54 UTC, a move of +0.115 percent from the baseline. Inside the 3 percent band: no alert: https://zambo.dev/run/e42b60ed-1dee-4360-bc4c-9b07ccb08250. The update saved: https://zambo.dev/run/1630f1f9-991e-40c1-a358-431c82dacae6
- The wrap, naming only the job's five executed steps: https://zambo.dev/handover/60db250a-bf2a-4c8c-86da-b2ec8b7e150c, or its JSON twin: https://zambo.dev/handover/60db250a-bf2a-4c8c-86da-b2ec8b7e150c.json. It lists exactly those 5 steps, in order. The wrap's own receipt is https://zambo.dev/run/307d76af-cd16-4c2a-bd06-3206f6821c3c

## Audit this run

Do not take this page's word for any of it, including the failures. Open the refused save (https://zambo.dev/run/c7d11d3b-64da-4625-b246-42243674bf7c) and read the refusal yourself; open any step in the final handover (https://zambo.dev/handover/60db250a-bf2a-4c8c-86da-b2ec8b7e150c) and check its receipt 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. 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 https://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 swarm shape: many agents, one shared job, per-agent receipts](swarm-coordination-on-zambo.html)
- [The loop by use case: one routine, pre-built for every daily job](the-loop-by-use-case.html)
- [The scheduled agent heartbeat: pick up free, work, wrap the proof](scheduled-agent-heartbeat.html)
- [The morning standup: what your agents did overnight, with receipts](morning-standup-continuity.html)
- [Start in one AI, pick the work up in another, free](pick-up-your-work-in-another-ai.html)
- [AI agent handover, the signature product](https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b)

## 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 data: 4,247 callers came, 17 stayed, and the loop the 17 run](https://dev.to/rambozambo/4247-callers-came-17-stayed-here-is-the-loop-the-17-run-2o51)
- [The recipe: the scheduled agent heartbeat](scheduled-agent-heartbeat.html)
- [The library: the loop pre-built for every daily job](the-loop-by-use-case.html)
- [The morning shape: the standup that reads what your agents did overnight](morning-standup-continuity.html)
- [The switching shape: start in one AI, pick the work up in another, free](pick-up-your-work-in-another-ai.html)
- [The swarm shape: many agents, one shared job, per-agent receipts](swarm-coordination-on-zambo.html)
- [The starter: zambo-memory-loop-starter, clone it and run the loop today](https://github.com/zambodotdev/zambo-memory-loop-starter)
- [Start free: add Zambo to your AI in two minutes](https://zambo.dev/add/)

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

Zambo, the verifiable work layer for AI. [zambo.dev](https://zambo.dev/) · [MCP endpoint](https://zambo.dev/mcp) · [Registry](https://rambozambodotdev.gitlab.io/registry.html) · [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. Install: `npm install zambo-loop` (PyPI listing on its way; the pattern also runs today from the starter repo).
- [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`.