An agent with memory finishes a session and writes what it learned. Do that for six months without a policy about what deserves writing, and the memory store holds forty thousand entries, most of them unremarkable, several of them contradicting each other, and a handful of them wrong in ways that now look authoritative.
Retrieval over that is worse than no memory at all, because the agent now confidently recalls things that are not true. Consolidation — the decision about what survives a session — is the part that determines whether memory helps.
What changed in 2026
- Memory became a production concern with real benchmarks. Evaluations for cross-session recall moved the discussion from demos to measurable trade-offs.
- The write policy got recognised as the hard part. Storage and retrieval are largely solved; deciding what to store is where systems succeed or fail.
- Supersession became standard. Explicit handling for newer information replacing older moved from an afterthought to a design requirement.
- Provenance spread into memory. Recording where a remembered fact came from, and whether it was verified, became part of the record rather than just the text.
Two kinds of memory
The distinction that organises everything else.
Episodic memory is what happened: this user asked about X on Tuesday, this run modified these files, this tool returned this error. Chronological, event-shaped, and useful for recall of specifics.
Semantic memory is what is true: this user prefers concise answers, this project uses this framework, this customer is on this plan. Durable, general, and useful for shaping behaviour.
|
Episodic |
Semantic |
| Content |
Events, with timestamps |
Facts and preferences |
| Volume |
Grows continuously |
Should stay bounded |
| Lifetime |
Often expires |
Persists until superseded |
| Retrieval |
By recency or similarity |
By relevance to the task |
| Failure if unmanaged |
Unbounded growth |
Accumulated contradictions |
Systems that conflate the two get the worst of both: an ever-growing log that the agent treats as a set of standing truths. Keeping them separate means episodic entries can expire on a schedule without touching durable facts, and semantic entries can be updated without rewriting history.
What deserves writing
The default should be nothing, with explicit criteria for promotion. A useful test: would this change how the agent behaves in a future session? Most of what happens in a session fails that.
Reasonable candidates: stated preferences, corrections the user made, stable facts about the environment, decisions with lasting consequence, and things the user explicitly asked to be remembered.
Poor candidates: intermediate reasoning, the content of documents already retrievable from their source, anything derivable on demand, and — most importantly — the agent's own inferences.
That last one causes the most damage. There is a large difference between "the user said they prefer TypeScript" and "the user seems to prefer TypeScript". The first is a verified fact. The second is a guess, and once written to memory it is indistinguishable from a fact and will be acted on as one indefinitely. This is exactly how context poisoning becomes permanent rather than session-scoped.
If inferences are stored at all, mark them as inferences and record what they were based on.
Supersession and contradiction
Memory without an update rule accumulates contradictions. The user preferred detailed answers in March and concise ones in July, and both entries sit there with equal weight.
Three mechanisms handle this.
Timestamp everything and prefer recent for facts that can change. Preferences, project state, and configuration all have this property.
Detect conflict on write. Before storing a fact, check whether an existing entry addresses the same subject. If so, update rather than append — and keep the old value only if history matters for that class of fact.
Expire episodic entries. Events lose value with age. A retention policy on the event log keeps volume bounded without touching semantic memory.
The alternative — retrieving both contradictory entries and letting the model decide — sounds appealing and works badly. The model has no basis for choosing, and it will often prefer whichever appears more prominently.
Common mistakes
- Writing everything by default. Retrieval quality falls as volume rises.
- Storing inferences as facts. Creates permanent, untraceable errors.
- No supersession. Contradictions accumulate and the agent becomes inconsistent.
- Merging episodic and semantic. Neither can be managed properly.
- No expiry on events. Unbounded growth, degrading retrieval.
- No provenance. A wrong memory cannot be traced to its origin.
- Building memory for single-session tasks. Complexity with nothing to persist.
FAQ
Should the agent decide what to remember, or should I?
Both, layered. Explicit user requests to remember something are unambiguous and should be honoured. Agent-initiated writes need constraints — a schema, a category, and a check against existing entries — rather than free-form storage of whatever it thought was interesting.
How is this different from RAG?
Retrieval reads from a corpus you curate; memory writes back what the agent learned. The retrieval mechanics overlap heavily, and the hard problem is different — RAG has no write path, and the write path is where memory systems fail. See AI agent memory.
Can users see and edit their agent's memory?
They should be able to. A memory store that shapes behaviour and cannot be inspected is a system nobody can correct, and a wrong entry is otherwise permanent. Inspection is also the cheapest debugging tool you will have.
How much memory is too much?
When retrieval starts returning irrelevant entries for well-formed queries, you are past it. Measure that the same way you measure any retrieval — see retrieval metrics.
Where to go next
For the broader memory picture, read AI agent memory. For the contamination that memory makes permanent, context poisoning, and for within-session context management, context compaction.