Practical Patterns for Agent Memory
Stateless agents forget the user every turn. Real agents need memory — but the wrong kind makes them worse. Four patterns that hold up.
Memory in agents is not one thing. It is four different problems that look alike, and bolting a vector store onto all of them is how you get an agent that confidently remembers the wrong things.
The four memories
- 1Working memory — the current context window. Short-lived, expensive, manually curated.
- 2Episodic memory — what happened in this user's past turns. Summarised, scoped per user.
- 3Semantic memory — durable facts about the world or the user. Structured, queryable.
- 4Procedural memory — how to do recurring tasks. Stored as reusable prompts or tools.
Store less, retrieve better
The instinct is to remember everything. The right instinct is to remember almost nothing and retrieve precisely. A small, well-indexed semantic store beats a giant dump every time, because retrieval noise hurts more than missing data.
Summarise before you store
Never store raw transcripts. Summarise each turn into a fact before writing it to semantic memory — 'user is on the free plan' not the paragraph that established it. Raw transcripts make retrieval return the wrong slot.
// before storing a turn
fact = summarise_to_fact(turn)
if fact_is_new_and_stable(fact):
upsert(semantic_memory, fact, embedding)
Procedural memory is the cheapest win
If the agent does the same multi-step thing often, do not make it rediscover the steps each time. Save the proven prompt as a reusable procedure and call it by name. This is where most reliability gains hide.
Memory that is never retrieved is storage. Memory that returns the wrong thing is a bug. Most agent memory is one of those two.
