Memory Architecture: Types, Persistence, and Staleness#

TL;DR#

Persistent memory - what an agent carries across sessions, potentially forever - is a distinct architectural component with its own type taxonomy, its own dedicated evaluation benchmarks, and its own hard, named failure modes: knowing whether "this is the same user/project as before" (cross-session identity), and knowing whether a stored fact has gone stale (was true, no longer is) rather than merely old. It is related to but structurally different from retrieval over an external corpus (lesson 09) and from within-session compaction (lesson 10): memory decides what a system should durably remember about itself and its principals across the boundary between sessions, not what fits in one conversation right now.

The idea#

Every agent that runs more than once needs to answer a question retrieval and compaction don't: what, if anything, should survive the boundary between this session and the next one? A coding agent that forgets a codebase's naming conventions every morning, or a support agent that re-asks a returning customer for information given six sessions ago, is failing at memory, not at retrieval (the corpus it needs isn't external and pre-existing - it's the agent's own accumulating experience) and not at compaction (the problem isn't fitting the current conversation into a budget - the conversation is long over).

By 2025-2026 the field stopped treating "give the agent a database and let it write notes" as sufficient and started treating memory as a first-class architectural subsystem: it has an input problem (what gets written, when), a storage problem (how it's structured and typed), a retrieval problem (how the right memory gets surfaced later, which reuses machinery from lesson 09 but against a different, self-authored corpus), an update problem (what happens when new information contradicts old), and a garbage-collection problem (what gets forgotten, and when forgetting is itself the correct behavior). A 2026 survey (Huang et al., arXiv:2602.06052) frames this explicitly as five operations any memory system must implement: storing, retrieval, updating, compression, and forgetting - and notes the field has grown large enough (59 co-authors contributed to that single survey) that memory now supports dedicated conferences, benchmarks, and vendor products of its own.

How it works#

The memory-type taxonomy: cognitive-science terms, contested edges#

The dominant taxonomy in 2025-2026 agent-memory research borrows five categories from cognitive psychology, though not every source uses all five or draws the same boundary between them:

• Sensory memory - the raw, unprocessed input buffer. For text-based LLM agents this category is largely a formality carried over from human cognition rather than a distinct engineering concern; most agent-memory papers mention it for completeness and then move on, since an LLM's "sensory" input is just its immediate prompt.
• Working memory - the active context window: whatever is in the current conversation, the loaded files, the tool results from earlier in the session. This is what lessons 07-10 of this subject are actually about. Working memory is not persistent by definition - it's scoped to the current session or thread, which is exactly why compaction (lesson 10) operates on it and memory does not.
• Episodic memory - what the agent (or its user) did and when: session logs, past decisions and their outcomes, debugging traces, "last time we tried X and it failed because Y." Episodic memory is inherently temporal and event-shaped.
• Semantic memory (also called declarative or factual memory) - durable facts abstracted away from the specific episode that produced them: "the user's name is Priya," "this service's database is Postgres," "the team's code style uses snake_case." Semantic memory is what's left after you strip the "when and how I learned this" context off an episodic memory and keep only the conclusion.
• Procedural memory - how to do things: reusable skills, successful tool-call sequences, execution strategies that worked before and are worth reusing without re-deriving them. This is the category most often under-built in practice - most production memory systems in 2026 are still mostly semantic-memory stores (facts) with episodic logs bolted on, and comparatively few systematically capture "the successful procedure for X."

Where sources disagree. The old version of this lesson (before the 09/11 split) used an informal episodic/semantic/procedural three-way split without sensory or working memory. That three-way split is still common and not wrong, but the more complete and more current framing explicitly separates working memory (session-scoped, not persistent) from the three persistent categories - a distinction that matters precisely because this lesson is the one that isn't about working memory (lessons 07-10 already covered that ground). Separately, the same 2026 survey (Huang et al.) also proposes cutting the problem along two other axes that sit alongside the cognitive taxonomy rather than replacing it: substrate (memory stored in the model's own parameters via fine-tuning, versus memory stored in an external retrieval-augmented store) and subject (memory that's about the user - personalization - versus memory that's about the agent's own accumulated experience). A real system typically has to make choices along all three axes at once - e.g., "user preferences, stored as semantic memory, in an external store" is a different design point from "the agent's own successful debugging strategies, stored as procedural memory, in an external store."

Memory as an evaluated component: the current benchmarks#

Treating memory as a serious architectural component means it gets measured on its own, separately from the base model's raw capability. Three benchmarks are the current (2026) reference points, and they are not interchangeable - each stresses a different failure surface:

• LoCoMo (Maharana et al., arXiv:2402.17753, Feb 2024) - 50 synthetic-persona conversations averaging roughly 300 turns across up to 35 sessions, with question-answering (single-hop, multi-hop, temporal, open-domain), event summarization, and multimodal dialogue tasks layered on top. It was the benchmark that first made the recall gap visible at scale: human QA performance scores around F1 88, while contemporary LLM baselines (GPT-3.5/4-class) scored only around F1 37-42, with RAG-augmented variants only modestly better. LoCoMo mainly measures whether the right fact from earlier gets surfaced at all across a long, multi-session history.
• LongMemEval (Wu et al., arXiv:2410.10813, Oct 2024, ICLR 2025) - 500 curated questions embedded in scalable chat histories (roughly 115K tokens in the standard setting, up to 1.5M tokens in the larger one), explicitly designed to test five distinct abilities: information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention (knowing when the answer isn't in memory at all, rather than fabricating one). Commercial assistants and long-context LLMs showed roughly a 30-percentage-point accuracy drop on this benchmark relative to easier settings - meaning the gap LoCoMo exposed didn't close on its own as context windows grew. LongMemEval is the benchmark that most directly tests staleness-adjacent behavior, because "knowledge updates" specifically checks whether a system correctly overrides an earlier fact with a later, contradicting one, and "abstention" checks whether it invents an answer instead of admitting the memory doesn't have it.
• BEAM ("Beyond a Million Tokens"; Tavakoli et al., arXiv:2510.27246, ICLR 2026) - 100 procedurally generated, narratively coherent conversations scaling from 100K up to 10M tokens, with roughly 2,000 validated questions spanning ten distinct memory abilities, including contradiction resolution, event ordering, instruction-following across time, and preference tracking. BEAM's central finding is that even models with genuinely million-token context windows, with or without retrieval augmentation, degrade as the underlying conversation lengthens - directly undercutting the "just use a bigger context window instead of building memory" argument from lesson 09's retrieval discussion, but at the memory timescale (accumulated sessions) rather than the single-document timescale.

The practical takeaway for a staff-level reader: "our agent has memory" is not a single pass/fail property. A system can score well on LoCoMo-style recall (it finds the right old fact) while failing LongMemEval-style knowledge updates (it finds the old, now-wrong fact and states it confidently) or BEAM-style contradiction resolution (it holds two conflicting facts and doesn't notice). Picking a benchmark, or building an internal eval, requires knowing which of these failure surfaces you actually care about for your product.

Example (Aug 2026): Vendor leaderboards on BEAM change month to month - one 2026 memory-engine vendor reported roughly 77% at the 100K-token scale and 68% at 10M tokens, edging out an earlier leader that had reported around 64% at 10M tokens. Treat any specific number as a snapshot, not a durable fact - see landscape-snapshot for what's current, and re-check the benchmark's own leaderboard before citing a number in a design doc.

Cross-session identity: knowing it's the same principal#

A memory store is useless if the system can't reliably answer "whose memory is this, and is the entity asking right now the same one this memory is about?" This sounds trivial in a single-user, single-device toy setup and becomes a genuinely hard, named problem the moment real usage shows up: anonymous sessions before login, the same human on multiple devices, shared or delegated accounts, an agent acting on behalf of a team rather than one person, or a project (rather than a person) as the actual continuity anchor. The implicit assumption most memory systems start with - a stable user_id that every session can be keyed against - breaks under all of these, and resolving whether two interactions actually came from "the same" principal is, as of 2026, an open identity-resolution problem at the memory layer, not a solved plumbing detail. Getting it wrong is not a neutral failure: if identity resolution incorrectly collapses two different people onto one memory record, one person's private context (health details, salary, relationships the agent inferred from their messages) can surface inside a different person's session - a privacy failure, not just a quality one.

A related but distinct identity question is the agent's own continuity, not the user's. Menon (arXiv:2604.09588, Mar 2026) argues that when a long session's history overflows and gets summarized (lesson 10's compaction), an agent can suffer what the paper calls catastrophic forgetting of self - not just losing facts, but losing the coherent persona, stated commitments, and accumulated stance that made it recognizably "the same agent" across the compaction boundary. The paper's proposed fix - a "multi-anchor" architecture that stores identity-defining information (who this agent is, what it has committed to) as a structurally separate, harder-to-drop component from the general episodic/semantic log - is one specific design; the durable point independent of that specific paper is that cross-session continuity is a two-sided problem: is this the same user the memory is about, and is this still recognizably the same agent that wrote the memory in the first place.

Staleness: a fact that used to be true, not a fact that was never true#

The prior lesson-09-and-10 material already covered poisoning - a false claim entering context and persisting because nothing challenges it. Staleness is a different, equally real failure mode and deserves to be named separately: a stale memory is one that was true when it was written and is no longer true now, versus a poisoned memory, which was never true at all. "The user works at Acme Corp" might have been a correct, faithfully-recorded fact in March and become false in July when they changed jobs - nothing was ever written incorrectly; reality simply moved. A memory system that only guards against writing false things (validation, provenance-checking) does nothing to catch this, because the write was correct at the time. Guarding against staleness requires a different mechanism: either tracking when a fact was true and for how long it should be trusted, or actively detecting that a stored fact now contradicts something newer.

Three 2026 threads of work target this specifically: - TOKI (Wang, arXiv:2606.06240, Jun 2026) treats contradiction resolution in persistent agent memory as a concurrency-control problem, by analogy to database systems: when a new fact conflicts with a stored one, something has to decide which wins, and the paper's contribution is naming four heuristics already used in production systems - last-writer-wins, evidence-weighted merge, await-confirmation (hold both, ask), and per-rule custom policy - and pointing out that none of them, as commonly implemented, come with an explicit, checkable guarantee about what inconsistencies they can and can't produce. The paper's proposed fix is a bitemporal scheme: track both when a fact was true in the world and when the system learned it, so a superseded fact isn't deleted but is marked non-current and kept for audit rather than silently discarded. - STALE (Chao et al., 2026, per current literature surveys) is a benchmark built specifically to test whether an agent notices that a stored memory has gone stale and correctly resolves the conflict between the obsolete stored value and the current reality, rather than confidently repeating the old value or silently averaging the two. - A distinct but related failure, documented in "When Memory Updates but Behavior Does Not: Repairing Implicit Stale Dependencies in Personalized Agent Responses" (arXiv:2608.01619, 2026), is that a memory record can be correctly updated while the agent's downstream behavior keeps depending on the old value anyway - e.g., a cached inference, a previously-generated plan, or a routine derived from the old fact doesn't get invalidated just because the underlying memory record did. This means "update the memory record" and "the agent now behaves correctly" are not automatically the same event - a staleness fix at the storage layer doesn't guarantee a staleness fix at the behavior layer.

Worked example. A support agent's memory store has "customer is on the Pro plan, added March 2026." In August the customer downgrades to the Basic plan. If the write path only appends new facts without invalidating old ones, both statements now coexist - a poisoning-style validator wouldn't flag either one, since both were true when written. A staleness-aware design needs one of: (a) a TTL or explicit supersession so "Pro plan" is marked non-current the moment "Basic plan" is written for the same (customer, plan) key, or (b) a periodic re-validation pass that checks high-relevance facts against ground truth (the billing system) rather than trusting an old write indefinitely - the same "checkpoint against ground truth" discipline lesson 10 recommends for repeatedly-compacted sessions, applied here at the memory layer instead of the session layer.

How memory interacts with compaction#

Lesson 10 covers what survives within one long session when its context is compacted. This lesson covers what survives across sessions, in a persistent store. These are related decisions made by different parts of a system, on different criteria, and conflating them causes real bugs.

They are not the same selection problem. Compaction's job is: "what does this thread need to keep going, right now, to finish the task it's already doing?" Its scope is one task, and its summary is disposable once the task ends. Memory-writing's job is: "what will be useful to a future, different session that hasn't started yet, possibly about a different task?" Its scope is indefinite, and what it produces is meant to outlive the task that generated it. A detail can be essential to compaction and useless to memory (the exact stack trace from a bug fixed an hour ago - needed to finish today's task, irrelevant to any future session) or the reverse (a one-line user preference stated in passing, easy to compact away as "not load-bearing for finishing this task," but exactly the kind of fact a memory system should capture for every future session).

Where they should hook together in a well-designed system. The practical pattern is to run memory-extraction as its own pass, logically separate from (though often triggered near) a compaction event: before or during compaction, a dedicated step asks "of everything in this context, what's a durable candidate for the persistent store?" and writes those candidates out, independently of what compaction decides to keep or discard for the session's own continuation. Using the lesson-10 worked example (the ORM migration agent): compaction keeps "tests pass as of step 112" and discards the raw test output because the session still needs to know tests pass to keep working - but that fact has no business in persistent memory, since it says nothing about future sessions. The user's naming correction ("use snake_case_ids, corrected at step 38"), by contrast, is exactly what a memory-extraction pass should catch and write durably, so a different future session on this codebase doesn't require the user to correct it again. Note the two systems can reasonably disagree: compaction might discard the naming correction from the active context once it's been applied everywhere (no longer load-bearing for finishing this task), while memory still needs to have captured it earlier, because otherwise it never gets recorded at all once compaction drops it.

A compaction bug that's actually a memory bug. If a system only extracts to persistent memory from the compacted summary rather than from the full pre-compaction context, anything compaction already discarded as session-irrelevant is permanently unavailable to memory too, even if it would have been a great candidate for persistence. This is a common, easy-to-miss architecture mistake: it silently caps what memory can ever learn at what compaction happened to think was worth keeping for a different purpose.

Pros#

• A dedicated memory subsystem lets an agent avoid re-deriving or re-asking for the same context every session, compounding usefulness over time rather than resetting to zero at each session boundary.
• Typed memory (episodic/semantic/procedural, rather than one undifferentiated log) enables targeted retrieval and targeted invalidation - a semantic fact can be superseded without touching the episodic log of what happened, and vice versa.
• Treating memory as its own evaluated component (LoCoMo/LongMemEval/BEAM-style benchmarking) surfaces failure modes - stale-fact repetition, contradiction blindness - that would otherwise only show up as vague, hard-to-diagnose user complaints in production.

Cons#

• Every one of memory's five operations (store, retrieve, update, compress, forget) is a place a system can silently fail, and most failures are invisible until a user notices the agent confidently repeating something wrong - unlike a crash, a stale or poisoned memory produces plausible-looking, wrong output.
• Cross-session identity resolution and staleness detection are both open problems as of 2026, not solved plumbing - building a memory system means owning genuine, unsolved risk, not just wiring up a vector store.
• Persistent memory adds a real privacy and data-governance surface that session-scoped working memory doesn't have: data that outlives the session it was collected in needs retention policy, deletion capability, and access-control correctness (see the cross-session identity failure mode above), which is meaningfully more responsibility than a system that forgets everything at session end.

Alternatives#

• Stateless agent, re-derive everything each session. No persistent memory at all; every session starts cold and rebuilds whatever context it needs from source (the codebase, a document, the user re-stating preferences). Simpler and has zero staleness or cross-session-identity risk by construction, at the cost of real, repeated user friction and repeated token spend re-establishing what a memory-equipped agent would already know. Preferable for low-frequency, low-continuity interactions where the cost of never remembering is genuinely lower than the cost of building and governing a memory system.
• Fine-tuning as memory (parametric substrate). Bake durable facts or behaviors into model weights instead of an external store - this is the "substrate" axis from the taxonomy above. Avoids per-query retrieval cost and store maintenance, but inherits the same downsides lesson 09 named for fine-tuning over RAG: expensive to update, poor provenance, and a poor fit for anything that changes as often as user-specific facts typically do. Reasonable for durable, agent-wide procedural knowledge (a house coding style baked in for every user) rather than per-user or per-project semantic facts.
• Flat, untyped append-only log instead of a typed taxonomy. Simpler to build - just keep writing everything to one store - but loses the ability to invalidate or retrieve selectively by type, making both targeted staleness fixes and targeted retrieval harder as the log grows. Reasonable as a first pass at small scale, before the type distinctions actually start paying for themselves.

When to use it#

Build a persistent memory subsystem when an agent has recurring interactions with the same user, team, or codebase across sessions, and the cost of re-establishing context every time is measurable - in tokens, in latency, or in user frustration at repeating themselves. Invest specifically in staleness handling (supersession, TTLs, or periodic re-validation against ground truth) once any memory record has a realistic chance of becoming false over the system's operating timescale - which for most user-facing and project-facing facts is "eventually," not "rarely."

When NOT to use it#

Don't build persistent memory for genuinely one-shot or low-recurrence interactions, where the governance cost (retention policy, deletion, access control, staleness handling) exceeds any plausible benefit - a stateless design is not a lesser architecture there, it's the correct one. Don't treat a flat, untyped log as adequate once the system needs to answer "is this still true?" for individual facts - that question requires the kind of per-fact temporal tracking a plain append-only log doesn't give you for free. And don't assume a memory system that scores well on recall-oriented evaluation (can it find the old fact?) is safe to ship without also checking contradiction- and update-handling (does it know when the old fact it found is no longer correct?) - LongMemEval and BEAM exist specifically because those are different failure surfaces that don't move together.

Key takeaways / mental model#

Memory is a first-class agent architecture component, not a leftover write-a-note-to-a-database afterthought - it has its own type taxonomy (working, episodic, semantic, procedural, with sensory carried over from cognitive science mostly for completeness), its own dedicated benchmarks (LoCoMo for raw recall, LongMemEval for updates and abstention, BEAM for contradiction and scale), and its own named hard problems. Staleness is not the same problem as poisoning: poisoning is a fact that was never true; staleness is a fact that used to be true and no longer is, and catching it requires temporal tracking or re-validation, not just fact-checking at write time. Cross-session identity - both "is this the same user" and "is this still recognizably the same agent" across a compaction boundary - is an open problem, not solved plumbing, and getting it wrong has real privacy consequences. And memory-writing and compaction (lesson 10) are related but distinct selection decisions running on different criteria and different timescales: don't let a compaction pass silently become the only gate on what memory ever gets a chance to learn.

Self-check questions#

1. Explain, precisely, the difference between a stale memory and a poisoned one. Give a concrete example of each that would look identical in the memory store (i.e., both are just a stored fact) but require a different mechanism to catch.
2. A team's agent scores well on a LoCoMo-style internal recall eval but keeps confidently repeating a customer's old subscription tier after they've upgraded. Which benchmark's failure surface does this map to, and what's missing from their memory system that a pure-recall eval wouldn't have caught?
3. Why is "the same user_id" an insufficient foundation for cross-session identity in a real deployment? Name two concrete scenarios where it breaks, and what breaks (functionally, and separately, from a privacy standpoint) when identity resolution gets it wrong.
4. A long coding session gets compacted at step 150 (lesson 10). Design the boundary between what compaction keeps for the session's own continuation and what a separate memory-extraction pass should write durably for future sessions. Give one example of a fact that belongs in one but not the other, and one that arguably belongs in both.
5. Why does the paper introducing BEAM argue that a 10-million-token context window does not eliminate the need for a dedicated memory system? Connect this to lesson 09's RAG-vs-long-context discussion - is this the same argument at a different scale, or a genuinely different one?
6. Staff-level judgment call: your agent needs to decide, for a given fact, whether to store it with a TTL, with bitemporal supersession tracking, or with no staleness handling at all (trust it indefinitely). What property of the fact should drive that choice, and what's the cost of getting it wrong in each direction?

References#

• Huang et al., "A Survey of Agent Memory in the Second Half: Towards Self-Evolving and Long-Horizon Agents," arXiv:2602.06052 - https://arxiv.org/abs/2602.06052
• Wu et al., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory," arXiv:2410.10813 (ICLR 2025) - https://arxiv.org/abs/2410.10813
• Maharana et al., "Evaluating Very Long-Term Conversational Memory of LLM Agents" (LoCoMo), arXiv:2402.17753 - https://arxiv.org/abs/2402.17753
• Tavakoli et al., "Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs" (BEAM), arXiv:2510.27246 (ICLR 2026) - https://arxiv.org/pdf/2510.27246
• Wang, "TOKI: A Bitemporal Operator Algebra for Contradiction Resolution in LLM-Agent Persistent Memory," arXiv:2606.06240 - https://arxiv.org/pdf/2606.06240
• Menon, "Persistent Identity in AI Agents: A Multi-Anchor Architecture for Resilient Memory and Continuity," arXiv:2604.09588 - https://arxiv.org/abs/2604.09588
• "When Memory Updates but Behavior Does Not: Repairing Implicit Stale Dependencies in Personalized Agent Responses," arXiv:2608.01619 - https://arxiv.org/html/2608.01619
• Jiang et al., "Anatomy of Agentic Memory: Taxonomy and Empirical Analysis of Evaluation and System Limitations," arXiv:2602.19320 - https://arxiv.org/html/2602.19320v1