Day 35: Why agent memory is not one database
Why useful agent memory has to be separated, scoped, and governed.
"Just add memory to the agent" is like "just add furniture to the house." Which room, and for what?
The question sounds pedantic until you notice that the four kinds of agent memory are really four different data-lifecycle problems wearing one word.
Four memory types, four different retention problems
| Memory type | Stores | Lives for | Risk if unmanaged |
|---|---|---|---|
| Working | Current task state | Minutes | Context lost mid-task |
| Episodic | What happened in past runs | Days to months | Stale assumptions; a privacy surface |
| Semantic | Durable facts about user and domain | Indefinite, with corrections | Old facts treated as current truth |
| Procedural | Learned how-to, skills, workflows | Until the process changes | Automating a habit that is now wrong |
The question that separates asset from liability
Not "what should the agent remember": teams answer that one easily, usually with "everything."
The harder questions are the ones nobody schedules time for:
- Retention. How long does each class live, and what actually expires it? Episodic memory in particular grows without limit unless something removes it.
- Correction. When a stored fact turns out to be wrong, what updates it, and does the correction win at retrieval time, or does it simply sit alongside the original with equal weight? This is where a lot of "the agent keeps insisting" behaviour comes from.
- Access. Who and what can read each class. Episodic memory is the sharp one here: it records what users did, which makes it a privacy surface that arrived without a privacy review.
Remembering everything is not a feature
An agent whose memory only grows does not get smarter. It gets confidently out of date, and it does so gradually enough that nobody notices the transition.
Procedural memory is the most treacherous of the four for exactly this reason. It encodes how we do things here, and when the underlying process changes, the agent keeps executing the old one competently. The failure looks like correct behaviour, because it was correct, last quarter.
Where to start
Before reaching for a memory framework, answer the boring version in one table: what does this agent remember, for how long, who can read it, and what removes it.
Most teams discover while filling that in that they need far less memory than they assumed, and that two of the four categories they were planning to build have no use case behind them.
Closing thought
Agent memory is not one thing, and treating it as one store is how privacy, relevance, and deletion problems get created simultaneously and untangled slowly.
Day 35 of 60 Days of Production AI Systems.
Which of your agent's memory should be temporary, which durable, and which never stored at all?
Previous: Day 34: Why tool access is where AI becomes operational risk
Next: Day 36: Why reflection should change the next action
Day 35 of 60 · Agentic AI Foundations (chapter 6 of 10)
