Agent Memory in Production: What to Store, What to Recompute, and What to Forget

Most teams building agent memory are building a database when what they actually need is a retention policy. The work that gets scheduled is a store, a schema, an embedding index, a retrieval call. The work that decides whether the agent gets better or worse over six months is a set of rules: what earns the right to be written, what gets read on a given turn, and what expires. The design question is not "what can we remember" but "what must survive a session, and what is cheaper to recompute than to store".

That reframing matters because the failure mode of a memory layer is not amnesia. It is confident recall of something no longer true. An agent that remembers nothing is obviously broken. An agent that takes a preference expressed once, in one narrow context, and applies it as a permanent belief is wrong in a way no error rate surfaces, and it gets worse as it accumulates. Memory is the only component of an agent that degrades with use unless someone designs for decay.

The state of the practice as of the week of September 14, 2026 is that the storage problem is solved and the policy problem is not. What teams lack is the vocabulary for which kind of memory they are building, and the rules governing each kind. This guide supplies both, in build order.

Key Takeaways

• Memory is four distinct systems, not one. Working context, episodic, semantic, and procedural memory have different lifetimes, write rules, and failure modes. Building them as one store causes most memory bugs.
• Promotion is the control point. A fact moves from "said once" to "true about the user" only on corroboration or explicit confirmation, and without provenance and a timestamp it cannot be audited, contradicted, or expired.
• Retrieve on intent, not on principle, and forget on a policy. Blanket injection spends context budget on irrelevance, while time to live by class, decay on contradiction, and a hard deletion path are product requirements rather than cleanup jobs.
• Storage is cheap and retrieval is not. The recurring cost is the embedding and retrieval work per turn plus the context tokens the memory occupies, which makes store-versus-recompute real arithmetic.
• A memory layer with no evaluation suite is untestable by construction. Replay suites with planted contradictions, staleness probes, and scoping canaries are the minimum, and a memory-disabled control arm is the only proof the layer helps.

What Agent Memory Actually Is

Agent memory is the set of mechanisms that carry information across a boundary the context window cannot cross. Everything inside a single run is context management. Everything that survives the end of a run, a compaction, or a switch between users is memory. That boundary is why "just use a bigger context window" never resolved the problem: a one million token window changes how much fits in a run, not what happens when the run ends. It also explains a common confusion, since one technology implements both sides. Summarization compacts a transcript inside a run and also produces the artifact written at the end of it. The mechanics are shared, the policies are not.

The Four Memory Classes

Working context is the transcript and scratchpad of the current run, bounded by the window and managed by compaction. It is not durable memory, but it is where memory pressure first becomes visible, because compaction is a lossy write that happens automatically and leaves no record of what it dropped.

Episodic memory is what happened in prior sessions, scoped to a user, an account, or a thread. It produces the continuity users actually notice: the agent knows the migration was attempted last Tuesday and failed on a permissions error. Episodes are append-only and timestamped, never edited in place, because events do not change retroactively. The characteristic problem is volume: they grow linearly forever, and retrieval quality falls as the pile grows.

Semantic memory is durable facts and preferences distilled from episodes: the user is on the platform team, the account runs Postgres. This layer goes wrong most often, because distillation is where a one-off becomes a permanent belief. "Use short output for this one" becomes "the user prefers short output", and then a truncated answer six weeks later when the user wanted the long version.

Procedural memory is learned routines and tool-use patterns: which sequence of calls completes an expense report here, which argument this API silently rejects, which approach failed last time. It converts exploration into recall, which is where the real efficiency gain sits, and where almost nobody is deliberate. Most teams accumulate it by accident, in a prompt file nobody owns.

The taxonomy earns its place diagnostically. An agent that forgets yesterday has an episodic problem. One insisting on something the user stopped wanting has a semantic promotion and expiry problem. One rediscovering the same workaround is missing a procedural layer. Teams treating memory as one system try one fix on all three.

Named implementations map onto these classes unevenly. Systems in the MemGPT and Letta line page explicitly between in-context and out-of-context storage; LangGraph separates thread-scoped checkpoints from a cross-thread store, the working-versus-episodic boundary expressed as an API; Mem0 and Zep focus on extraction and on representing when a fact was true rather than only that it was stated. Almost none ship an opinionated procedural layer, which is the gap worth building into.

Write Policy: What Earns Promotion

The write path is where a memory system is won or lost, because everything downstream inherits whatever it accepts. The default: episodes are written, facts are earned. An episode is a timestamped claim about an event, cheap and low risk, true even when what it describes changes. A semantic fact is an assertion about the present, and every one risks being applied out of context indefinitely.

Extraction should therefore require evidence beyond a single mention, through two mechanisms that compose. Corroboration promotes a candidate only once it appears in more than one episode, or is confirmed behaviorally by the user accepting output that depended on it. Explicit confirmation asks, in the flow of work, whether the agent should remember something. It is the cheapest correctness mechanism available and is underused because it feels like friction, when one question buys correctness on a fact that will shape hundreds of later turns.

