Agent Memory Strategy Decision Tree

A Machine Learning Mastery article that reframes agent memory design around a single question: not "which memory system should this agent use," but "where should each category of information live." The core move is that memory is never one architectural choice. A support agent's current ticket, a customer's subscription tier, and their complaint history are three different kinds of information, and each wants a different kind of storage. You run the classification once per category, then combine the answers into an architecture.

Four memory layers

The framework leans on the cognitive-science split between four memory types, each defined by what it assumes about the information it holds:

• Working memory — everything relevant right now lives in the active conversation and a finite token budget. A conversation buffer, kept in bounds by trimming or summarization.
• Semantic memory — stable, reusable facts worth storing as a canonical representation instead of re-inferring or re-asking. User attributes (name, role, preferred language), domain knowledge (business rules, product specs), and knowledge distilled from repeated interactions.
• Episodic memory — the history of what happened, valuable on its own and not just as current state. Past decisions, complaints, transactions. Stored as a growing log.
• Procedural memory — recurring task shapes that should get faster or more reliable with repetition. Distilled routines, not raw transcripts.

Most production agents use more than one. A customer support agent keeps the ticket in working memory, the subscription tier in semantic memory, past complaints in episodic memory, and a learned refund-handling routine in procedural memory.

The five questions

Run these per category of information, in order:

1. Does it need to persist beyond the current turn? If it's self-contained (a one-off classification request, a throwaway tool output), no memory layer is needed — the context window is enough. If it carries forward, continue.
2. Does it need to survive beyond a single session? If within-session only (what's been asked, which tools were called), working memory suffices. If it must outlive the session (a returning customer's preferences, a multi-day task), continue.
3. Is it a stable fact or an evolving event? Stable facts go to semantic memory; evolving history goes to episodic memory. This is the question people skip — dumping everything durable into one store regardless of shape.
4. How will it be retrieved? Small bounded stores (a profile, a handful of facts) get read in full at session start. Large growing stores (interaction history, document corpus) need semantic or hybrid retrieval because reading everything becomes impractical. One agent often needs both patterns at once.
5. Does the agent need reusable procedures? If a task shape recurs and should improve with repetition, distill it into procedural memory layered on top of the existing semantic/episodic stores. One-off tasks skip this.

The combined per-category answers form a memory profile. A coding agent ends up with all four layers; a simple FAQ agent may need only working memory. Both are correct outcomes of the same process.

Wrong-layer failures

The article's most useful section is its pitfall table, which maps symptoms to the layer mismatch that causes them:

• Agent re-asks for something given this session → working memory trimmed too hard, or summarization dropped the detail. Fix the window, don't add long-term memory.
• Retrieval returns contradictory results → stable facts and evolving events mixed into one store. Split them: structured store for facts, separate log for events.
• Semantic memory overwritten with bad information → no validation or versioning at write time. This is the problem memory-conflict-detection addresses: gate the write, keep both versions visible, don't silently overwrite. The article cites Zep's temporal knowledge graph, where each fact carries a validity window so a superseded fact gets invalidated rather than left to contradict the newer one.
• Procedural memory never improves anything → the store holds raw replays instead of distilled lessons. Write the digested lesson, not the transcript.
• One store handling facts, history, and session state at once → nothing was classified. Run the tree per category.

How this connects to the rest of the memory cluster

The decision tree is the top-level map; the vault's other memory pages fill in the mechanics each branch implies.

Question 4's large-store branch is where hybrid-search lives — BM25 for exact terms plus embedding similarity for meaning. Question 3's split between facts and events, and the "overwritten with bad information" pitfall, is exactly memory-conflict-detection. The article treats episodic logs as append-and-prune; agent-memory-decay is a more principled version of the pruning — memories weaken on a half-life unless reinforced by retrieval, so stale entries fade instead of being deleted on a fixed schedule.

On the tooling side, the toolbox memory systems each stake out a position in this tree. hippo-memory implements three storage layers with decay and conflict detection by default — roughly working/semantic/episodic with the mechanics from the failure table built in. mempalace is a large episodic store answering Question 4 with verbatim history plus hierarchical retrieval (it reports 96.6% R@5 on LongMemEval). stash leans hardest on Question 5's distillation step: raw episodes get synthesized in the background into facts, relationships, and patterns, blurring the episodic-to-semantic/procedural boundary the tree draws as a hard line.

The article names external building blocks for specific branches: the OpenAI Agents SDK for session buffers (Q2), Anthropic's memory tool for small full-read stores (Q4 small), Google's Memory Bank and Mem0 for large searchable stores (Q4 large), and Zep for temporal knowledge graphs (Q3).

Caveat from the discussion

The framework is a taxonomy, not a validated result — it tells you where to put things, not how well any given placement performs. The one substantive HN comment makes the point that benchmarking memory systems is still the hard open problem: existing benchmarks like LoCoMo and LongMemEval don't cover all the use cases the article enumerates, so there's no clean way yet to measure whether a chosen architecture actually holds up in production.