("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.
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.