Three fields are mandatory on every stored fact, and systems that omit them cannot be repaired later. Provenance records which episode or message the fact came from, which lets a wrong fact be traced, a poisoned one retracted, and a belief explained to the user who asks why the agent holds it. Timestamps record when the fact was asserted and when it was last confirmed, which are different values, and the second is what revalidation runs against. Scope records who the fact belongs to: user, account, organization, or global. Scope is a security boundary, not an organizing convenience. One further rule: write facts in a form that can be contradicted, because an unfalsifiable fact like "is detail-oriented" accumulates forever, with nothing able to refute it.

Read Policy: Retrieval on Intent, Not Injection

The instinctive read policy loads everything known about the user into the system prompt. It demonstrates well and fails at scale three ways: it spends context budget on irrelevance, it puts stale facts beside fresh ones with nothing to rank them, and it makes every turn costlier in proportion to customer tenure.

Memory retrieval deserves the same relevance discipline as any other retrieval, and most of the technique transfers from the guide to retrieval-augmented generation. Retrieve against the current turn's intent rather than the user's identity: a question about invoice formatting should pull formatting preferences and prior invoice episodes, not the whole profile. Then set a per-turn budget in tokens or item count and enforce it, so ranking happens deliberately rather than by accident of whatever the index returned.

The hard part of ranking is recency against authority. The most recent statement is not automatically the most authoritative, because a user working around a temporary constraint says things that should not outlive it. A workable ordering is confirmation status, then corroboration count, then recency as the tiebreaker, with one override: a direct contradiction in the current session wins for that session.

Label retrieved memory as recalled information carrying its timestamp rather than merging it into the instructions. A model told "the user said on August 2 that reports should be brief" behaves differently from one told "reports should be brief". The first can be overridden. The second is an instruction.

Cost discipline on the read path follows the guide to LLM caching strategies, and the interaction matters: memory changes on nearly every turn, so placing it before the stable system prompt destroys prefix caching for everything after it. Stable instructions first, retrieved memory last, is both a caching rule and a precedence rule.

Forgetting as a First-Class Feature

An agent that cannot forget gets measurably worse over months, and the mechanism is specific: stale facts accumulate while fresh ones stay roughly constant, so any fixed retrieval budget fills with a rising share of things that used to be true.

Time to live by class is the default. Episodes expire or compress into summaries on a schedule measured in weeks to months. Semantic facts get a revalidation interval rather than a hard expiry, after which they are demoted to candidates until reconfirmed by use or by asking. Procedural routines expire when the tool definition they were learned against changes, a dependency rule rather than a clock.

Decay on contradiction is the most important and least implemented. When a new statement contradicts a stored fact, the default should be to retire or demote the old one and record the contradiction with its source. Storing both without resolution produces the accumulation failure below.

Hard deletion is a privacy requirement and needs a real path: a user asking to be forgotten must produce deletion in the primary store, in every derived artifact, and in the embedding index. Derived artifacts are where this breaks, because a deleted fact survives inside last month's episode summary, a fine-tuning dataset, and a vector index nobody reindexed. The design rule is that derived artifacts carry their sources' identifiers so deletion cascades, and it belongs in the first version because retrofitting is expensive.

Consolidation is forgetting done well: compress many episodes into fewer, higher-value facts, archive the raw material, and run corroboration checks there, because it is the only moment the system sees across episodes.

The Failure Modes That Actually Bite

Contradiction accumulation. The user said Postgres in March and MySQL in August. Both are stored, both retrieve, and the model picks whichever ranks higher that turn. The symptom is intermittent inconsistency no single bad record explains. The fix is contradiction detection at write time rather than read time, plus a resolution policy that retires the loser and keeps the provenance of both.

Cross-scope leakage. One user's fact surfaces in another user's context, because the namespace was keyed on something that is not unique, a shared index was queried without a scope filter, or a global "organization preferences" bucket was written from one user's session. That is a data incident rather than a quality issue, and it is why scope belongs in the storage key rather than a filter applied after retrieval. A filter can be forgotten. A key cannot.

Memory poisoning. Content the agent processes carries assertions engineered to be extracted and stored, and once stored they influence every later session. This is the durable form of the attack class covered in the guide to prompt injection, and persistence is what makes it worse: a single-turn injection ends with the turn, a poisoned memory does not. Mitigations: untrusted content is never eligible for promotion, extraction runs over user statements rather than retrieved content, and provenance allows everything from a hostile source to be retracted at once.

Confident recall of an obsolete preference. The mildest-sounding failure and the most common. The agent applies a preference that was real, is recorded accurately, and no longer holds. Nothing is broken, which is why it survives every test that looks for broken things, and only a staleness policy catches it. The procedural equivalent is a learned routine referencing a tool argument removed two releases ago, which the agent keeps retrying because the routine is what it knows.

Evaluating a Memory Layer

A memory layer with no evaluation suite is untestable by construction: the behavior under test spans sessions, and single-turn evaluation cannot see across them. The suite that works is built from multi-session fixtures.

