An agent with no memory beyond the current conversation is a stranger every time. It asks for information the user gave last week, re-explores approaches that already failed, and cannot learn anything from experience. Adding memory is obviously desirable and easy to do badly, because the naive implementation — store everything, retrieve by similarity — degrades quickly into a store full of contradictory fragments.
The design question is not how to store, but what to store and when to surface it.
What changed in 2026
- Memory types got separated. Distinguishing what happened from what is true, with different retrieval and lifetime policies, replaced treating all memory as one store.
- Selective writing became the norm. Extracting facts worth remembering, rather than persisting transcripts, emerged as the practice that keeps memory useful at scale.
- Correction and expiry got designed in. Handling superseded facts explicitly, rather than accumulating contradictions, became a recognized requirement.
- Memory evaluation appeared. Testing whether an agent actually recalls the right thing at the right moment became part of agent evaluation suites.
Memory types
| Type |
Contains |
Retrieval trigger |
Lifetime |
| Episodic |
Events, interactions, what was tried |
Similarity to the current situation |
Decays; older episodes matter less |
| Semantic |
Stable facts and preferences |
Relevance to the current task |
Long, until corrected |
| Procedural |
How to do a recurring task here |
Task type match |
Long, updated on failure |
| Working |
Current session state |
Always in context |
Session only |
Conflating episodic and semantic is the most common design error. That a user asked about pricing last Tuesday is an episode — mildly useful, decaying in relevance. That they prefer metric units is a stable fact that should be applied every time. Storing both in one similarity-searched pile means the preference surfaces only when the conversation happens to resemble the one where it was mentioned.
Writing selectively
The temptation is to persist everything and let retrieval sort it out. That produces a store where the useful items are buried among thousands of trivial ones, and similarity search returns whatever happens to match the current phrasing.
Extract instead. After a session, run a step that identifies what is worth remembering: stated preferences, decisions made, facts about the user's situation, approaches that failed. Store those as discrete entries with clear text, not as conversation excerpts. This costs one model call per session and makes everything downstream work better — the same structured-extraction principle behind context compression.
Handle corrections explicitly. When a user says something that contradicts a stored fact, the old entry must be updated or marked superseded rather than left to compete with the new one. An agent that holds two contradictory preferences will apply them inconsistently, which reads as unreliability.
Apply decay to episodic entries. Something from a year ago is usually less relevant than something from last week, and pure similarity ranking has no way to know that. This is the temporal problem covered in temporal RAG explained, applied to memory.
Give users visibility and control. A memory the user cannot inspect or delete is a privacy problem as well as a correctness one, and the settings expectations in personal AI privacy checklist apply directly.
Common mistakes
- Persisting transcripts as memory. Unsearchable and enormous.
- One store for all memory types. Preferences surface only by coincidence.
- No correction path. Contradictory facts applied inconsistently.
- No decay on episodes. Ancient interactions rank alongside recent ones.
- Injecting all memory into context. Fills the window and triggers the degradation in context rot.
- No user visibility. A privacy problem and a debugging obstacle.
FAQ
How much memory should be injected per turn?
Little. A handful of relevant entries, retrieved deliberately, rather than a dump. More memory in context is not more helpful.
Where should memory be stored?
A vector store for similarity retrieval works, and structured facts frequently belong in an ordinary database with keyed lookup. Many systems use both.
How do I evaluate memory quality?
Construct scenarios where the correct behaviour depends on recalling something from an earlier session, and score whether it happens.
Should memory be per user or shared?
Per user for preferences and personal facts, and organizational knowledge belongs in a retrieval corpus rather than in agent memory. Mixing them creates leakage risk across users.
Where to go next
For within-run context handling, read context compression. For agent architecture, planner-executor agents, and for privacy, personal AI privacy checklist.