DocsMemory
Memory
A session ends and its transcript stops mattering. The decisions in it don't: why you chose SQLite, which approach you already rejected, the convention every route follows, the root cause of that race condition. Memory is where those survive.
It is workspace-scoped, local-first, and retrieved by meaning rather than keyword. Nothing is sent anywhere by default — the database is a SQLite file in the workspace, and the default embedder runs on your machine.
Session activity
│
▼
Extraction an LLM pass picks out decisions, patterns, rejections
│
▼
Embedding content → vector, locally or via an API embedder
│
▼
Storage SQLite, in the workspace
│
▼
Retrieval semantic ∪ lexical, fused by rank
│
▼
Injection the relevant few are prepended to the system promptWhat gets remembered
Fragments are typed, and the type is what makes retrieval sharp — "what did we decide" and "what did we rule out" are different questions.
| Type | Captures | Example |
|---|---|---|
decision | A choice, and why | "Chose SQLite over Postgres because the product is local-first" |
rejection | An approach explicitly ruled out | "Rejected Redux — too much boilerplate for this app's state" |
pattern | A convention established | "All API routes follow /api/v1/:resource/:id" |
fix | A bug fix, with root cause | "Race condition in session cleanup, fixed by a mutex on DB writes" |
architecture | A structural decision | "Embeddings are stored as base64 Float32Arrays so they stay in SQLite" |
preference | How you want work done | "Prefers registry-derived values over magic numbers" |
convention | A project norm to follow | "Tests use node:test and node:assert, never vitest" |
context | A background fact | "Sole maintainer; this is the primary income source" |
onboarding | Orientation for a cold start | "Server tests need better-sqlite3 built first" |
What it is not
- Not chat history. A transcript is what was said; a fragment is what was concluded. Memory stores the second.
- Not a cache of your code. It stores knowledge about the code, and tracks when the code it referenced has moved on — see staleness.
- Never blocking. Extraction runs after a turn settles. If embedding fails, the session continues without memory and logs a warning. The same is true of team sync, which runs on its own in the background.
Next
- How memories are made — extraction, gating, staleness.
- Retrieval and the vector store — how the right fragments come back.
- Memory map and code graph — browsing what's stored, and the symbol graph beside it.
- Configuration and sharing — embedders, and git-syncing with your team.