> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ziro-agent.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Memory

> Three memory surfaces: long-term facts in the store, file-based project memory, and a per-thread scratchpad.

Ziro keeps three distinct kinds of state for you. **Long-term user memory** lives
in the store (SQLite in dev, PostgreSQL in prod), keyed
`("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.

<Note>
  This page is in progress. It will cover `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.
</Note>

<Columns cols={3}>
  <Card title="Flavours" icon="git-branch" href="/concepts/flavours">
    Why a flavour shares one memory store.
  </Card>

  <Card title="Architecture" icon="layers" href="/concepts/architecture">
    The store and checkpointer in the two runtime modes.
  </Card>

  <Card title="Commands" icon="terminal" href="/interfaces/commands">
    `/memory` and `/scratch`.
  </Card>
</Columns>