("memory", user_id, agent_id), or ("memory", user_id, flavour) when a
flavour is active, so every agent in a flavour shares one set of facts. The agent
writes to it with save_memory(...) and the relevant facts are injected into the
system prompt on each turn. Project memory is file-based instead: one durable
fact per Markdown file under ~/.ziro/projects/<workspace-key>/memory/, with
YAML frontmatter naming and describing it. Only a derived index rides in the
prompt, one line per fact giving its name and description; full bodies load on demand via
load_project_memory(name). Write to it with save_memory(..., scope="project").
The scratchpad is throwaway per-thread working space: the agent writes
tmp://draft.tex and the tmp:// prefix resolves to a temp directory scoped to
that thread, confined against path escapes, size-capped, and garbage-collected on
a TTL. On Linux and macOS that directory lives in <temp>/ziro-<uid>, readable only by
you; if someone else created that folder first (or it is a link, or other users can
open it), Ziro leaves it alone and uses a fresh private folder for that run. On Windows
it is %TEMP%\ziro, which is already per-user. On Linux and macOS, scratch left in the old shared
<temp>/ziro folder is not moved or cleaned by Ziro: a thread resumed after the
upgrade starts with an empty scratchpad, and your OS temp cleaner removes the old files.
This page is in progress. It will cover the
memory section of settings.yaml
(was memory_policy.yaml) in full, the worktree layer chain that lets a linked
git worktree inherit its main repo’s project memory, and the /memory and
/scratch commands. Scratchpad GC and quota (ttl_days, clear_on_resume,
max_scratch_bytes) are now a host resource in resources.scratch of a
layer-root settings.yaml; see Configuration.Flavours
Why a flavour shares one memory store.
Architecture
The store and checkpointer in the two runtime modes.
Commands
/memory and /scratch.