Memory systems get built read-first: how do we retrieve the right fact at the right time? But retrieval quality is capped by what was stored, and the common failure is not a weak search. It is a store full of things that should never have been written.
Save everything and you have built a second context window with the same problem, only now it persists.
The three questions
- What is worth keeping? Durable facts and decisions, not the conversation that produced them. "Deploys go through the staging worker first" is worth keeping. "The user said thanks" is not.
- When is it written? At decision points and confirmed outcomes. Writing on every turn produces a log, and a log is not memory.
- When does it expire? The question nobody asks. A fact about a system that changed six months ago is worse than no fact, because it is retrievable and wrong.
Why expiry matters most
A memory store with no expiry rule accumulates contradictions. Two entries say different things about the same system, both retrieve, and the model picks one. That is context pollution with a longer fuse: sourced from your own memory system, and persisting across every session until someone notices.
Practical options, roughly in order of effort:
- Supersede rather than append. Writing a new fact should replace the old one about the same subject, not sit alongside it.
- Timestamp everything and surface the age at retrieval, so recency is visible to the model.
- Scope by project or task, so memory from one context cannot leak into an unrelated one.
- Review periodically. If the store is small enough to read, read it. Most are.
A useful default
Start stricter than feels right. Write only what you would be annoyed to explain twice, and only when it is confirmed rather than merely proposed. It is far easier to notice a missing memory than a wrong one, because a missing memory shows up as a question and a wrong one shows up as a confident mistake.
Related terms
Externalized state
Externalized state keeps the durable facts of a task in files rather than in the conversation, so the window holds pointers instead of being the record. It is what makes a long task survive a context that cannot.
Read definition →PatternValidatedScratchpad
A scratchpad is a place the model writes intermediate work it will read back later, rather than holding it in the answer. It separates thinking from output, and gives the working a home that is not the context window.
Read definition →PatternValidatedCheckpoint
A checkpoint is a deliberate save point holding enough state to resume a task from there. It turns a long run from something that either finishes or is lost into something that can be picked up.
Read definition →AntipatternProvenContext rot
Context rot is the gradual decay of a long session as stale, superseded, and irrelevant text accumulates in the window. Nothing breaks at any single step, which is why it is usually diagnosed as the model getting worse.
Read definition →