How it works
One loop, running whether or not you're looking — listen, think, act, remember.
Everything else in these docs is a detail of one loop. A presence listens, thinks in a space of its own, optionally acts on Base, and remembers what mattered. The loop does not stop when you close the tab — it slows down.
The loop
The four moments map onto the four systems the rest of the docs cover:
| Moment | System | What happens |
|---|---|---|
| listen | session | Your message enters the 128k working window alongside recent turns and the salient memory the keywords pulled in. |
| think | route + space | The route reasons; it may run code in its space or ask the chain skill. |
| act | wallet | If it decides to move funds, the spend policy gates it — execute, or pause for your yes. |
| remember | memory | Keywords are extracted; repeats pin, one-offs start a 7-day timer. See Memory. |
Anatomy of a turn
When you send a message, in order:
- Assemble. Recent turns (verbatim) + memory recalled by the keywords in your message + standing preferences are composed into the working window.
- Reason. The route runs. It can call tools: the chain skill (read), wallet ops (write, policy-gated), and the shell in its space.
- Resolve. Tool results return; the route continues until it has an answer or a completed action.
- Reply & record. You get the reply; the compactor extracts keywords and updates memory asynchronously — it never blocks the reply.
You never resend history. The thread is server-side; the presence already has it. The API takes one message, not a transcript.
Between messages
The same loop runs without a prompt. A standing intent wakes the presence on a schedule in its space; it reads the chain, checks it against memory, and either acts within policy or messages you. This is the difference between a presence and a chatbot: the loop is not user-triggered, it is continuous.
# every wake-up, in its own space state = recall("Base positions", "thresholds") now = chain.read(state.watchlist) if moved(now, state) > state.threshold: notify(you) # or act, if policy allows remember("checked positions", keyword="routine")
Where state lives
Four stores, four lifetimes. Knowing which is which explains most of yuzu's behaviour:
| Store | Lifetime | Notes |
|---|---|---|
| Session window | this thread | Up to 128k tokens. Recent turns verbatim. Not where long-term truth lives. |
| Memory | days → forever | Up to 100k tokens. Subtractive; salience decides what stays. Survives route changes. |
| Space (disk) | persistent | Files, scripts, working state in its Linux box. Yours to reset. |
| Wallet | persistent | On Base. Balances and policy outlive everything above. |
Lifecycle
- Raise. Name + founding instruction. That instruction is written straight to pinned memory.
- Live. Conversation and standing intents accrete memory; salience prunes it continuously.
- Re-route. Change the model; identity, memory, wallet, and files are untouched.
- Reset a part. You can wipe the space, edit memory, or rotate the wallet independently — the presence persists through any one of them.
The mental model
Hold these four and the rest of the docs follow:
- The presence is the unit, not the session.
- Memory is subtractive — forgetting is a feature.
- Reading the chain is free; spending is policy-gated, always.
- The loop runs between messages, not only during them.