Memory
Save useful project knowledge in Markdown so future sessions can reuse it.
Clarvis memory keeps useful project knowledge in Markdown files: working commands, architecture decisions, recurring errors, and why a workaround was needed. You can read and edit those files yourself. The default storage does not need a vector database or embeddings.
Distinguish memory from sessions and context
- A session transcript is the durable record of what people and agents said and did.
- Model context is the bounded working set sent to one model call and may be compacted.
- Memory is curated knowledge extracted for reuse across runs in the same workspace.
Memory does not copy every conversation. Most runs need no update. Details live in MEMORY.md files, grouped under topic summaries. PROFILE.md is the project's top-level index.
<workspace>/.clarvis/memory/
├── PROFILE.md
└── build/
├── TOPIC.md
└── bun/
└── MEMORY.mdTurn memory on
Open /settings/memory, choose global or workspace scope, create the memory block, and select the model used to extract durable knowledge. Save the change for future runs. The session row lets you temporarily turn configured memory on or off without rewriting settings.
Memory needs an effective extraction model. It uses the memory-specific model when configured and otherwise the effective default model. If neither resolves, Clarvis keeps memory configured but warns that it cannot learn.
Follow how one run learns
At run start, Clarvis adds the bounded PROFILE.md summary to the agent's context. Agents with memory access can search and read deeper documents. The lead can update memory through the guarded memory tools; sub-agents receive read access but cannot independently grant themselves write authority.
After a run ends, Clarvis saves a background job to review the task, result, and a limited set of tool evidence. It updates memory only if there is something worth keeping. You can start your next task without waiting for this review.
Tell Clarvis what deserves a note
Add plain Markdown guidance in either or both locations:
| File | Scope | Share it? |
|---|---|---|
~/.clarvis/memory-policy.md | your preference everywhere | no |
<workspace>/.clarvis/memory-policy.md | this project's expectations | optionally commit it |
The two policies combine, global first. Write editorial guidance about what is useful, not a replacement wiki structure:
Record the exact command that fixed a build and explain why it worked.
Do not retain customer data, temporary credentials, or personal shell aliases.Policy edits apply to the next indexing pass without a restart.
Keep memory inspectable and safe
The default file backend lives inside the workspace's Clarvis data and remains directly readable as Markdown. Secrets are redacted from bounded run snapshots before indexing, but a memory policy is still important: do not instruct an agent to retain sensitive data that should not be part of the project's long-lived knowledge.
Clarvis can also use a configured MCP or plugin memory provider. The effective provider owns its storage and capabilities; a read-only provider is never sent an indexing write. Changing providers does not replay queued writes into a different backend.