How to make AI memory actually work
The failure mode of a memory system is not a full store. It is a store full of things that were true once.
The short answer: memory quality is decided by what you refuse to store, whether old facts can expire, and whether a correction can override an earlier belief. Storage capacity and embedding model matter far less than any of those.
The test for whether something belongs
Would someone picking this work up cold, months from now, be worse off without it?
If yes, store it. If it is task state, something recomputable from the files, or a narration of what just happened, it does not belong. You would be paying to embed noise and paying again later to evict it.
Most memory systems fail here first. They capture everything, and a store growing quickly with entries nobody ever retrieves is turning into landfill.
The five things worth keeping
- Corrections. Anything you told the assistant that it had wrong. Highest value and rarest, and easy to miss because they arrive mid-conversation as a passing remark.
- Decisions and their reasoning. The why matters more than the what — the what is usually recoverable from the code, the why never is.
- Preferences. How you want things done.
- Approaches that failed, and why. Saves repeating them.
- Durable facts. A real path, a version constraint, a hardware limit, a deployment detail.
One idea per memory
State each so it stands alone with no conversational context. “Prefers invoices sent on the 1st” is a memory. “We talked about invoices” is not.
Watch for entries leaning on context they will not have when read back: an opening pronoun, a relative date like “today”. Rewriting them at write time is cheap. Later it is not.
Old is not the same as wrong
The most damaging failure is a stale fact retrieved confidently. Not a missing memory — a present one that stopped being true.
Different kinds of knowledge decay at different rates, so a single expiry policy is wrong. A reasonable set of windows:
| Kind | Goes stale after | Why |
|---|---|---|
| Event | ~1 month | Describes a moment that has passed |
| Note | ~3 months | Observational, low durability |
| Fact | ~6 months | Describes a world that moves |
| Decision | ~1 year | Holds until revisited |
| Preference | Never | True by virtue of having been said |
| Correction | Never | Same — and too valuable to prune |
Stale entries should still surface, flagged, rather than disappear. Old is not the same as wrong. But an assistant relying on one should say so.
Supersede, do not delete
When a fact changes, replace it and keep the old version queryable. Deleting rewrites history silently and destroys your ability to answer “when did this change?”
Deletion is for what should never have been stored — a secret, personal data someone asked you to erase. Everything else is a supersede.
Not everything that matches is relevant
Pure vector similarity has a specific weakness: a confident, high-importance memory can score well against a query it has nothing to do with. Ranking only ever expresses how strongly something matches; it cannot express that the match itself is a mistake.
Two things fix most of it. Require more than one independent signal before an entry appears — semantic similarity and keyword match, rather than either alone. And check absolute quality, not just relative: if the best hit scores poorly on its own terms, say so rather than writing confident prose around a weak result.
Scope it
A namespace per project, plus one global scope for things true everywhere, prevents your work notes from surfacing in a personal question. It also keeps retrieval fast and results legible.
Where it should live
Plain Markdown files on your own disk, with the search index derived and rebuildable. This is not aesthetic preference — it means you can read your memory without the tool that wrote it, fix it in any editor, and leave whenever you want.
The trade-off is real: if it only lives locally, your assistant cannot reach it when the machine is off. That is what a cloud replica solves, and it is worth understanding what a replica means for privacy before enabling one.
This is how Varven is built, and the token economics of getting it right are in memory as a token strategy.
Common questions
What should an AI assistant remember about me?
Corrections, decisions and their reasoning, stated preferences, approaches that failed, and durable facts like paths and version constraints. Not conversation transcripts, not task state, not anything recomputable from files you already have.
Why does my AI keep forgetting corrections?
Usually because corrections are never written down. They arrive mid-sentence as an aside rather than as an instruction to remember, so nothing captures them. Treat a correction as the highest-priority thing to store, and exempt it from expiry and pruning.
Should AI memory ever be deleted?
Rarely. When a fact changes, supersede it and keep the old version queryable so you can answer when it changed. Reserve real deletion for content that should never have been stored.