Memory

An agent that forgets your project every session is one you have to brief every session. Snaga keeps three separate kinds of memory, and it is worth knowing which is which, because they are written and forgotten differently.

Notes about your project — SNAGA.md

> /init

This creates SNAGA.md in your project. It is a plain Markdown file, checked in if you want it to be, and it is loaded into the system prompt every session.

Put in it what a new contributor would need and the code cannot tell them: conventions that differ from the language default, the reason a strange thing is strange, commands that are not guessable. Leave out what the code already says — a directory listing or a dependency list costs context every session and can be reconstructed by looking.

Manage it with /memory show and /memory update, or just edit the file.

Facts the agent stores as it works

Separately from SNAGA.md, the agent keeps a key-value store of durable facts, searchable full-text, persisted in .snaga/memory/snaga.db. Two things write to it.

The agent, deliberately. It has a memory tool with remember and recall actions, and uses it when something looks worth keeping.

A pass that runs on its own. Every five turns, one extra model call distils durable facts out of the recent conversation and stores them. It runs after your answer has already streamed, so it adds no latency to the reply you are reading. This only happens in the interactive CLI, and not under --fast.

At the start of each turn, relevant facts are queried and injected as a [MEMORY CONTEXT] block that expires after five rounds.

Making it forget

Stored facts are in .snaga/memory/snaga.db inside the project. Deleting the directory clears them. SNAGA.md is just a file — edit or delete it.

/clear resets the conversation, not memory: the current thread goes away, and what was stored stays stored. That is usually what you want, and occasionally a surprise.

What it does not remember

The conversation itself is not persistent memory. It is compacted when it grows too large, and compaction is lossy by design — see Context.

Sessions are recorded, though, and you can go back to one:

snaga --continue        # the most recent session here
snaga sessions list     # the ids
snaga --resume <id>     # a specific one

A resumed session appends to the same session rather than starting a new one.