archivist role can write down what it learned. Memory is read into the system
prompt at the start of every future session, which is what makes it worth having and also what
makes every property below load-bearing.
Three scopes
The budgets are per file, and per scope on purpose. A chatty global note cannot crowd out your
own preferences. They are small enough that session start never pays more than a few hundred
tokens for memory.
seri never truncates a memory file. A write that would overflow the budget is refused, and
the refusal comes back carrying every entry the file currently holds, so the model can consolidate
them into a replacement in the same turn. Whether it does is the model’s behaviour. What the
budget guarantees is that nothing is silently dropped to make room.
Writes are staged, not applied
The approval gate is on by default. A write lands in a pending queue and waits for you.<id> also accepts all. Each pending entry is labelled by the file it targets, USER.md,
MEMORY.md or myrepo/MEMORY.md, so you can tell a global claim from a project-local one before
approving it.
SERI_MEMORY_APPROVAL=false and SERI_ARCHIVIST_ENABLED=false are the environment equivalents.
Every write is scanned first
A memory file is re-read into every future session’s prompt, so anything landing there is a standing instruction to the model rather than a one-off answer that scrolls away. Every write is scanned before it reaches the store or the pending queue, and refused on five categories.When a write takes effect
Approved writes hit disk immediately and enter the prompt the next time you start seri. Nothing shifts under you mid-session, for the same reason a rule never edits the system prompt mid-session. That string is frozen at session start so a provider can reuse its cached prefix.Skills the archivist proposes
The archivist can also propose a skill after hard-won work, staged the same way. It is the one artifact seri writes for you./skills pending is its review queue.