Replay suites with planted contradictions are the core. Build a fixture of several sessions in which a fact is stated, contradicted, then relied upon, and assert the agent uses the current value, varying the interval and the strength of the contradiction. This one class catches contradiction accumulation, bad ranking, and missing decay.

Staleness probes run the opposite direction: plant a fact, advance the clock past the revalidation interval, and assert the agent either reconfirms it or stops asserting it. That is impossible without clock control, which is reason enough to make the memory layer's notion of time injectable.

Scoping tests plant a canary fact in one scope and assert it never appears in another. Run them continuously, not at release time, because the consequence is a data incident rather than a quality regression. Alongside them, retrieval precision at the budget is the standing diagnostic: of the facts retrieved for a turn, how many were relevant?

The control arm is the test almost nobody runs and the only one that says whether the layer earns its cost: the same task suite with memory disabled. If quality does not move, the layer is decoration. All of it belongs in the same telemetry as the rest of the agent, wired the way the guide to agent observability describes, with memory reads and writes on the trajectory span rather than in a log nobody opens mid-incident.

The Cost Model: Store or Recompute

Storage is trivially cheap and is not the cost: a million facts of a few hundred bytes each is well under a gigabyte. The recurring cost is per turn, in embedding the query, running the retrieval, and paying for the tokens the memory occupies on every call of every session, forever. The question is never "can we afford to store this" but "is retrieving this every turn cheaper than deriving it when needed".

Take a profile summary, either stored as a maintained fact or recomputed from recent episodes on demand. Assume ten thousand active users, twenty turns each per week, and a retrieval injecting eight hundred tokens per turn: two hundred thousand turns and one hundred sixty million injected tokens weekly, before any output. Recomputing the summary might cost four thousand input tokens, but only on turns that need it. Below roughly one turn in five, recomputation wins on tokens alone, and the crossover shifts further once the stored version also has to be maintained and expired. The point is that this is arithmetic, and most teams never run it.

Two traps recur: embedding every write whether or not anything will search it semantically, and unbounded growth inflating the retrieval budget, because injected tokens grow with tenure while cost per turn is watched as an average.

The strategic dimension is covered in the analysis of the AI memory layer as the next lock-in: the properties that make memory valuable, that it compounds with use and does not port cleanly, make it the stickiest layer in the stack. A team owning its episode store and extraction pipeline is in a very different position from one whose accumulated context sits inside a vendor's memory feature.

Build Order for a Team Starting Now

1. Episodes first, with provenance and timestamps. A correctly scoped append-only log is the only component that cannot be added later, because episodes not captured are gone.
2. Retrieval over episodes, with a budget. Before any extraction, prove that retrieving prior sessions improves outcomes. This alone delivers most of the continuity users notice.
3. Extraction with a promotion rule. Semantic facts only on corroboration or explicit confirmation, and only with provenance, timestamp, and scope. Resist the version that promotes everything and filters later.
4. Contradiction handling and expiry. Detect contradictions at write time, retire losers, set revalidation intervals per class. Most teams defer this, and it decides whether the system degrades.
5. The evaluation suite. Multi-session replay fixtures, staleness probes, scoping canaries, and a memory-disabled control arm.
6. Procedural memory last, and deliberately. Version learned routines against the tool definitions they came from, promote on repeated success, expire on tool change. Built this way it is the highest-leverage layer; built by accident, it fails silently.

Throughout, every stored item needs an owner who can say what writes it, what reads it, and what deletes it. Any item whose third answer is "nothing" is a future bug with a delivery date.

Frequently Asked Questions

What is the difference between episodic and semantic memory in an AI agent?

Episodic memory records what happened: a timestamped account of a prior session, append-only and true regardless of what changes later. Semantic memory records what is true: a durable fact or preference distilled from episodes, revalidated or retired when it stops holding. Episodes are cheap to write and safe to keep. Facts need a promotion rule, because a fact is asserted as currently true every time it is retrieved.

Do I need a vector database for agent memory?

Not at the start, and often not at all. If memory is accessed by user, account, or recency, a relational or key-value store with an index is cheaper, simpler, and easier to scope securely. A vector store earns its place when semantic search over history is a genuine access pattern, meaning users ask questions whose answers sit in episodes sharing no keywords with the question. See the guide to when you need a vector database.

How long should an agent remember a user preference?

Give it a revalidation interval rather than an expiry. An explicitly confirmed preference can hold for months; one inferred from a single statement should stay a candidate and be demoted within weeks unless corroborated or used successfully. What matters is that some interval exists, because a preference with no expiry is a permanent belief formed from one sentence.

Can agent memory be poisoned?

Yes, and persistence is what makes it serious. If content the agent processes can influence what gets written, an attacker can plant an assertion that survives into every future session. Mitigations: make untrusted content ineligible for promotion, extract only from user statements rather than retrieved documents or tool output, and keep provenance so everything from a hostile source can be retracted at once.