"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 typeStoresLives forRisk if unmanaged
WorkingCurrent task stateMinutesContext lost mid-task
EpisodicWhat happened in past runsDays to monthsStale assumptions; a privacy surface
SemanticDurable facts about user and domainIndefinite, with correctionsOld facts treated as current truth
ProceduralLearned how-to, skills, workflowsUntil the process changesAutomating 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?

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.