What belongs in AI memory, and what ruins it
Most memory systems fail on the write path, not the read path. They store the wrong things, and no error is ever raised.
The short answer: store corrections, decisions with their reasoning, stated preferences, failed approaches, and durable facts. Do not store task state, conversation narration, anything recomputable from files you already have, or anything you inferred rather than were told.
The test
Would someone picking this work up cold, months from now, be worse off without it?
That is the whole rule. It is deliberately about a future stranger rather than about you now, because everything feels worth keeping in the moment you learn it. The stranger test filters on durability instead of novelty.
The five worth keeping
Corrections
The highest-value kind and the rarest. They are easy to miss because they arrive mid-conversation as a passing remark — “no, we moved off that” — rather than as an instruction to remember. If you capture nothing else, capture these. An assistant repeating a mistake you already corrected is the most expensive failure in the whole system, in tokens and in trust.
Decisions, with the reasoning
Store the why, not just the what. The decision is usually recoverable from the code; the reason for it never is. “Moved to SQLite” is half a memory. “Moved to SQLite for the embedded-replica story; Postgres meant a network hop on every read” is a memory that survives the next person asking why.
Preferences
How you want things done. These never expire, because they are true by virtue of having been said rather than by describing a world that moves.
Approaches that failed
And why. Saves repeating them, and this is the category almost nobody records — failure feels like something to move past rather than something to write down.
Durable facts
A real path, a version constraint, a hardware limit, a deployment detail. The things you look up repeatedly and never quite memorise.
The four that ruin it
- Task state. What you are doing right now expires by itself. Storing it means retrieving it later as though it were still true.
- Narration. “We discussed the API” is not a memory. It has no content and it will match queries about the API forever, crowding out entries that actually say something.
- Anything recomputable. If it can be read from the files, reading the files is cheaper and always current. A stored copy is a second source of truth that will silently diverge.
- Inferences dressed as facts. The dangerous one. If you concluded it rather than being told it, either do not store it or mark it as inferred with lower confidence. A guess stored as a fact is indistinguishable from knowledge six months later.
Write it so it stands alone
Each entry should make sense with no conversational context. Watch for opening pronouns and relative dates — “he prefers this”, “changed today” — which are meaningless when read back cold. Rewriting at write time is cheap; later it is not, because by then you have forgotten what “this” referred to.
One idea per entry. Splitting is easy, and a compound memory matches queries about either half while fully answering neither.
Write during, not after
Capture when something durable surfaces and the context is fresh, not at the end when you have already started forgetting the reasoning. Then do a closing sweep for what you missed.
The structural problem is that every write depends on someone — or some model — choosing to record something they can easily forget exists. Durable knowledge evaporates by default, and no error is ever raised. That is worth designing against explicitly.
Then let it expire
Deciding what to store is half the job; deciding what stops being true is the other half. How to make AI memory actually work covers staleness windows and superseding. If you want the cost argument for any of this, it is in memory as a token strategy.
Common questions
How much should an AI assistant remember?
Less than you think. A store growing quickly with entries nobody ever retrieves is landfill, and it makes retrieval worse for everything else. Quality of what goes in beats quantity every time.
Should I store whole conversations?
No. Transcripts are mostly narration and task state, and they bury the few durable facts inside them. Extract the facts; discard the conversation.
What if I am not sure whether something is durable?
Store it with lower confidence and a short expiry window rather than not at all. An entry that ages out quietly costs little. A missing correction costs an hour.