New here? Start this series at Day 31: Why agents need outcomes, boundaries, and stop conditions
- Day 31: Why agents need outcomes, boundaries, and stop conditions
- Day 32: Why agent behavior is a loop, not a single prompt
- Day 33: Why planning reduces wasted AI actions
- Day 34: Why tool access is where AI becomes operational risk
- Day 35: Why agent memory is not one database
- Day 36: Why reflection should change the next action
"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 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.
Which of your agent's memory should be temporary, which durable, and which never stored at all?
More on these topics
Comparison · · 1 min read
LangGraph vs the OpenAI Agents SDK
Two ways to write the same supervisor. Compared on control flow, tracing, provider coupling, testing and what each makes hard.
Checklist · · 24 checks
Working with Claude, practices that hold up
Prompting, agents and tools, Claude Code, evaluation and safety. The habits that make Claude-based systems reliable, as a checklist you can run against your own setup.
Architecture pattern · · 1 min read
Pattern: the outbox for agent actions
Agents that write to systems of record need the same transactional outbox that event-driven services use. This entry covers the shape and the trade-offs.
Discussion