Skip to main content
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.
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.

Flavours

Why a flavour shares one memory store.

Architecture

The store and checkpointer in the two runtime modes.

Commands

/memory and /scratch.