Dlouhodobá paměť a kontext AI systémů

Long-Term Memory and Context Architecture for AI Systems

Evidence dossier — research snapshot: October 3, 2026

Executive summary and evidence frame

This dossier investigates the research question supplied in the research brief: how AI systems should retain, retrieve, update, summarize, scope, and forget information over time without allowing stale, irrelevant, duplicated, unsafe, or misleading context to accumulate. It treats storage, retrieval, context construction, reasoning, action, updating, and deletion as separate capabilities rather than collapsing them into a single concept called “memory.” 1

The central conclusion is that “memory” is not one subsystem. Modern systems use the term for at least four materially different things:

• Context management — deciding what information the model sees now.

• External knowledge retrieval — locating relevant material that remains authoritative elsewhere.

• persistent derived memory — storing information extracted or inferred from previous interactions for later reuse.

• state management — maintaining exact, mutable facts about an ongoing task, user, workflow, or environment.

These have different correctness requirements. A vector store holding conversation snippets is not equivalent to a workflow database. A summary is not equivalent to its source. A model context window is not persistent memory. Prompt caching is not semantic memory. A retrieved fact is not yet a correctly used fact. And an inference about a user should not silently acquire the authority of an explicit user statement.

The evidence through October 2026 points strongly toward hybrid architectures rather than a universal memory mechanism. Long-context models have improved substantially, but benchmark evidence continues to show position effects, distractor sensitivity, degradation as length and reasoning complexity increase, and a substantial gap between nominal context capacity and reliable context utilization. Lost in the Middle found large positional effects even in long-context models; RULER found that only about half of 17 tested long-context models maintained satisfactory performance at 32K tokens despite all advertising at least that context length. 2

At the same time, retrieval is not a universal replacement for long context. Decomposing information into retrievable fragments can destroy cross-document, narrative, temporal, or causal dependencies; 2026 work explicitly finds cases where decomposition-based RAG harms tasks with strong context dependence. 3 The relevant architectural question is therefore not “long context or RAG?” but which information should be preserved intact, which should be selectively retrieved, which belongs in structured state, and which genuinely deserves durable derived memory.

A second major conclusion is that memory accuracy is governed more by lifecycle integrity than by storage capacity alone. LongMemEval decomposes long-term memory into indexing, retrieval, and reading and shows substantial degradation in sustained interaction, including knowledge updates and temporal reasoning. More recent work isolates maintenance failures: increasing storage capacity does not necessarily cure failures to replace or supersede obsolete information. 4

A third conclusion is that derived memories should normally be treated as projections over evidence, not as replacements for evidence. Systems increasingly summarize, consolidate, graph, merge, and abstract past observations because this can reduce retrieval cost and noise; TiMem and RecMem report substantial efficiency gains from hierarchical and recurrent consolidation. But newer work such as Zero-Mem and E-mem attacks the opposite failure mode: generated summaries and graph transformations can omit qualifying details, fragment context, or turn interpretation into apparently factual state. 5

A fourth conclusion is that forgetting is an essential architectural operation, but “decay” and “deletion” are not synonyms. Recency weighting, TTLs, pruning, archival, and confidence decay affect retrieval eligibility. They do not necessarily erase the underlying record, embeddings, summaries, indexes, caches, or downstream derived artifacts. This distinction matters both technically and legally: for example, Article 17 of the EU GDPR creates a right to erasure in specified circumstances, subject to exceptions; reducing a memory’s retrieval score is not itself erasure. 6

Finally, persistence changes the security model. A one-turn malicious instruction disappears with the context unless something carries it forward. A poisoned memory can survive a session boundary and influence unrelated future tasks. Recent attacks and benchmarks have demonstrated precisely this transition from temporary prompt injection to persistent compromise. MemSecBench’s July 2026 preprint reports malicious memory persistence in 84.2% of cases across its 24 tested configurations and successful full write-to-execution attacks in 50.3%; other 2025–2026 work independently demonstrates persistent memory poisoning and delayed activation. These are new results and should not yet be read as universal rates, but the attack class itself is now well supported. 7

Evidence conventions used here. Peer-reviewed primary papers and standards receive the greatest weight; recent preprints are included because memory-agent research is moving faster than publication cycles but are identified as such. Provider documentation is used only for provider-specific capabilities. Architecture papers are distinguished from benchmarks, and benchmark gains are not treated as production evidence. Human cognitive-memory terminology is used only as functional analogy unless the source directly concerns cognition.

The evidence strength can be summarized as follows:

Finding	Evidence state
Nominal context length is not equivalent to reliable context use	Strong empirical support across multiple benchmarks. 2
Retrieval, reading/reasoning, and action are separable failure stages	Strong and improving support from LongMemEval, Mem2ActBench, MemoryArena and 2026 agent benchmarks. 4
RAG is universally superior to full context	Contradicted; outcome depends strongly on information locality and dependency structure. 3
Consolidation can reduce memory cost/noise	Supported conditionally, largely benchmark-specific. 5
Generated summaries should be trusted as equivalent to source evidence	Not supported; emerging work identifies lossy decontextualization and maintenance failures. 8
Forgetting/pruning can improve efficiency and sometimes accuracy	Conditional emerging evidence; no universal decay law is established. 9
Persistent memories create a distinct poisoning surface	Increasingly strong evidence, including peer-reviewed and benchmark work, although quantitative attack rates remain environment-specific. 10
One universal memory architecture is likely to dominate all agent types	Not supported by current evidence; workload-dependent results dominate recent evaluations. 11

Memory and context taxonomy and architecture map

The most useful first distinction is between where information exists and whether the model currently sees it. Conversation logs, databases, memory stores and knowledge bases can contain information without that information being in the current model context. Retrieval can locate information without the model using it properly. And even successful reasoning does not guarantee that an ensuing tool invocation reflects that reasoning correctly; Mem2ActBench was created specifically because traditional memory QA benchmarks do not test that final transition. 12

Mechanisms that should not be conflated

Mechanism	Persistence	Selection mechanism	Primary function	Commonly confused with
Model context window	None by itself	Application supplies tokens	Maximum model-visible sequence for a call	“Memory capacity.” It is a computational input limit, not durable storage. Long-context benchmarks show that usable capacity can be materially below nominal capacity. 13
Working context	Usually one inference/agent step	Orchestrator, model, truncation/compaction policy	Information actively available for current reasoning	The entire stored conversation. Only delivered material is working context.
Conversation history	Potentially durable	Replay, truncation, retrieval	Raw interaction record	“Memory”; it is evidence/history until selected into context. LongMemEval explicitly studies alternative history indexing granularities. 4
Session state	Session or checkpoint lifetime	Deterministic application logic	Current variables within an interaction	Semantic memory. It is often exact operational state.
Context compaction / summarization	Depends on implementation	Generative transformation	Reduce context size/noise	Retrieval or forgetting. A summary is a lossy representation, not merely fewer stored records. Emerging memory research explicitly identifies information-loss risks. 8
Prompt caching	Provider-defined cache lifetime	Prefix/cache-key match	Reuse computation for repeated prompt prefixes	Long-term semantic memory. Provider documentation describes cached model state such as reusable key/value computation; it does not perform relevance selection or factual reconciliation. 14
Lexical retrieval	External corpus persists	Term/statistical matching, e.g. BM25	Recover text with matching vocabulary/identifiers	Dense semantic retrieval. It often retains advantages for exact names, IDs and rare terminology.
Vector/dense retrieval	External index persists	Embedding similarity	Semantic candidate selection	“Understanding” or “memory use.” DPR demonstrated major gains over BM25 on its open-domain QA setting, but later benchmarks show retrieval quality remains domain-dependent. 15
Hybrid retrieval + reranking	External index persists	Sparse + dense candidate generation; learned/LLM reranker	Increase candidate robustness/precision	A distinct memory ontology. It is principally a selection architecture. Hybrid sparse–dense reranking has shown complementary gains in retrieval studies. 16
RAG	Corpus/index external to model	Retrieve, then inject into context	Ground generation in selected external material	Persistent personal memory. Original RAG combines parametric generation with retrieved non-parametric knowledge; the external corpus can remain independently updateable. 17
Structured state	Usually durable/checkpointed	Key/schema lookup	Exact mutable variables: status, IDs, counters, permissions, workflow phase	Natural-language semantic memory. Its advantage is determinism rather than semantic flexibility.
Source-of-truth system / external KB	Durable	Database/search/API query	Authoritative organizational or domain record	Memory extracted from that record. A derived memory should not silently outrank its source. Provenance standards explicitly model entities, derivations, activities and responsible agents. 18
User profile / preference memory	Cross-session	Explicit lookup/retrieval	Personalization	Identity truth. Preferences can be temporary, inferred, contradictory or scope-specific; recent work specifically targets preference updating because static profiles fail as preferences change. 19
Episodic memory	Usually durable	Similarity/time/entity retrieval	Store or reconstruct particular past interactions/events	Human episodic memory. For AI this is normally an engineered event record or textual trace, not evidence of a homologous cognitive mechanism.
Semantic memory	Usually durable	Entity/fact/topic retrieval	Decontextualized facts/generalized knowledge extracted from episodes	Authoritative knowledge. Its abstraction often removes evidential context.
Procedural memory / skills	Cross-task	Task similarity, skill selector	Reusable procedures, policies or successful action patterns	Factual memory. ReMe, for example, explicitly treats reusable experience as procedural memory and includes refinement/pruning. 20
Prospective memory	Until intention resolved	Trigger/time/event detection	Remember to perform a future intention	Merely recalling the past. 2026 prospective-memory evaluations show that delayed-intention execution remains a distinct and difficult capability. 21
Knowledge graph memory	Durable	Entity/relation/temporal traversal	Explicit relational and temporal structure	Source data. The graph usually contains extracted/derived statements and can inherit extraction errors. A-MEM and temporal-KG systems report benchmark gains, but they do not convert derived edges into authoritative facts. 22
Durable instructions	Cross-session/project/org	Scope/configuration hierarchy	Policy and behavioral constraints	User factual memory. Instructions describe what the agent should do, not necessarily what is true.
Organizational memory	Shared, durable	ACL- and scope-aware retrieval	Shared learned knowledge/history	Organizational source of truth. It may contain useful experience without being authoritative policy or record.

The vocabulary borrowed from cognitive science should therefore be interpreted cautiously. Human-memory research distinguishes episodic memories of events from semantic knowledge and prospective remembering of delayed intentions, but even cognitive science does not support completely independent, cleanly separable boxes; episodic and semantic systems interact substantially. 23 An AI system calling timestamped dialogue snippets “episodic memory” is making a functional analogy, not demonstrating a human-like episodic mechanism. Likewise, “procedural memory” is a useful label for reusable procedures but does not establish an analogue of biological skill learning.

Storage, retrieval, context and use form a pipeline

A useful decomposition is:

available evidence → stored representation → retrieved candidates → constructed context → model interpretation → decision → action

LongMemEval formalizes a closely related indexing–retrieval–reading decomposition. 4 Mem2ActBench extends the distinction by evaluating whether remembered material is actually translated into correct tool selection and grounded parameters; its 400 tool-use tasks were constructed from 2,029 sessions, with human evaluation finding 91.3% of tasks strongly memory-dependent. 12 MemoryArena goes further by coupling learning, memory and later decisions across interdependent multi-session tasks and finds that systems near saturation on conventional memory tests can perform poorly in the agentic setting. 11

This yields at least five independent failure classes:

Stage	Successful outcome	Example failure
Capture/store	Relevant evidence survives in appropriate form	Important preference never stored; malicious instruction stored instead
Retrieve	Correct evidence enters candidate set	Relevant record exists but similarity search misses it
Context construction	Correct subset/ordering reaches model	Evidence retrieved but truncated, buried, duplicated or overwhelmed by noise
Interpret/use	Model resolves relevance, time, scope and authority correctly	Correct historical fact retrieved but obsolete value chosen
Action	Reasoning becomes correct external behavior	Agent answers correctly but fills a tool argument with the stale ID

A successful storage-and-recall demonstration therefore proves considerably less than a successful memory architecture.

Architectural families

The major architectures solve different information-shape problems.

Architecture	Natural strength	Characteristic weakness	Evidence
Full long context	Preserves relationships and original wording; no retrieval miss if material fits and is effectively used	Positional degradation, distractors, token cost, weaker effective utilization than nominal window	Lost in the Middle; RULER; BABILong. 2
Trimmed recent context	Low latency; excellent for local conversational continuity	Catastrophic omission of distant dependencies	Long-term conversational benchmarks motivate external memory precisely because distant relevant evidence falls outside recency windows. 24
Summarized/compacted history	Lower token load; can remove repetition	Irrecoverable omission, compression bias, stale summaries	Systems exploiting consolidation report efficiency gains, while preservation-oriented work documents risks of destructive transformation. 5
RAG / selective retrieval	Scales beyond context; source material can remain independently updateable; retrieval is inspectable	Retrieval misses; fragmentation; relevant query may require unstated causal/temporal dependencies	Original RAG; LongMemEval; AMA-Bench. 17
Structured state	Exact values, updates, constraints, versioning and auditability	Requires schema/explicit state model; weak for fuzzy unstructured memories	Engineering/database pattern rather than a substitute for open-ended semantic retrieval. Bitemporal work formalizes separate valid and transaction times. 25
Persistent extracted memory	Cross-session continuity without replaying all history	Promotion errors, duplicates, contradictions, staleness, privacy/security burden	LongMemEval and recent memory architectures expose both potential gains and update/maintenance problems. 4
Knowledge graph / temporal graph	Multi-hop relational and temporal access	Extraction error, maintenance overhead, decontextualization	A-MEM/Zep-style work reports benchmark benefits; later evidence remains workload-dependent. 22
Hybrid	Allows different information classes to use different representations	Coordination, authority and invalidation become first-class problems	The diversity of benchmark results increasingly favors workload-specific combinations rather than a single substrate. 11

Workload changes the design space materially. Conversational assistants primarily face preference, continuity and personal-scope problems. Analytical systems depend more heavily on attributable source documents and reproducibility. Coding agents mix repository truth, current task state, tool output and reusable procedures. Business-process agents often require exact workflow state that cannot safely be approximated by embedding similarity. Long-running autonomous agents additionally need prospective intentions, checkpoints and learning from prior actions. Recent agent benchmarks increasingly test these differences instead of treating all memory as conversational recall. 12

Memory lifecycle, source of truth, promotion, update and forgetting

A durable memory architecture has a lifecycle, not merely a write API.

Every arrow is a potential failure boundary.

Capture can overcollect private or irrelevant content. Classification can assign a memory to the wrong user, project or type. Validation can mistake a model-generated interpretation for evidence. Promotion can turn a joke or temporary state into a lasting profile. Indexing can discard useful temporal/contextual signals. Retrieval can miss evidence or surface poison. Context assembly can bury a correct record among distractors. Use can misread validity or authority. Update can leave old and new values simultaneously active. Consolidation can erase exceptions. Expiration can leave stale derived indexes reachable. Deletion can remove the primary record while leaving its summary or embedding behind.

A source-of-truth model

The most important architectural separation is epistemic authority versus retrieval usefulness. An easily retrieved summary is not thereby more authoritative than the database row from which it was synthesized.

W3C PROV provides a useful general foundation: provenance describes entities, activities, agents and derivation relationships so that the origin and transformation of information can be inspected. 18 Bitemporal database work adds another useful distinction: valid time describes when something is true in the modeled world, whereas transaction/recording time describes when the system stored or learned it. 25 That difference is directly applicable to AI memory: “the user moved on July 1” and “the assistant learned this on September 2” are not the same timestamp.

An evidence-based authority model is therefore better represented as layers:

Layer	Example	Appropriate authority	Overwrite semantics
Authoritative source data	CRM status, repository contents, policy database, signed document	Highest within its defined domain	Changed through the source’s own version/ownership process
Explicit user-owned assertion	“My preferred airport is Prague”; “I no longer eat meat”	Strong for the user’s own current preferences/circumstances	Later explicit statements can supersede earlier statements in the same scope
Raw interaction/event evidence	Exact message, tool result, source snapshot	Evidence that an event/message occurred	Ideally immutable or versioned; corrections should create new provenance rather than rewrite history invisibly
Extracted normalized fact	preferred_airport=PRG extracted from a message	Derived	May be superseded, but should retain pointer to evidence
Retrieved external material	Search result, document excerpt	Authority inherited from source, not retrieval score	Should not override stronger source merely because similarity is high
Consolidated summary	“User prefers central-European departures”	Derived projection	Recompute/invalidate when its inputs change; should not replace underlying evidence
Inferred preference / model interpretation	“User probably prefers morning flights”	Low unless confirmed	Explicit contradictory evidence should dominate; often suitable for expiry
Episodic trace	“On March 4 we discussed moving to Berlin”	Strong that interaction occurred, weak that every proposition inside it is true	Preserve provenance and speaker role
Operational task state	invoice_status=awaiting_approval	Authoritative for the active workflow if owned by its state machine	Deterministic state-transition rules should govern it

The ordering is not a universal global hierarchy. A user cannot necessarily override an organization’s regulatory policy, and a CRM should not be authoritative over a user’s private dietary preference. Authority is always predicate- and scope-specific.

A robust memory item therefore needs more than {text, embedding}. The research on provenance, temporal databases, memory updates and poisoning collectively supports recording some representation of source/evidence, subject and scope, ownership, creation/observation time, validity interval where known, version or supersession relationships, trust/source class, access permissions, retention status and derivation links. 18

Confidence is useful but insufficient. A high-confidence model inference should not outrank an explicit authoritative record merely because its scalar confidence is 0.97.

Promotion into durable memory

The decision to convert transient input into persistent memory is where many future errors are created. Existing research systems use combinations of salience, recency, frequency, LLM judgment, semantic novelty, reflection and consolidation. Generative Agents, for example, scores and retrieves stored observations and creates higher-level reflections; its evaluation concerns believable simulated-agent behavior, not authoritative fact management. 26 MemoryBank explicitly incorporates an Ebbinghaus-inspired forgetting mechanism, an example of borrowing a human-memory metaphor as an engineering heuristic rather than demonstrating that the human forgetting curve is optimal for AI. 27

The promotion mechanisms have different failure profiles:

Promotion signal	Advantage	Failure mode
Explicit request to remember	Strong intentional evidence	User may be ambiguous; persistence/scope may still be unclear
Deterministic schema/rule	Reproducible, auditable	Brittle; misses semantically important exceptions
Frequency/repetition	Simple evidence of recurring relevance	Repeated misinformation or injected content becomes stronger
Recency	Tracks current situation	Overweights temporary circumstances
Model-rated importance/salience	Flexible	Non-determinism, misinterpretation and prompt-injection susceptibility
Repeated independent observation	Can increase evidential confidence	Repeated copies of one bad source are not independent evidence
User confirmation	Stronger basis for inferred preferences	Interaction cost; confirmation itself must be scoped
Task outcome	Useful for procedural learning	A coincidentally successful or malicious action can be reinforced
Human review	High-assurance path	High cost and low throughput

No evaluated strategy establishes a universally optimal promotion policy. This is an important unresolved area: memory research is much richer in retrieval algorithms than in calibrated write decisions.

Sensitive data adds another asymmetry. A useful retrieval system can always fetch information later from an authorized source; once sensitive information has been unnecessarily promoted into several derived memories, summaries and indexes, removal becomes harder. Persistence therefore has an option-value cost that raw retrieval does not.

Updating, contradiction and staleness

LongMemEval explicitly tests knowledge updates and temporal reasoning and reports substantial degradation over sustained histories. 4 Preference-update work in 2026 similarly treats evolving preference state as its own problem rather than assuming that ordinary retrieval resolves contradictions automatically. 19

Recent work also questions whether “more memory” solves stale-state problems. The 2026 Supersede preprint isolates current-value maintenance and reports cases where bounded self-maintained memory deteriorates as conversation length increases, while allocating more memory capacity does not recover the loss. The paper’s environment is narrower than a production agent and should not be generalized numerically, but it provides evidence that maintenance logic can be a bottleneck independent of storage size. 28

Several distinct conflict types need different resolution semantics:

Replacement. “My office is now in Berlin, not Prague.” The old value can remain historical evidence while the new value becomes the current valid value.

Scope conflict. “For work travel I prefer trains; for family travel I prefer driving.” Both are simultaneously valid.

Authority conflict. A remembered model inference conflicts with an explicit user statement. This is not a symmetric contradiction: the explicit statement has stronger authority over a user-owned preference.

Temporal conflict. A 2025 company policy conflicts with its 2026 replacement. Version/validity is needed; embedding similarity alone cannot establish which is current.

Source disagreement. Two independent external documents disagree. Both may need to remain visible pending adjudication.

Interpretive conflict. Two summaries drawn from the same evidence disagree. Neither should silently overwrite the source.

This is where deterministic state machinery can be superior to generic “LLM memory.” A recent 2026 preprint examining deterministic freshness logic finds that simple timestamp/serial-number selection can work well for narrowly defined current-value cases, but it does not dominate model-based reasoning across all update tasks. 29 The disagreement is informative: freshness can be mechanically determined where the domain supplies version semantics, but semantic contradictions often cannot.

Forgetting, decay and deletion

Forgetting has at least six distinct forms:

Retrieval decay reduces an item’s score with time or disuse.

TTL expiration makes an item ineligible for ordinary retrieval after a defined time.

Invalidation marks it obsolete because a newer event supersedes it.

Archival removes it from active working memory while retaining historical evidence.

Replacement changes the current projection while retaining historical versions.

Deletion/erasure removes data itself, potentially including dependent representations.

These operations should not be conflated. Recent memory systems experiment with utility-driven pruning and strategic forgetting, and some report improved benchmark efficiency or relevance. 9 The evidence is nevertheless too young and benchmark-dependent to establish a universal forgetting curve.

Forgetting can improve relevance by suppressing obsolete temporary preferences, accuracy by removing superseded facts from candidate sets, efficiency by shrinking retrieval/index burden, privacy by limiting persistence, and security by eliminating compromised records. But it can destroy continuity when old information remains genuinely useful, particularly for episodic history, long-running projects, recurring constraints or delayed intentions.

A critical implication is that unused ≠ useless. Prospective memory is an obvious counterexample: an intention might be intentionally unused for months and then become critical at one future trigger. PM-Bench’s 2026 preprint finds prospective-memory execution difficult even in simulated multi-day environments, reinforcing that value cannot be estimated solely from recent retrieval frequency. 21

And deletion has stricter semantics than decay. In jurisdictions where an erasure obligation applies, the relevant question becomes whether personal information survives in raw memories, embeddings, graph edges, generated summaries, caches, backups or downstream derived state. GDPR Article 17 is one concrete legal example, though the exact obligation is jurisdiction- and circumstance-dependent and includes statutory exceptions. 6

Personal, organizational and security boundaries

Personalization is a special case of uncertain state

Personalization is often presented as the clearest justification for long-term memory, but it is also where epistemic mistakes become particularly visible.

A useful taxonomy separates:

Personal information	Example	Stability expectation
Explicit durable preference	“Always use metric units”	Relatively durable until revoked
Explicit scoped preference	“For this project, write in English”	Scope-bound
Temporary circumstance	“I am in Tokyo this week”	Short-lived
Observed behavior	User selected aisle seats three times	Evidence, not necessarily a preference
Inferred preference	“Probably prefers aisle seats”	Low authority and revisable
Identity datum	Name, account, organization	Requires identity/scope discipline
Sensitive datum	Health, finances, intimate or protected-category information	Higher privacy and access-control burden
Hard constraint	Allergy, contractual restriction	Often high consequence but must still be sourced/current

The most damaging personalization error is often not forgetting but overremembering an interpretation. Repeatedly tailoring future behavior to an old inference can create an anchoring loop: the system acts on an assumption, the user accommodates the system, and the resulting behavior appears to confirm the original assumption. Preference-update research exists partly because static memory does not handle evolving preference state well. 19

Personalized memory can therefore create stale profiles, inappropriate personalization and self-reinforcing filters even when retrieval is technically correct. Those risks are conceptually different from raw recall error.

Personal, project and organizational scopes are not interchangeable

An AI system can simultaneously operate over:

• one user’s private history;

• a project’s shared context;

• a customer’s records;

• a team’s working knowledge;

• organization-wide policy;

• globally applicable system instructions.

The crucial distinction is not simply where the record is stored but who owns it, who can read it, where it may be reused and which scope is allowed to influence which action.

For example, a fact learned in a private employee conversation should not automatically become team memory. A customer-specific instruction should not become a global organizational skill. A project-specific coding convention should not silently override repository-level policy outside that project. A global assistant behavior instruction should not be represented as a “memory” learned from an individual user.

This makes namespace and permission boundaries part of memory semantics rather than only database administration. Cross-user and cross-project leakage can occur at indexing, retrieval, summarization and consolidation: even if the raw store is tenant-separated, a shared summary or learned procedural artifact can inadvertently combine information from multiple scopes.

The organizational source of truth is also usually not the AI’s memory store. A CRM, policy repository, ticketing system, financial ledger, code repository or document-management system may own authoritative state. The AI memory can hold references, extracted projections and usage history without acquiring ownership of the truth represented by those systems. This follows directly from provenance and versioning principles rather than from any single LLM architecture. 18

Persistence changes the security threat model

Memory systems introduce a write-side trust boundary absent from ordinary retrieval-only systems. An attacker no longer needs the malicious instruction to remain in today’s context if they can convince the agent to memorialize it.

MemoryGraft demonstrated poisoned experience records that can be retrieved later and alter an agent’s behavior. 30 Hidden in Memory, a 2026 preprint, studies “sleeper” poisoning in which malicious content causes fabricated persistent memories that activate in later interactions. 31 A broader 2026 security analysis identifies multiple write channels and attack classes and concludes that agents with more aggressive memory write/retrieval behavior can become more exploitable. 32

Peer-reviewed BackdoorAgent work at ACL 2026 demonstrates persistent triggers across agent stages and reports especially strong persistence through memory-based attack paths in its evaluated environments. 10 MemSecBench then evaluates poisoning as an explicit Write → Execute → Forget/Repair lifecycle rather than merely asking whether an injected string was stored; across its 24 configurations, it reports an 84.2% malicious-memory persistence rate and 50.3% successful full write-to-execution chain. These figures are specific to the benchmark and configurations, but the evaluation design is significant because it measures downstream consequence and repair. 7

The resulting attack catalogue includes:

Memory-specific attack	Mechanism	Why persistence changes impact
Persistent prompt injection	Untrusted instruction gets written as durable memory	Survives context/session reset
Memory poisoning	False fact, preference or procedure inserted	Future unrelated queries can retrieve it
Context poisoning	Retrieved malicious source enters active prompt	Can influence current reasoning even without persistence
Compromised consolidation	Poison changes a generated summary/reflection	One malicious event can contaminate a higher-level representation
Procedural poisoning	Bad action sequence becomes a reusable “skill”	Attack propagates to later similar tasks
Privilege escalation via memory	Record from higher-privilege context becomes reachable in lower-privilege task	Converts a scope error into durable capability leakage
Cross-user/project leakage	Incorrect namespace or shared derived representation	Exposure can recur across many queries
Poisoned knowledge base	Malicious external document consistently ranks highly	RAG repeatedly reinjects adversarial text
Deletion evasion	Primary poisoned memory removed but summary/index survives	Attack can reactivate through derivatives

Persistence therefore increases both duration and fan-out. A transient injection has to win again each time; a successful persistent injection can convert one compromise into a future input source.

An important research implication is that provenance is security metadata as well as epistemic metadata. “This statement came from an authenticated policy service” and “this statement was inferred by a model after reading an untrusted webpage” cannot safely occupy identical memory records. The same applies to write authority: content that a model may read is not necessarily content it should be permitted to promote into trusted persistent state. Recent poisoning results strongly support separating these capabilities. 32

Evidence on long context, retrieval, state and persistent memory

Long context is larger than it is reliable

Lost in the Middle established an influential finding: moving relevant information within an otherwise identical long input can materially change model performance, with evidence near the beginning or end often used more reliably than evidence in the middle. 2

RULER expanded evaluation beyond simple needle retrieval to multiple needles, multi-hop tracing and aggregation. Across 17 models, near-perfect performance on simple needle tests did not translate into stable performance as context length and task complexity grew; only roughly half maintained satisfactory performance at 32K despite nominal support of at least 32K. 13

BABILong similarly reports that then-current models often effectively use only a fraction of their available context as reasoning complexity grows, while LongGenBench shows that long-context retrieval success does not guarantee stable long-form generation. 33 A 2026 literary long-context benchmark found that tested frontier models were not stable beyond 64K on complex narrative/storyworld tasks, again showing that “accepts N tokens” and “reliably reasons across N tokens” are different properties. 34

Current provider documentation nevertheless shows that context ceilings themselves continue to expand into very large ranges, including million-token-class contexts. 35 That development weakens the old argument that retrieval is mandatory simply because text cannot fit. It does not eliminate the remaining arguments for retrieval: freshness, permissions, observability, selective relevance, cost, source attribution and updateability.

Conversely, long context has an intrinsic advantage when information is strongly interdependent. 2026 research on document decomposition finds that RAG-like decomposition can hurt when understanding requires preserving contextual dependencies that fragmentation destroys. 3 The correct implication is therefore conditional:

Long context becomes more attractive as information dependency rises and total evidence fits within reliably usable context; selective retrieval becomes more attractive as information sparsity, corpus size, update rate and access-control complexity rise.

Retrieval is a selection mechanism, not a truth mechanism

The original RAG architecture combines a parametric model with retrieved non-parametric evidence, providing a way to refresh and inspect external knowledge without retraining model weights. 17 Dense Passage Retrieval demonstrated that learned dense representations could significantly outperform a strong BM25 baseline on the open-domain QA datasets evaluated in that work. 15 Later evaluations show that this result should not be universalized: exact terms, rare identifiers and domain vocabulary continue to make lexical retrieval valuable, and hybrid sparse+dense systems can exploit complementary signals. 16

Reranking adds another stage: broad, high-recall retrieval first, more expensive precision-oriented selection second. This improves candidate ordering but does not solve underlying provenance or freshness. An obsolete document can be semantically perfect and rank first.

LongMemEval demonstrates that retrieval query formulation, storage granularity and reading strategy all affect final memory performance. 4 AMA-Bench argues that similarity retrieval can omit causal and objective details from long agent trajectories and reports gains from a causality-graph plus tool-augmented retrieval architecture on its benchmark. 36 Because AMA-Bench is a 2026 preprint and its architecture is evaluated primarily on its own benchmark, its absolute architectural conclusion remains provisional; the diagnostic point—that similarity alone can miss causal dependencies—is stronger.

Structured state solves a different class of problem

Consider three remembered propositions:

“The user once mentioned Paris.”

“The user’s currently confirmed shipping city is Prague.”

“The current workflow is awaiting manager approval.”

These should not necessarily share a retrieval mechanism.

The first is naturally episodic and fuzzy. The second is a mutable user state with explicit supersession semantics. The third is operational state in which an approximate historical match could be actively dangerous.

Structured state sacrifices open-ended semantic flexibility for exactness, observability, reproducibility and deterministic update behavior. Temporal database research has long formalized version and validity concepts relevant to this category. 25 Persistent LLM memory becomes most questionable when it is used as a fuzzy replacement for an existing precise state representation.

Persistent-memory systems demonstrate several distinct architectural ideas

Research since 2023 has explored multiple forms rather than converging on one design.

MemGPT frames finite context as a virtual-memory problem and lets an agent manage hierarchical storage tiers, moving information between active context and external memory. It is primarily an architecture proposal plus experimental demonstration, not evidence that autonomous memory management is universally safe. 37

Generative Agents stores natural-language observations, retrieves them according to relevance/recency/importance, creates reflections and uses the resulting memory in planning. Ablations show contributions to the paper’s simulated-agent believability objective, which is materially different from enterprise factual correctness. 26

A-MEM introduces structured, dynamically linked notes inspired by Zettelkasten organization. It is evidence that structured relationships can improve evaluated memory tasks, not evidence that those derived structures should become authoritative records. 22

Mem0 proposes dynamic extraction, consolidation and retrieval and reports strong LoCoMo efficiency and quality results, including substantial token/latency savings. Because the paper is vendor-authored and its measurements compare particular systems and configurations, the relative architecture claim deserves more weight than treating its numerical gains as a general law. 38

Temporal knowledge-graph approaches, including Zep/Graphiti research, model changing facts and relationships explicitly and report benchmark improvements. These are attractive when time and relation traversal matter, but graph construction adds a transformation layer whose extraction errors and provenance must themselves be managed. 39

TiMem, published in ACL Findings 2026, uses temporal-hierarchical organization and semantic consolidation and reports 75.30% on LoCoMo and 76.88% on LongMemEval-S while recalling substantially shorter memory than comparator approaches on LoCoMo. 5 RecMem, also ACL Findings 2026, uses recurrent consolidation and reports memory-construction token reductions of up to 87% versus three evaluated state-of-the-art approaches while improving accuracy in its experiments. 40

The opposing line of research is equally important. Zero-Mem explicitly preserves original traces as the source record and uses deterministic conflict filtering alongside structured organization, arguing that repeatedly asking LLMs to rewrite memory introduces cost and potential distortion. 41 E-mem similarly argues that aggressive preprocessing and graph-like compression can decontextualize evidence and focuses instead on reconstructing relevant episodic context. 8 These are new 2026 preprints, so they do not overturn consolidation results; they expose a trade-off those results do not eliminate.

Comparative architecture matrix

The table below is an evidence synthesis, not a benchmark in which all systems were run under identical conditions.

Property	Full long context	Summarized context	Vector RAG	Hybrid retrieval + rerank	Structured state	Persistent episodic/semantic memory
Recall of all raw evidence	Potentially high if evidence fits; effective recall degrades with length/position	Lower after lossy compression	Conditional on retrieval recall	Usually stronger candidate robustness	High only for represented schema	Conditional on what was promoted
Cross-evidence reasoning	Strongest when dependencies remain intact	Conditional on summary quality	Can fail when evidence fragments are retrieved separately	Better candidate set, same fragmentation risk	Strong for explicit relations/state	Conditional on representation
Context noise	High as corpus/history grows	Lower	Lower if retrieval works	Lower/medium	Very low	Medium, controlled by retrieval
Freshness	Must reconstruct prompt with current evidence	Requires summary invalidation	External corpus can update independently	Same	Excellent with explicit update semantics	Hard; staleness must be actively managed
Latency	Model-processing cost rises with input length	Lower model input, added summarization cost	Retrieval + generation	Additional reranking step	Usually low lookup overhead	Retrieval/consolidation dependent
Token cost	Often highest	Lower at inference	Bounded by retrieved set	Bounded but reranker cost added	Minimal representation overhead	Varies substantially
Observability	Exact prompt is inspectable	Summary transformation must be audited	Retrieval candidates/scores inspectable	High but multi-stage	Very high	Depends on system
Reproducibility	High if prompt/model/version fixed	Lower when generative summaries vary	Retrieval/index version also matters	More moving parts	High	Often lower due to generative write/update steps
Update semantics	No persistent update problem inside one prompt	Regenerate/invalidate	Update source/index	Same	Explicit	Core unresolved problem
Security exposure	All inserted text enters trust boundary	Poison can become concentrated in summary	Malicious documents can be retrieved	Reranking may help relevance, not instruction safety	Strong ACLs possible	Persistent poisoning/write attacks become first-class
Maintenance burden	Prompt assembly	Summary lifecycle	Corpus/index lifecycle	Multiple retrieval components	Schema/version migrations	Highest: promotion, conflicts, expiry, deletion and provenance
Best-supported niche	Dense interdependent evidence that reliably fits	Loss-tolerant continuity/compression	Sparse relevant evidence in large changing corpora	High-recall heterogeneous corpora	Exact mutable state	Cross-session experience/preferences where durable value justifies lifecycle cost

This synthesis is consistent with the long-context evidence, retrieval literature and current memory benchmarks rather than implying one universally optimal column. 13

Evaluation map, failure catalogue and contradictions

Evaluation has moved beyond “did it recall the fact?”

Earlier memory evaluation heavily emphasized conversational QA and recall. The frontier in 2026 is shifting toward interrupted tasks, active tool use, prospective intentions, cost/latency, dynamic updates and security.

Benchmark	What it primarily measures	Important coverage	Important omissions/limitations
LoCoMo (2024)	Long-term conversational memory	~300-turn conversations, QA, event summarization and long-range conversation evidence	Primarily conversational/passive; limited action and security testing. 24
LongMemEval (2024)	Interactive assistant memory	Extraction, multi-session reasoning, temporal reasoning, knowledge updates, abstention; 500 curated questions	Mostly answer-oriented rather than action-oriented; histories substantially synthetic. 4
RULER (2024)	Effective long-context utilization	Retrieval variants, multi-hop tracing, aggregation across controlled lengths	Synthetic diagnostic benchmark; not persistent memory lifecycle. 13
BABILong (2024)	Long-context reasoning amid distractors	Multi-fact reasoning over increasing context	Synthetic task family; not personalization or updates. 33
LifeBench (2026 preprint)	Rich long-term personal memory	Multiple memory-like evidence types including procedural/habit-style information	Simulated benchmark; cognitive labels remain functional abstractions. 42
IFCMemoryBench (2026 preprint)	Domain/professional structured memory	Separates ingestion, retrieval and utilization; difficult domain setting	New benchmark; domain coverage still limited. 43
Mem2ActBench (ACL 2026)	Memory-to-action	Tool choice and parameter grounding; 400 memory-dependent tasks from 2,029 sessions	Synthesized interaction construction; finite tool domains. 12
PM-Bench (2026 preprint)	Prospective memory	Delayed intentions over simulated multi-day operation; best reported method remains far from perfect	Simulation; emerging benchmark. 21
MemoryArena (2026 preprint)	Memory integrated with agentic action	Multi-session interdependent subtasks across web navigation, planning, search and reasoning	New; benchmark maturity and wider replication remain pending. 11
STATE-Bench (2026 production-oriented release)	Whether experience improves enterprise task execution	450 tasks across support, travel and shopping; task success/efficiency rather than recall alone	Engineering benchmark/provider report rather than peer-reviewed evidence. 44
MemSecBench (2026 preprint)	Memory poisoning lifecycle	Write → Execute → Forget/Repair, 310 cases, 24 system configurations	Security environment remains controlled and attack coverage cannot be exhaustive. 7
DolphinBench (Sept. 2026 preprint)	Task success + memory cost/latency	Three knowledge-work personas with ~500K tokens of messages each; 200 verified tasks/persona; requires accuracy, cost and latency	Extremely recent; independent replication not yet mature. 45

Two recent developments deserve particular weight. MemoryArena reports that agents performing near saturation on established long-context memory benchmarks can perform poorly on interdependent agentic tasks. 11 DolphinBench, released only days before this dossier’s snapshot, explicitly argues that conversational QA gives the question itself too much information about what should be remembered and instead measures task completion while requiring cost and latency reporting. 45

Together with Mem2ActBench, these results reinforce a methodological point:

A memory architecture should be evaluated at the level of the outcome it is supposed to improve, not merely at the level of retrieved text.

Current benchmarks still leave substantial gaps. Explicit, verifiable deletion and erasure are rarely primary benchmark targets. Cross-tenant permissions and privacy leakage remain less systematically evaluated than recall. Few benchmarks jointly test changing authoritative organizational sources, adversarial input, interrupted real-world tool execution, and downstream purge of derived memories. Long-lived production drift over months or years remains especially difficult to reproduce experimentally.

Failure-mode catalogue

Lifecycle area	Failure mode	Consequence
Capture	Overcollection	Privacy and noise accumulate before usefulness is established
Capture	Missing salient event	Nothing downstream can recover information never retained
Capture	Adversarial text promoted	Prompt injection becomes durable poisoning
Classification	Wrong memory type	Temporary task fact becomes permanent profile
Classification	Wrong tenant/project/user	Cross-scope leakage
Validation	Hallucinated extraction accepted as fact	Model inference becomes pseudo-authoritative
Validation	Source role ignored	Assistant speculation remembered as user’s statement
Storage	Duplicate records	Repetition distorts retrieval ranking/importance
Storage	Contradictory records without supersession	Stale and current states compete
Storage	Sensitive data retained unnecessarily	Increased privacy/security exposure
Indexing	Excessive fragmentation	Causal/narrative dependencies disappear
Indexing	Excessive consolidation	Exceptions and provenance disappear
Retrieval	Semantic miss	Relevant stored evidence never reaches model
Retrieval	Lexical miss	Identifier/name not recovered by semantic similarity
Retrieval	Temporal mismatch	Older but semantically similar item outranks current state
Retrieval	Poisoned-item dominance	Malicious memory becomes preferred candidate
Context assembly	Too much retrieved evidence	Noise recreates long-context failure
Context assembly	Ordering/position effect	Correct evidence exists but receives low effective attention
Reading	Authority confusion	Summary/inference overrides source truth
Reading	Temporal confusion	Historical fact treated as current
Reading	Scope confusion	Work preference applied in personal context
Action	Parameter grounding failure	Correctly recalled value is not used in tool call
Update	Append without superseding	Multiple “current” values remain active
Update	Summary not invalidated	Derived stale representation survives source update
Consolidation	Lossy abstraction	Qualifier, uncertainty or exception disappears
Consolidation	Self-reinforcing interpretation	Inference becomes evidence for later inference
Forgetting	Aggressive recency decay	Rare but important continuity is lost
Forgetting	No expiry	Temporary circumstances become permanent
Deletion	Source-only deletion	Embedding, summary, graph edge or cache survives
Organizational scope	Learned procedure crosses boundary	Customer/project behavior contaminates global behavior
Security	Poisoned procedure reused	One attack affects many future tasks
Prospective memory	Intention forgotten before trigger	Delayed obligation never executes
Prospective memory	Obsolete intention not cancelled	Agent performs an action that is no longer desired

The catalogue makes clear why “memory accuracy” is too coarse a metric.

Where credible approaches disagree

Long context versus retrieval. Lost in the Middle, RULER and BABILong provide strong evidence that simply inserting more tokens is not equivalent to reliable use. 2 Yet decomposition research shows the opposite failure: retrieval can destroy dependencies that intact context preserves. 3 This is a genuine architectural trade-off, not merely terminology. The key moderator appears to be information dependency/locality.

Aggressive consolidation versus evidence preservation. TiMem and RecMem show that structured consolidation can improve benchmark efficiency and accuracy. 5 Zero-Mem and E-mem emphasize failure from generated rewriting/decontextualization. 41 The conflict is partly objective choice: one line optimizes compact effective recall; the other gives greater weight to context integrity and auditability.

Graph memory versus simpler retrieval. Graph architectures can expose entity, relation and temporal structure and report gains on benchmarks. 22 But graph construction creates another extraction/transformation pipeline and does not consistently dominate across workloads; matched 2026 comparisons increasingly find workload-dependent rather than universal winners. 46 The disagreement is therefore both architectural and benchmark-dependent.

Model-managed memory versus deterministic state. MemGPT, A-MEM and related systems give models substantial discretion over memory organization. 37 Update studies suggest that known current-value semantics often benefit from explicit deterministic logic. 28 These need not be mutually exclusive: ambiguity-heavy semantic promotion and exact operational state are different problem classes.

Forgetting as feature versus continuity as objective. Strategic-forgetting research reports gains from pruning weak memories, but prospective-memory and long-horizon tasks demonstrate cases in which old, rarely used information remains decisive. 9 There is no evidence for a universal age-based decay rule.

Cognitive-memory categories as architecture versus metaphor. Episodic/semantic/procedural/prospective terminology is useful for distinguishing functional requirements, but human cognitive science itself models substantial interactions among memory systems. 23 The analogy is useful at the taxonomy level and weak as justification for copying human mechanisms literally.

Claim-to-source dossier, unresolved questions and research frontier

The following table concentrates the most consequential claims. “Supported” means supported in the stated task/architecture context, not established as a universal theorem. “Conditional” means important boundary conditions or conflicting results exist. All sources were inspected for this dossier on 2026-10-03.

Exact claim	Evidence type / architecture or task	Source date	Direct URL / DOI	Status	Main limitations
Nominal context-window size does not imply reliable use of all positions within that window.	Peer-reviewed long-context QA/retrieval experiments; Lost in the Middle	2024	https://doi.org/10.1162/tacl_a_00638	Supported 2	Models predate the 2026 frontier; tasks focus on retrieval/QA rather than every long-context workload.
Simple needle tests can substantially overstate usable long-context capacity.	RULER benchmark: 17 models, 13 tasks spanning retrieval, tracing and aggregation	2024-04-09 initial arXiv	https://arxiv.org/abs/2404.06654	Supported 13	Synthetic diagnostic tasks; “satisfactory” performance threshold is benchmark-defined.
Persistent conversational memory requires separate indexing, retrieval and reading/use evaluation.	LongMemEval benchmark; 500 questions including temporal/update/abstention tasks	2024-10-14	https://arxiv.org/abs/2410.10813	Supported 4	Mostly QA; interaction histories are partly generated/edited rather than organic long-term deployment logs.
Correct memory retrieval does not guarantee correct tool/action execution.	Peer-reviewed Mem2ActBench; tool selection and parameter grounding	2026-07	https://doi.org/10.18653/v1/2026.acl-long.370	Supported 12	Synthetic dataset construction and finite tool domains; not all agent classes tested.
RAG is not universally superior to intact long context; decomposition can harm tasks with strong contextual dependencies.	ACL Findings 2026 long-context/decomposition experiments	2026	ACL Findings paper “Lost in Decomposition”	Supported conditionally 3	Result depends on document/task structure and evaluated routing/decomposition methods.
Dense retrieval can outperform lexical BM25 substantially in some open-domain QA settings, but this is not a universal corpus-independent result.	Peer-reviewed DPR experiments	2020	https://doi.org/10.18653/v1/2020.emnlp-main.550	Supported conditionally 15	Dataset/domain dependent; later hybrid work shows complementary lexical value.
Sparse+dense hybrid retrieval can improve over either retrieval signal alone in appropriate settings.	Peer-reviewed hybrid/reranking retrieval experiments	2023	ACL Findings 2023 hybrid reranking study	Supported conditionally 16	Retrieval result, not full memory-lifecycle evaluation; gains vary by corpus.
Memory consolidation can materially reduce context/construction cost while preserving or improving benchmark accuracy.	ACL Findings 2026 TiMem and RecMem	2026	TiMem and RecMem ACL Findings records	Supported conditionally 5	Comparator-specific and benchmark-specific; does not establish source fidelity under all conditions.
Generated consolidation can also lose or distort contextual evidence; preserving original traces remains a credible alternative design.	2026 architecture preprints Zero-Mem and E-mem	2026	https://arxiv.org/ records for Zero-Mem and E-mem	Supported as identified risk; comparative superiority unresolved 41	Very recent preprints; independent replication limited.
Version/freshness maintenance can fail independently of raw memory capacity.	Supersede 2026 preprint; current-value memory-update experiments	2026	Supersede arXiv record	Supported conditionally 28	Narrower update environment; numerical results should not be generalized to all architectures.
Source provenance and derivation should be distinguishable from derived representations.	W3C provenance standard/model	2013	https://www.w3.org/TR/prov-overview/	Supported as mature data-management model 18	General provenance standard, not an AI-memory benchmark.
Valid time and system-recording time are distinct dimensions that matter for changing facts.	Temporal/bitemporal database research	Seminal pre-LLM work	XBiT/bitemporal primary literature	Supported as established database concept; AI application is synthesis 25	Direct application to LLM memory is architectural inference rather than benchmark result.
Persistent memory creates an attack surface in which malicious input can survive sessions and influence later actions.	MemoryGraft, Hidden in Memory, BackdoorAgent, MemSecBench	2025–2026	https://arxiv.org/abs/2607.27080; ACL 2026 BackdoorAgent record	Supported 30	Field is new; attack rates vary dramatically with harness, model, memory backend and threat model.
Deleting or decaying retrieval priority is not equivalent to erasing personal information.	Technical distinction plus EU statutory example	GDPR 2016; current text inspected 2026	https://eur-lex.europa.eu/eli/reg/2016/679/	Supported 6	Exact erasure duties are jurisdictional and have legal exceptions; this is not legal advice.
Agentic memory evaluation can expose failures hidden by conversational recall benchmarks.	MemoryArena, Mem2ActBench and DolphinBench	2026	https://arxiv.org/abs/2602.16313; https://arxiv.org/abs/2609.24971; DOI above	Supported, rapidly developing 11	Two of three are very recent preprints; benchmark ecosystems are not yet stable.
There is no demonstrated universal memory architecture that dominates across conversational, retrieval-heavy and agentic workloads.	Cross-study synthesis; MemoryArena and matched backend comparisons	2026	https://arxiv.org/abs/2602.16313; https://arxiv.org/abs/2608.13883	Supported as current evidence synthesis, not a theorem 11	Comparisons are not globally controlled; new models and benchmarks could change the frontier.

Inspection date for every row: 2026-10-03.

The highest-value unresolved questions now lie less in “how do we make another vector store?” and more in the interfaces between lifecycle stages.

Promotion calibration remains poorly solved. There is no broadly accepted empirical method for estimating whether an observation should become a durable memory. Most systems combine heuristics and model judgment, yet false-positive promotion can be more harmful than failure to remember because it affects arbitrarily many future interactions.

Authority-aware retrieval remains immature. Retrieval systems optimize relevance scores much more naturally than source authority, validity and ownership. How best to combine semantic similarity, freshness, provenance, permission and epistemic authority into a single context-selection process remains open.

Memory utilization is still weaker than memory retrieval. Mem2ActBench and MemoryArena make this gap measurable, but robustly translating memory into correct multi-step action—particularly when memories conflict or are only conditionally applicable—remains unresolved. 12

Deletion semantics remain under-benchmarked. Current memory research has increasingly sophisticated write, retrieve and consolidate benchmarks, yet comparatively little standardized evaluation asks whether a system can delete one person’s data, remove all dependent representations, preserve unrelated evidence and prove that the deleted material can no longer affect future behavior.

Cross-scope memory needs stronger evaluation. Multi-user, project, tenant and organizational boundaries are central to deployed systems but less mature experimentally than single-user recall. The dangerous failure is not only leaking text but allowing private or client-specific history to influence a shared summary, learned procedure or global decision policy.

Memory quality under endogenous feedback is poorly understood. An agent’s actions alter its future observations. A mistaken memory can cause an action that generates observations consistent with that mistake, creating self-confirming memory. Existing benchmarks largely avoid the years-long feedback dynamics that production agents could encounter.

Confidence remains conceptually underdefined. Systems frequently attach model confidence to derived memories, but there is no universal calibration connecting confidence to source trust, freshness or authority. “Highly confident inference” and “low-confidence authenticated source” cannot be safely compared on a single scalar without defining the decision problem.

Forgetting lacks a general objective function. Recency, frequency, utility and importance are useful heuristics, but prospective-memory tasks show why rarely retrieved records may remain crucial. 21 The core theoretical problem is estimating future option value rather than merely past usage.

Research frontier as of October 2026

Several developments could materially change the architecture landscape.

Effective long-context capability, not nominal token count, is the critical variable. Context windows continue to expand, and better attention, positional calibration and training may reduce current long-context weaknesses. If models become reliable over genuinely million-token interconnected histories, the balance will shift away from aggressive retrieval fragmentation. Yet current evidence still shows substantial utilization gaps, so this transition has not already occurred merely because large windows are technically supported. 35

Adaptive routing between context and retrieval is likely more consequential than choosing one permanently. The contradiction between RULER-style long-context limitations and decomposition failures suggests a future architecture in which the system estimates dependency structure: highly interconnected evidence remains contiguous, while sparse independent evidence is retrieved selectively. Lost in Decomposition already points toward routing as an answer to heterogeneous task structure. 3

Memory maintenance is becoming its own research field. Early systems focused on retrieval from accumulated records. The 2025–2026 frontier increasingly studies supersession, consolidation, temporal graphs, preference updates, pruning and contradiction handling. 5 This moves the field closer to databases and event/state management than to pure semantic search.

Agent benchmarks are replacing passive QA as the most demanding test. MemoryArena, Mem2ActBench and September 2026’s DolphinBench emphasize whether history changes later behavior correctly, not merely whether the model can answer “what did I say?” 11 DolphinBench’s explicit cost-and-latency requirement also pushes evaluation toward Pareto frontiers rather than a single accuracy score.

Security evaluation is moving from injection success to lifecycle consequence and repair. MemSecBench’s Write–Execute–Forget design is an important shift: the relevant questions are whether malicious state persisted, whether it altered an actual downstream action, and whether selective repair can remove it without destroying legitimate memory. 7

Original evidence versus generated memory is becoming a central architectural fault line. One research branch is pushing increasingly sophisticated consolidation, graphs and hierarchical representations; another is preserving immutable/raw traces while treating abstractions as disposable indexes or projections. 5 The latter approach resembles event-sourced and provenance-aware information systems and directly addresses the risk that a model-generated interpretation gradually becomes indistinguishable from its source.

Memory evaluation is likely to become multi-objective. DolphinBench explicitly couples task accuracy with latency and cost. 45 Security benchmarks add exploitability and repair; operational systems additionally care about provenance, deletion, reproducibility and permission integrity. A system with the highest QA recall but prohibitive cost, untraceable transformations or unsafe cross-session persistence cannot reasonably be called the “best memory system.”

The resulting design-space picture is therefore not a ladder from “no memory” to “more memory.” It is a set of differentiated information mechanisms:

context determines what the model can see now;
retrieval determines what external evidence is selected;
structured state represents exact mutable variables;
persistent memory carries selected information across time;
provenance determines where that information came from;
authority/version semantics determine what should currently be believed;
consolidation trades detail for efficiency;
forgetting controls continued eligibility and retention;
deletion removes information rather than merely ignoring it; and
evaluation must determine whether the complete chain produces the correct future decision or action.

Current evidence does not support collapsing those responsibilities into one universal “memory layer.” It supports treating long-term AI memory as a governed, temporal, provenance-aware information lifecycle whose final objective is correct future behavior—not maximal retention and not maximal recall. 4

Evidence Audit of Long-Term Memory, Context Management, and Retrieval in LLM Systems

Research snapshot: October 3, 2026
Scope: empirical evidence about long-term memory, context use, retrieval, persistent agent memory, dynamic updates, prospective memory, forgetting, compression, personalization, and security in LLM-based systems and agents.
Interpretive rule: a system does not count as having demonstrated meaningful long-term memory merely because an old fact was present in storage or could be retrieved.

Bottom line. The empirical literature supports a narrower set of claims than the architecture discourse usually implies. External retrieval can improve knowledge-intensive generation; persistent stores can improve recall on long conversations; some experience memories improve repeated-task performance; and recent benchmarks show that retrieved past information can sometimes be carried through into tool arguments and actions. Long context has also improved substantially. But none of this establishes that a particular “memory architecture” is necessary for capable agents, that human categories such as episodic/semantic/procedural memory describe distinct computational necessities, that recursive summaries are reliable indefinitely, that forgetting is generally beneficial, that knowledge graphs are superior memories, that vector databases are required, or that agents equipped with persistent memory become monotonically more useful over time. Much of that remains architectural intuition. 1

The strongest recurring methodological problem is stage conflation. Most “memory” scores measure the final answer to a question even though success depends on at least six separable events: the information was stored; it was retrieved; the right item was recognized as relevant; it was interpreted correctly; it was incorporated into the current reasoning; and the resulting answer or action was correct. LongMemEval and RAGChecker make important progress toward separating retrieval from downstream generation, while very recent benchmarks such as Mem2ActBench explicitly move from recall to tool selection and parameter grounding. But active-use evaluation remains far less mature than passive QA. 2

A second conclusion is that “long context versus RAG versus memory” is not a three-way contest with a stable winner. Full-context prompting has beaten RAG on average in controlled comparisons when the relevant corpus fits and compute is available; RAG is often much cheaper and remains useful for corpora that cannot sensibly be put into every prompt. Meanwhile, increasingly capable long-context models still show a material difference between nominal context capacity and reliable context utilization, especially when retrieval cannot exploit literal lexical overlap or when reasoning must integrate several dispersed pieces of information. 3

The field is moving in the right direction. LongMemEval-V2, TriggerBench, Mem2ActBench, large comparative memory-system evaluations, and 2026 security studies test harder phenomena than early “remember my favorite color” demonstrations. But many of these strongest-looking results are 2026 preprints rather than mature replicated evidence, so they belong in a research frontier, not yet in a list of settled engineering laws. 4

Executive judgment and construct map

What the literature means by “memory”

There is no stable, field-wide construct corresponding to LLM memory. At least four technically different things are routinely called memory: information encoded in parameters; tokens currently supplied to the model; an external information repository accessed by retrieval; and durable state accumulated by an agent over interactions. Lewis et al.’s original RAG formulation is unusually precise: the pretrained seq2seq model is parametric memory, while the Wikipedia vector index is non-parametric memory. Later agent papers broaden “memory” to include dialogue records, summaries, reflections, learned workflows, user profiles, notes, files, knowledge graphs, and executable experience traces. 1

Construct	Best operational definition for evidence auditing	Stability of usage	What it should not automatically imply
Parametric memory	Information represented in model weights after training/fine-tuning. Lewis et al. explicitly contrast this with an external non-parametric index. 1	Relatively stable	That a model can reliably address, update, source, or delete a particular remembered proposition.
Context / in-context information	Tokens available to the model during the current inference episode.	Stable technically; often metaphorically called working memory	Persistence after the context disappears.
Conversation history	Earlier turns copied or reconstructed into the current input. LoCoMo and LongMemEval evaluate this extensively. 5	Stable as an artifact, not as a cognitive category	A separate memory mechanism; it may simply be prompt content.
External retrieval	A query-time procedure that selects information from a corpus, history, database, file system, search engine, or other store. 1	Stable	That the retrieved corpus represents personal or persistent agent memory. Web search is retrieval without being agent memory.
Persistent memory store	Information that survives the current invocation/session and can later be accessed by the agent. MemGPT, MemoryBank, Mem0 and recent agent-memory systems fit this broad definition. 6	Broadly stable	That persistence entails correct retrieval, updating, or use.
User memory	Persistent information specifically about a user: facts, preferences, prior requests, relationships, goals, or interaction-derived profiles. MemoryBank is an early explicit example. 7	Moderately stable	That the stored inference is true, current, consensual, or appropriate to reuse.
Episodic memory	Usually timestamped events, interaction records, trajectories, or past experiences. Generative Agents and experience-retrieval systems use variants of this idea. 8	Unstable	Neurocognitive episodic memory or human autobiographical recollection.
Semantic memory	Usually extracted facts, entity relations, concepts, consolidated notes, or graph-like propositions.	Unstable	That an agent possesses a human-like semantic-memory subsystem.
Procedural memory	Usually workflows, skills, successful reasoning/action traces, reusable procedures, or instructions. Reflexion and experience-memory systems are closer to this functional notion than conventional RAG is. 9	Highly unstable	Human implicit procedural learning. A text trace of a successful workflow is still explicit data.
Working memory	Current scratchpad, short-term context, active task state, or a managed subset of external information.	Highly metaphorical	A computational analogue of human working-memory architecture merely because it is capacity-limited.
Prospective memory	Remembering that an intention should be executed when a future condition holds. Recent benchmarks operationalize this as latent trigger → spontaneous future action rather than answer retrieval. 10	Becoming more precise only recently	Ordinary recall of the instruction. The defining issue is later execution at the appropriate trigger.
Structured task state	Explicit variables such as current workflow stage, commitments, IDs, tool outputs, pending operations, deadlines, or environment state.	Technically clear but often folded into “memory”	A cognitive memory mechanism. Frequently it is just application state, and treating it as a database/state-management problem is more precise.

The most defensible umbrella definition is therefore functional rather than cognitive:

Agent memory is information from an earlier interaction or experience, preserved outside the immediate generation step and made available to influence a later generation or action.

That definition deliberately says nothing about how the information is represented. A vector database, a SQL row, a summary, a text file, a knowledge graph, a full conversation transcript, a learned parameter update, and an experience trace can all satisfy the functional requirement under different circumstances. The empirical literature does not justify defining memory by any one storage technology. This follows directly from the variety of representations evaluated in RAG, MemGPT, MemoryBank, Mem0, LongMemEval-V2, and newer comparative work. 1

Memory tasks are not interchangeable

The literature often reports “memory accuracy,” but the underlying tasks require quite different abilities. Treating them as one variable obscures more than it reveals. LoCoMo, LongMemEval, TriggerBench and Mem2ActBench illustrate the progression from conversational recall through dynamic temporal reasoning to prospective behavior and grounded tool execution. 5

Task	What must actually be demonstrated	Main confounds
Fact recall	Retrieve and correctly state an earlier proposition	Often reducible to lexical or semantic search
Preference recall	Recover a user preference and determine that it is still relevant	Preference may have changed; inference may never have been valid
Event recall	Recover what happened, often with actors/time/order	Temporal ordering and event identity
Multi-session continuity	Preserve relevant information across session boundaries	Could be solved by replaying history without any special memory architecture
Document QA	Locate evidence and answer from it	Primarily an information-retrieval task, not necessarily personal memory
Dynamic information update	Prefer a later valid state over an earlier superseded one	Requires time, provenance and conflict resolution, not merely retrieval
Conflict resolution	Determine which of several incompatible records governs the present query	Recency is not always equivalent to validity
Prospective memory	Execute an old intention when its trigger occurs later	Distinguishes latent intention from factual recall
Old-information task execution	Transform an earlier constraint into correct future behavior	Adds planning/execution failure after retrieval
Tool parameter grounding	Insert remembered facts into the correct tool arguments	Exactness, schema matching, entity disambiguation, stale state
Personalization	Improve behavior or outcomes for the individual using prior information	“More personalized” can be subjectively appealing yet objectively wrong

Consequently, “System X scores higher on LoCoMo” legitimately supports a claim about performance on long-conversation QA and related tasks; it does not by itself establish reliable prospective memory, tool grounding, deletion, personalization quality, or learning from experience. LoCoMo itself consists of ten long conversations generated by an LLM-based framework, with QA and event-summarization annotations; its release also includes generated observations and session summaries for retrieval experiments. 11

From storage to retrieval to use and action

The evidence pipeline

A useful evidence standard is:

stored → retrievable → retrieved → recognized as relevant → correctly interpreted → correctly used → correct outcome

These are causally distinct. An answer may fail because nothing was stored; because the retriever missed it; because the model ignored retrieved evidence; because it trusted the wrong temporal version; because it drew the wrong inference; or because it reasoned correctly but supplied the wrong tool parameter. Conversely, high end-to-end QA accuracy tells us little about which stages work reliably. RAGChecker was designed specifically because conventional end-to-end RAG metrics obscure retriever/generator interactions; it separately measures retrieval and generator behavior, including context utilization and handling of noisy evidence. 12

LongMemEval makes a similar decomposition for conversational memory. Its 500 questions test information extraction, multi-session reasoning, temporal reasoning, knowledge updating and abstention, while its proposed design framework explicitly separates indexing, retrieval and reading. The paper reports roughly a 30% accuracy decline for evaluated commercial assistants and long-context LLMs under sustained histories, and then shows that session decomposition, fact-augmented retrieval keys and time-aware query expansion can improve retrieval and downstream QA. That is much stronger evidence than a demonstration that “the fact is in the vector store,” but the terminal outcome is still an answer rather than an external action. 2

RAGChecker likewise found that retrieval improvement and final response quality are not synonymous. Its evaluation of eight RAG systems across ten domains identified a retrieval-versus-noise trade-off and generator behavior that can include excessive trust in supplied context. The implication is empirical rather than philosophical: retrieval recall is an intermediate metric, not a valid substitute for task success. 12

LongMemEval-V2 moves the benchmark closer to experienced-agent memory. Its 451 manually curated questions span static state recall, dynamic state tracking, workflow knowledge, environmental “gotchas,” and premise awareness over as many as 500 trajectories and 115 million tokens of historical experience. AgentRunbook-C, which stores trajectories in files and uses a coding agent to gather evidence, reaches 72.5% average accuracy versus 48.5% for the strongest RAG baseline and 69.3% for an off-the-shelf coding-agent baseline. This is significant evidence that how historical experience is searched and reconstructed matters. But the endpoint remains context gathering followed by QA: it should not be described as 72.5% reliable execution of old intentions. 4

Passive memory remains much better studied than behavioral transfer

The most common benchmark asks some version of “what did Alice tell you earlier?” That tests retrieval plus answer production. The more demanding question is “does the agent quietly apply Alice’s earlier constraint when taking an unrelated-looking action two days later?” The 2026 Mem2ActBench was created precisely because this latter problem was poorly captured: it tests whether an agent reconstructs executable tool arguments from information dispersed across long, interrupted interactions, including tool selection and parameter grounding. Its existence is itself evidence that prior benchmarks left a behavioral gap; as a recent preprint, however, its results should be treated as frontier evidence rather than a mature performance standard. 13

Reflexion gives an older but different example of memory transferring into behavior. It stores verbal feedback/reflections from unsuccessful trials and reuses them in later attempts. On selected sequential decision-making, reasoning and coding benchmarks it improves performance; its paper reports 91% pass@1 on HumanEval for the Reflexion setup compared with 80% for the GPT-4 baseline used in the study. That establishes something important but narrower than “persistent agents learn from experience”: textual records of prior attempts can improve subsequent attempts on some tasks. The setting is repeated task-solving over a relatively short experimental horizon, not indefinite autobiographical or user memory. 9

Security experiments provide surprisingly strong evidence for storage-to-action transfer because the attack succeeds only if poisoned information survives the whole chain. Hidden in Memory evaluates whether adversarial information is written to persistent memory, retrieved later and then changes subsequent behavior. It reports poisoned memories being written at rates up to 99.8% for GPT-5.5 and 95% for Kimi-K2.6 in its tested setups; conditional on successful retrieval, the poisoned records induce attacker-intended agentic actions in 60–89% of evaluations. This is a preprint and adversarial rather than benign benchmark, but it is unusually direct evidence that persistent information can cross sessions and materially alter later actions. 14

Dynamic updates and conflicts

Dynamic memory is materially harder than static recall because “retrieve everything relevant” is no longer sufficient. An old preference can be relevant and wrong. Correct behavior may require distinguishing observation time, effective time, source authority, correction versus exception, and explicit deletion. LongMemEval includes a dedicated knowledge-update category and temporal reasoning; LongMemEval-V2 goes further with dynamic-state tracking and premise awareness. These benchmarks establish that update handling can be evaluated and remains nontrivial, but they still simplify the open-ended problem of maintaining mutable real-world state. 2

The benchmark landscape is nevertheless heavily biased toward information that remains answerable from history. LoCoMo contains temporally distributed events and LongMemEval explicitly includes updates, but neither is equivalent to maintaining a production state model in which records can be corrected, revoked, deleted or made conditionally valid. Recent systems such as AgeMem expose update and discard as explicit memory actions, which is architecturally promising, but exposing an operation does not establish that an agent invokes it reliably under realistic ambiguity. 5

A strong real-world memory benchmark would therefore distinguish at least four cases: “new fact adds information,” “new fact corrects an old one,” “new fact applies only after date/event X,” and “user requests that the old information be forgotten.” Current benchmarks cover the first two much better than the latter two. The literature reviewed here does not yet establish a robust general mechanism for deciding when two retrieved memories should coexist, merge, supersede one another, or be deleted. The recent comparative study Are We Ready For An Agent-Native Memory System?, which evaluates 12 memory systems plus two reference baselines across five benchmark workloads and 11 datasets, is an important step toward more systematic component analysis, but it is still 2026 preprint evidence. 15

Prospective memory is a different capability

Prospective memory should not be reduced to “can the model repeat an old instruction?” The relevant test is whether the system executes an intention when the appropriate future trigger appears without being explicitly re-prompted to remember it. That distinction is emerging only recently in LLM evaluation. 10

Mittal’s 2026 TrustNLP study, Did You Forget What I Asked?, tests prospective-memory-like constraint retention across more than 8,000 prompts from three model families. Under increasing cognitive load, compliance with earlier constraints falls by 2–21 percentage points in the reported settings, with some terminal constraints dropping by as much as 50%; salient trailing reminders can restore 90–100% compliance in many conditions. One GSM8K configuration falls from 93% to 27%. This is evidence of intention/constraint interference, but it occurs within constructed prompt episodes rather than a persistent agent surviving real wall-clock delays or restarts. 10

TriggerBench is conceptually stronger. It separates prospective and retrospective conditions, includes positive and negative triggers to measure both successful activation and false alarms, varies overloaded/implicit triggers, and tests daily-assistant and professional-workflow scenarios. Its reported results show that prospective performance degrades substantially more than retrospective recall as context grows; reasoning can increase proactive recall while also encouraging over-triggering, and the authors find prospective performance related to available reasoning capacity. This is good evidence that remembering an intention and recognizing when to execute it is not equivalent to remembering its content. It is still a 2026 preprint rather than evidence that deployed agents reliably maintain intentions for weeks across interruptions. 16

The professional claim justified today is therefore: prospective behavior is measurable and substantially harder than passive retrospective retrieval in tested settings. The claim agents can reliably maintain deferred intentions across interruptions, environmental changes and restarts is not yet established. 16

Long context, RAG, compression, and forgetting

Long-context evidence has changed, but the core distinction survives

The original Lost in the Middle result should no longer be treated as a numerical description of 2026 models. It studied earlier generations and found strong positional effects on multi-document QA and key-value retrieval: relevant information was often used better at the beginning or end than in the middle. Its enduring contribution is the evaluation principle that nominal context length does not establish uniform context utilization. 17

RULER broadened long-context testing beyond simple needle retrieval. Across 17 long-context models and 13 tasks involving diverse retrieval, tracing and aggregation problems, it found that nearly perfect vanilla needle-in-a-haystack performance could coexist with substantial degradation on harder tasks as sequence length increased; at 32K tokens only about half of the evaluated models maintained satisfactory performance despite nominal support for at least that context length. These are 2024-generation results and should not be projected mechanically onto current models. 18

NoLiMa provides more contemporary and diagnostically useful evidence. It removes literal lexical overlap between the question and the relevant passage, forcing the model to recover information through latent semantic association. Among 12 models advertised with context capacities of at least 128K, ten had fallen below half of their strong short-context baseline by 32K in the reported tests; GPT-4o, for example, fell from 99.3% at short length to 69.7% at 32K. This shows why literal needle tests can materially overestimate useful context access. 19

HELMET reaches a similar conclusion from a more application-oriented direction. It evaluates 51 long-context models across seven categories up to 128K and finds that needle-in-a-haystack performance is a poor predictor of downstream long-context performance; different task categories also show substantially different trends. The key 2026-safe conclusion is not “all models get lost after 32K.” It is context length and context utilization remain different quantities, and performance must be measured on the actual task distribution. 20

LongBench v2 further shifts evaluation away from trivial retrieval toward realistic reasoning over very long inputs, with contexts spanning roughly 8K to 2M words and tasks designed to require deeper understanding rather than quick literal lookup. Together with HELMET and NoLiMa, this makes the early “lost in the middle” observation less a claim about a permanent U-shaped curve and more a broader empirical warning: context access is task-, model-, position-, density- and reasoning-dependent. 21

RAG works, but “RAG” is not one treatment

The foundational RAG study combined a pretrained parametric generator with a dense Wikipedia index and neural retriever. On its knowledge-intensive benchmarks it outperformed the parametric-only seq2seq baseline and task-specific retrieve-and-extract systems on several open-domain QA tasks; on generation tasks, the authors reported more specific, diverse and factual outputs than their parametric-only baseline. This directly supports retrieval augmentation under the tested conditions. It does not establish that every modern RAG pipeline beats a contemporary long-context model. 1

A controlled modern comparison by Li et al. reached an important apparently contradictory result: with sufficient resources and when the documents fit, full long-context prompting consistently outperformed RAG on average across the tested datasets/models, while RAG was substantially cheaper. Their Self-Route hybrid used a routing decision to capture much of long-context accuracy while reducing compute. The correct interpretation is not that RAG lost; it is that RAG trades information selection for efficiency, and the selection step can discard evidence that a sufficiently capable full-context reader could have used. 22

This reconciles much of the RAG-versus-context debate:

[ \text{RAG advantage} \neq \text{universal accuracy advantage} ]

RAG can win because a collection is too large to fit, because reading everything is too expensive, because irrelevant information distracts the model, because the corpus changes frequently, or because retrieval improves provenance. Full context can win when selection errors dominate and the model can afford to see everything. The empirical evidence therefore supports a conditional engineering trade-off, not a universal architecture hierarchy. 3

RAGChecker makes the architecture dependence explicit. It diagnoses the retriever and generator separately and finds that increasing retrieval can introduce additional noise; it also observes that some generators faithfully follow misleading retrieved context. Therefore better recall@k can coexist with worse downstream answers. This directly answers the storage-versus-use question for RAG: successful retrieval is necessary in many RAG pipelines but not sufficient for answer correctness or factuality. 12

Retrieval design choices have conditional, not universal, effects

Query rewriting. Rewrite-Retrieve-Read showed consistent improvements on its open-domain and multiple-choice QA settings by generating or learning a search query better aligned with the information need. That is empirical evidence for query rewriting as a useful intervention under retrieval mismatch; it is not evidence that rewriting should be mandatory for every query. 23

Chunk size. There is no supported universal “best chunk size.” A multi-dataset 2025 study finds smaller 64–128-token chunks better for concise fact-oriented datasets while 512–1024-token chunks can work better when broader context is required, with sensitivity varying by embedding model. 24

A 2026 controlled code-RAG experiment is even more revealing: four chunking strategies × four retrievers × five generators × nine configurations across RepoEval and CrossCodeEval produced 864 settings. Chunking strategy had a statistically significant effect, but the available cross-file context budget was often more important: increasing it from 2,048 to 8,192 tokens yielded gains of up to 4.2 percentage points, whereas chunk-size effects were weaker and non-monotonic, up to about 1.9 points in the reported analysis. Sliding-window and cAST chunking dominated the cost-quality frontier in those code benchmarks, while function-level chunking was never Pareto-optimal. That is strong evidence against universal chunking folklore, not for one universal replacement. 25

Embedding versus lexical retrieval. The available evidence does not justify “semantic/vector retrieval is always superior.” Performance varies with domain, query form and chunk representation; the code-RAG study, for example, found differences among retrieval choices smaller than the chunking-strategy gap in its setting. Modern systems frequently combine lexical and dense retrieval precisely because their failure modes differ. 25

Hybrid retrieval and reranking. Anthropic’s Contextual Retrieval experiments provide primary vendor evidence that contextualizing chunks before indexing, combining lexical and embedding retrieval and reranking can improve retrieval in its evaluated corpora. This is useful production evidence but not peer-reviewed independent evidence, so its reported improvements should be treated as system-specific rather than as universal constants. 26

Contextualized chunks. The underlying hypothesis is empirically plausible: an isolated chunk can lose the entity, document, date or section information required for retrieval, and prepending a short document-specific context can restore those cues. Anthropic reports gains from this approach; independent cross-domain replication remains thinner than the industry enthusiasm suggests. 26

Reranking. The general information-retrieval rationale is strong, and vendor/individual system evaluations show gains, but the evidence reviewed here does not establish a universal reranker benefit after controlling for retrieval budget, generator, corpus, chunking and latency. This is an example where “usually sensible engineering” is stronger than “settled causal law.” 26

Factuality, citations and reasoning are separate RAG outcomes

Retrieval grounding can improve factuality, but RAG cannot guarantee it because the generator may ignore, misinterpret or over-trust the evidence. RAGChecker explicitly measures these generator-level phenomena rather than assuming retrieved evidence was used faithfully. 12

Citations are another separate outcome. A system can retrieve a relevant source yet write an unsupported claim, or cite a source that does not entail the generated sentence. Therefore “has citations” and “is grounded” must not be treated as synonyms. RAGChecker’s claim-level entailment framework exists in part because conventional response-level metrics miss these distinctions. 12

Likewise, retrieval does not create reasoning ability. It supplies evidence. HELMET, LongBench v2 and LongMemEval-V2 all show that finding information and reasoning over long/distributed evidence are distinct capabilities. 27

Summarization and context compression

Recursive summarization has positive evidence, but much less evidence for indefinite fidelity. A 2025 Neurocomputing study repeatedly updates a compact dialogue summary using the previous summary plus new dialogue and reports improved long-term dialogue consistency across GPT-3.5-Turbo, Llama and ChatGLM settings, including automatic and human evaluation. It also reports complementarity with larger context windows and retrieval. This supports recursive summary memory as a useful compression method in the evaluated dialogue tasks. 28

What that study does not establish is lossless long-term memory. A summary is an information bottleneck: omitted details cannot later be recovered from the summary alone. More importantly, the present literature has not convincingly characterized error accumulation after dozens or hundreds of recursive summary rewrites, especially under user corrections, contradictions, subtle exceptions and adversarial inputs. The available result is “recursive summarization can improve dialogue performance relative to tested baselines,” not “recursive summarization reliably preserves all information over arbitrary horizons.” 29

LoCoMo is useful here because its authors release raw dialogue, generated observations and session summaries as alternative RAG databases. Such comparisons make it possible to study a real compression trade-off: summaries reduce history volume but alter what can be retrieved. Yet the benchmark is still generated long-form dialogue rather than a longitudinal record with legally/operationally important facts whose omission carries known costs. 11

Thus the evidence for compression ratio versus downstream task performance is meaningful; evidence for summary fidelity over indefinite recursive updates is weak. “Summary drift” is a credible failure hypothesis, but it is not yet characterized well enough to quote a universal drift rate or safe recursion horizon.

Forgetting and decay

The research case for beneficial forgetting is much weaker than the conceptual case. MemoryBank explicitly adopts an Ebbinghaus-inspired forgetting mechanism, but its use of a human forgetting curve is an architectural analogy; the benchmark evidence does not establish that Ebbinghaus-shaped decay is an optimal policy for LLM agents. 7

There is stronger indirect evidence that blindly exposing the model to more information can hurt. Long-context benchmarks show degradation with distracting or difficult-to-access context, while RAGChecker finds that retrieving more material can introduce noise that harms downstream generation. This supports selection and pruning of the active context. It does not establish that the corresponding records should be permanently deleted from long-term storage. 30

That distinction matters:

not retrieving now ≠ forgetting permanently.

A memory can be excluded from the current context because it is irrelevant yet remain valuable later. True beneficial forgetting requires a stronger experiment: compare retention/deletion policies over future workloads and show that deletion improves overall performance or cost without creating unacceptable future recall failures. The reviewed benchmark literature rarely performs that experiment. Newer agentic frameworks such as AgeMem allow explicit discard operations, but architectural support for forgetting is not the same as empirical evidence that agents make good deletion decisions. 31

The literature is particularly immature on stale-memory deletion, user-requested erasure, deletion precision/recall, and future regret after deletion. Knowledge-update benchmarks establish that superseded facts are difficult; they do not establish optimal forgetting policies. 2

Persistent memory, personalization, human analogies, and security

What persistent-memory architectures have actually demonstrated

MemGPT treats context management as a virtual-memory problem, maintaining different tiers of information and explicitly moving information between them. Its 2023 experiments cover document analysis beyond the immediate context and multi-session conversation. The architecture is influential because it makes memory management explicit, but the evidence comes from an early model generation and relatively narrow evaluations; it does not establish OS-style hierarchical paging as a generally superior memory architecture. 32

MemoryBank stores conversational memories, retrieves relevant ones, updates them and synthesizes user/personality information; it also incorporates an Ebbinghaus-inspired forgetting mechanism. Its AAAI 2024 evaluation reports improvements in memory recall, empathetic companionship and understanding of user portraits, using a combination of qualitative real-user dialogues and quantitative simulated long-term conversations. Because part of the quantitative evaluation uses ChatGPT-simulated users/contexts, the evidence is substantially stronger for benchmark recall than for real longitudinal user benefit. 7

Generative Agents store natural-language experience records, retrieve them according to relevance/recency/importance, produce higher-level reflections and use them in planning. In a sandbox town of 25 agents, ablating observation, reflection and planning components reduced human-rated believability, and the integrated system generated multi-agent social behavior such as organizing a Valentine’s event. This is genuine component evidence—but its dependent variable is largely believable simulated behavior over a short horizon, not correctness on real-world tasks. 33

Reflexion provides some of the strongest evidence that memory-like experience can improve later behavior: verbal feedback on previous attempts is stored and reused, producing gains in coding, reasoning and sequential decision problems. But this is better described as trial-level experiential learning through context than as evidence for durable cross-session personal memory. 34

Mem0 reports stronger LoCoMo performance than several memory baselines, with its base approach showing a 26% relative improvement on the paper’s LLM-as-judge measure over the OpenAI-memory baseline used in the experiment; its graph variant adds roughly another 2% overall. The authors also report substantially lower latency and token costs than full-context approaches. These results show that extraction/consolidation/retrieval design can matter on conversational QA. They do not establish that graph memory is generally superior, particularly because the graph increment is modest, evaluation is concentrated on LoCoMo-style tasks, and the work is produced by the system’s developers. 35

LongMemEval-V2’s AgentRunbook-C is perhaps the most interesting architecture result as of the snapshot because a coding/file-navigation agent gathering evidence from stored trajectories significantly outperforms conventional RAG on the new benchmark. Its 72.5% average versus 48.5% for the strongest RAG baseline suggests that historical experience can benefit from structured browsing and computation rather than top-k semantic retrieval alone. Yet the 69.3% off-the-shelf coding-agent result also shows that much of the gain may come from the general evidence-gathering agent capability; the memory-specific incremental gain over that stronger baseline is only 3.2 points. That is precisely why baseline choice matters. 4

The emerging 2026 comparative literature is starting to address weak-baseline concerns directly. Are We Ready For An Agent-Native Memory System? decomposes systems into representation/storage, extraction, retrieval/routing and maintenance, and evaluates 12 representative systems plus two reference baselines on five workloads spanning 11 datasets. Its importance is methodological: the field is finally moving toward matched component evaluations instead of each new architecture choosing a bespoke benchmark and weak baseline. As of October 3, 2026 it remains recent preprint evidence. 15

Personalization evidence is real but narrower than product claims

Persistent user information can clearly change responses. MemoryBank provides early quantitative and qualitative evidence of better recall and user-profile understanding; Mem0 improves long-conversation QA; LoCoMo supplies user-like preferences and events over repeated sessions. This supports the limited statement that persistent access to prior user information can improve tests requiring that information. 7

That is not equivalent to demonstrating improved user outcomes. The core benchmarks overwhelmingly score answer correctness, LLM-judged response quality, personality consistency or simulated interaction. They rarely randomize real users to persistent-memory versus no-memory systems for weeks or months while measuring satisfaction, completion rates, trust, correction burden, perceived intrusiveness and objective task success. The material studies in this audit therefore do not support a strong general claim that persistent memory improves long-term user satisfaction. 7

Wrong personalization also deserves independent measurement. A correctly retrieved but obsolete preference can be worse than no personalization, because the system may confidently apply a constraint the user has rescinded. LongMemEval’s update category demonstrates the technical difficulty of superseded information, while the new security literature shows an extreme version in which false persistent information later controls behavior. Preference-specific user harm, however, remains poorly quantified. 2

The evidence thus differs by endpoint:

Personalization endpoint	Evidence status
Recall of user facts/preferences	Directly supported on benchmarks. 7
More contextually continuous dialogue	Conditionally supported. 7
Objective task-performance improvement	Supported in selected tasks, sparse across realistic longitudinal use. 36
Increased real-user satisfaction over months	Inadequately tested in the core evidence base reviewed here.
Appropriate handling of changed preferences	Early/partial evidence only. 2
Avoidance of inappropriate personalization	Poorly established.
Net benefit after correction burden/privacy costs	Not established by current memory benchmarks.

Human-memory terminology: useful experimental vocabulary, dangerous ontology

Cognitive terminology is most useful when it creates a falsifiable behavioral distinction. Prospective memory is a good example: TriggerBench translates the idea into a measurable difference between remembering information and spontaneously executing an intention when a trigger occurs. That analogy produces a useful benchmark without claiming shared cognition. 16

“Episodic” versus “semantic” memory can also be operationally useful when it means, for example, raw timestamped experiences versus consolidated factual abstractions. But papers implement these concepts using text records, embeddings, summaries, graphs and retrieval policies. Nothing about those implementations warrants cognitive equivalence with human episodic or semantic memory. Generative Agents’ “memory stream,” MemoryBank’s human-inspired forgetting and experience-memory systems are engineering abstractions over stored text, not evidence of human-like memory processes. 8

“Procedural memory” is especially easy to overstate. When an agent retrieves a successful reasoning trace and imitates it, what exists mechanically may be an explicit text demonstration in a database. Calling it procedural memory can be convenient, but it does not make the mechanism equivalent to implicit human skill learning. MemoryGraft’s attack actually highlights this distinction: malicious procedure templates stored as successful experiences can later be imitated by an agent because retrieval exposes them as demonstrations. 37

Likewise, working memory often means current context, scratchpad or actively selected records; consolidation often means summarization, extraction or merging; salience is typically an importance/relevance heuristic; forgetting means decay, pruning or deletion. These terms can organize hypotheses, but their mechanisms are ordinary computation over text/state unless separately demonstrated otherwise. MemoryBank’s Ebbinghaus-inspired decay is the clearest cautionary example: borrowing the curve does not establish that the underlying agent has a human-like forgetting process or that the borrowed decay profile is optimal. 7

Security has progressed from hypothetical threat to demonstrated attack

Persistent memory creates one of the clearest cases where the consequences are no longer architectural speculation.

MINJA, A Practical Memory Injection Attack against LLM Agents, shows that an attacker can inject malicious records into an agent’s memory by interacting through ordinary queries and observing outputs rather than directly modifying the memory store. The attack constructs records likely to be retrieved later and intended to induce malicious reasoning/actions on a victim query. The paper reports effectiveness across multiple agents, demonstrating that memory poisoning is a practical attack class rather than only a theoretical concern. 38

MemoryGraft attacks persistent experience retrieval. Its MetaGPT DataInterpreter experiment uses GPT-4o, 100 benign and 10 poisoned experience seeds and 12 handcrafted evaluation queries. Across 48 retrieved records, 23 were poisoned—a 47.9% poisoned-retrieval proportion—despite poison being a minority of the store. The malicious memories encode unsafe procedures such as skipping validation or unsafe automation, persist across sessions, and remain active until the store is purged. External validity is limited by the small handcrafted workload and specific assumptions, but persistent behavioral compromise is demonstrated. 37

Hidden in Memory goes further by explicitly evaluating write → later retrieval → future action and shows cross-session attacks against contemporary stateful assistants, with very high poison-write rates and 60–89% attacker-intended actions conditional on successful poisoned retrieval. This is perhaps the clearest empirical refutation of the idea that memory security can be treated as ordinary prompt-injection hygiene. 14

The evidence hierarchy is therefore:

demonstrated: malicious information can be persisted and later alter agent behavior. 39
demonstrated under specific threat models: poisoning can survive session boundaries and induce unsafe procedures/actions. 37
not yet demonstrated broadly: a general defense that remains effective across memory formats, retrievers, adaptive attackers and long-lived multi-user agents.

Provenance, sanitization, trust labels, write authorization and purge mechanisms are sensible defenses, but the current evidence does not justify saying that persistent-memory poisoning is a solved security problem. MemoryGraft itself emphasizes the vulnerability created when retrieved “successful experiences” are trusted without provenance verification. 37

Benchmark validity and contradictory evidence

Benchmark audit

Benchmark	Memory/context construct	Horizon and data	Dynamic/conflict?	What is measured	Important omissions / validity issue
LoCoMo	Long-term conversational/event memory	Ten selected very long conversations generated between LLM agents with personas; QA and event summaries; multi-session chronology. 11	Temporal events, but no systematic production-grade correction/deletion regime	QA, event summarization; RAG over raw dialogue, observations or summaries	Synthetic conversations; only ten conversations in final release; no tools/actions; “user outcome” external validity limited.
LongMemEval	Persistent conversational memory	500 questions embedded in scalable chat histories; short/full-history variants. 2	Yes: knowledge updates and temporal reasoning	QA plus retrieval recall; indexing/retrieval/reading decomposition	Final endpoint remains QA; no external action/tool execution.
LongMemEval-V2	Memory over agent/environment trajectories	451 curated questions, up to 500 trajectories and 115M tokens. 4	Stronger: dynamic state, workflow knowledge, environment gotchas, premise awareness	Context-gathering + QA	Much more realistic experience history, but still evaluates evidence reconstruction rather than direct execution.
RULER	Long-context utilization	Synthetic long contexts; 13 tasks, 17 models. 18	No real evolving state	Retrieval/tracing/aggregation accuracy	Synthetic by design; useful stress test, weak proxy for real assistant continuity.
NoLiMa	Latent long-context retrieval	Removes literal question–needle overlap; 12 ≥128K-context models. 19	Static	Answer retrieval across length	Still synthetic, but directly fixes a weakness of lexical NIAH tests.
HELMET	Application-oriented long-context performance	Seven categories, 51 models, up to 128K. 40	Depends on task	QA/reasoning/instruction-following/application outcomes	Better ecological diversity; still offline benchmark rather than longitudinal interaction.
LongBench v2	Long-context reasoning	Realistic long inputs from roughly 8K–2M words. 21	Primarily static input	Deep understanding/reasoning	Not persistent user memory; a context benchmark.
MemBench	Factual/reflective memory in participation and observation scenarios	Memory-specific benchmark	Mostly historical	Effectiveness, efficiency, capacity	Categories are benchmark-defined constructs; not proof of human memory types. 41
TriggerBench	Prospective vs retrospective memory	Long-context daily-assistant/professional scenarios, matched controls	Trigger state and negative-trigger conditions	Proactive recall, false alarms, robustness	Recent preprint; simulated triggers rather than real wall-clock persistence. 16
Mem2ActBench	Memory-to-action/tool grounding	Persistent-assistant simulation with long interrupted interactions	Prior preferences/task state reused later	Tool selection + executable argument reconstruction	Much closer to real behavior, but very recent preprint and simulated environment. 13

The benchmark-validity lesson from HELMET is particularly important: near-perfect NIAH does not predict broad long-context competence. NoLiMa reaches the same point by removing lexical shortcuts. A benchmark that lets a model win by matching an obvious entity/string tests a retrieval mechanism but can overstate the capacity to interpret a vague cue, integrate multiple records or identify the currently valid state. 40

LongMemEval itself also illustrates benchmark fragility. The project subsequently cleaned dataset histories after identifying noisy history sessions that interfered with answer correctness, underscoring that seemingly innocuous filler construction can materially affect measured memory ability. Benchmark design is not neutral: distractor distribution, history density and answer annotation can change conclusions. 42

What major benchmarks usually do and do not contain

Across the benchmark set, irrelevant history is now reasonably common: RULER, NoLiMa, LongMemEval and long-context suites deliberately stress distractor handling. 18

Changing information is less common but improving: LongMemEval has knowledge updates and LongMemEval-V2 has dynamic state tracking. 2

Conflicting information is tested indirectly in counterfactual/RAG diagnostic work and update benchmarks, but systematic provenance-aware conflict resolution is not yet a standard axis across memory benchmarks. RAGChecker explicitly treats misleading/noisy context as a generator robustness problem. 12

Malicious information is largely evaluated in separate security papers rather than ordinary memory benchmarks. MINJA, MemoryGraft and sleeper-memory poisoning demonstrate why these literatures need to converge. 39

Deletion is notably underrepresented. Frameworks can expose delete/discard operations, but benchmarks rarely measure whether a requested deletion propagated correctly, whether deleted facts continue to influence retrieval, or whether the system later reconstructs supposedly removed information. 31

User correction is only partially represented by knowledge-update tasks. The richer real-world question—whether an agent understands that “I no longer want X” supersedes an older preference while preserving unrelated historical facts—is not yet adequately standardized. 2

Cross-session behavior is tested more often than before, but typically as QA. Mem2ActBench and the security work are important because they require prior state to affect behavior. 13

Tool use remains uncommon in the classic memory benchmarks. That makes QA-heavy leaderboards a poor sole basis for claims about autonomous agents. 13

Why apparently contradictory studies are often both right

Long context beats RAG vs. long context deteriorates. Li et al. find full context more accurate than RAG in their tested setups when the context fits; RULER, NoLiMa and HELMET find substantial degradation as long-context tasks become longer/harder. These results are compatible: full context can be better than a lossy retriever and still be imperfect. 3

NIAH is solved vs. long context remains difficult. HELMET explicitly finds NIAH to be a poor downstream predictor, and NoLiMa shows that removing literal overlap makes the same nominal context much harder. The disagreement comes from task construction, not merely model generation. 40

RAG improves factuality vs. retrieved context can hurt. The original RAG results show better factual generation than parametric-only baselines, while RAGChecker finds that irrelevant or misleading retrieval can reduce output quality and that generators may over-trust context. Retrieval quality and evidence-use quality are distinct moderators. 1

Memory architecture X beats baseline vs. simple agent search is almost as good. AgentRunbook-C beats the strongest RAG baseline by 24 points on LongMemEval-V2, but only by 3.2 points over the off-the-shelf coding-agent baseline. Architecture claims that quote only the weaker baseline would dramatically overstate the specific value of the memory representation. 4

Graph memory improves performance vs. graphs are unnecessary. Mem0’s graph version reports a modest ~2% improvement over Mem0 overall on its benchmark, which is evidence for that implementation on that task—not evidence that knowledge graphs are generally superior to text, files, vectors or relational state. 43

Summarization works vs. summarization loses information. Recursive summarization improves tested dialogue outcomes; the fact that summaries are lossy does not contradict that. Compression can discard details and nevertheless improve downstream performance by reducing irrelevant context. What is missing is a long-horizon fidelity study establishing the conditions under which the discarded information later becomes consequential. 44

Prospective reasoning helps vs. reasoning causes over-triggering. TriggerBench reports that additional reasoning can raise proactive recall while increasing false positives in some conditions. That is precisely why prospective-memory evaluation needs both hit rate and false-alarm rate. 16

Claim audit and unsupported conclusions

The classifications below concern the general claim, not whether one paper has demonstrated one favorable instance.

Common claim	Evidence classification	What can legitimately be said
“Long-term memory is necessary for capable agents.”	Plausible but inadequately tested	Persistent tasks obviously require some way to preserve relevant state, but no evidence shows that a distinct “long-term memory architecture” is necessary for capable agents. Full history, files, structured state, retrieval, summaries and parametric adaptation can substitute in different tasks. 4
“Larger context windows eliminate the need for RAG.”	Contradicted as a general claim	Long context can outperform RAG in accuracy when the corpus fits, but utilization remains imperfect and RAG can dramatically reduce cost or search information beyond feasible context. 3
“RAG is better than long context for large knowledge bases.”	Conditionally supported / mixed	RAG has an obvious scaling/cost advantage as collections grow; on matched answer accuracy, full context can beat it when feasible. “Better” depends on corpus size, query distribution, cost, latency and retrieval error. 3
“Agents need episodic and semantic memory.”	Unsupported as a necessity claim	Those categories can motivate useful representations, but no factorial evidence establishes two cognitively named subsystems as necessary. 8
“Summarization provides reliable long-term memory.”	Mixed	Recursive summaries can improve long-dialogue performance; indefinite fidelity and resistance to accumulated drift are not established. 28
“Forgetting improves AI systems.”	Plausible but inadequately tested	Filtering irrelevant active context can help; permanent beneficial deletion is much less directly evaluated. Ebbinghaus-style decay is inspiration, not a proven optimal policy. 12
“Persistent memory improves personalization.”	Conditionally supported	It improves preference/fact recall and some personalization proxies; robust longitudinal evidence for real-user satisfaction and net benefit is sparse. 7
“Memory allows agents to learn from experience.”	Conditionally supported	Reflexion and experience-retrieval systems show that records of prior attempts can improve later attempts on selected tasks. This does not establish open-ended lifelong learning. 9
“Memory reduces hallucinations.”	Conditionally supported	Retrieved evidence can improve factuality relative to parametric-only baselines, but bad or poisoned retrieval can introduce errors and attacks. Memory is not a hallucination guarantee. 1
“Memory enables agents to become more useful over time.”	Plausible but inadequately tested	Benchmark gains exist; longitudinal studies showing monotonic net user value over months are missing. Stale and poisoned memories can make later behavior worse. 7
“Memory frameworks improve real-world task performance.”	Mixed	Gains are established on QA, simulation, coding and selected sequential tasks. Much of the literature remains synthetic or benchmark-bound, with limited longitudinal deployment evidence. 9
“Knowledge graphs provide superior agent memory.”	Unsupported as a general claim	Mem0’s graph variant offers a modest gain in its evaluation, but this is far from universal superiority. Files, retrieval, summaries and direct context remain competitive. 45
“Vector databases are necessary for long-term memory.”	Contradicted	Long-term information can be stored in raw histories, files, lexical indices, structured databases, graphs, summaries or model parameters. AgentRunbook-C’s file-based/coding-agent approach is a particularly direct counterexample. 1

What current evidence does not support

It does not support equating capacity with utilization. Advertising a 128K, 1M or larger context means the model accepts that many tokens; it does not establish that all relevant information is used equally well at every position and reasoning depth. 18

It does not support equating storage with memory success. Persistent storage is only the first stage; recent security work demonstrates the perversity of that assumption because malicious information can be stored and retrieved extremely successfully while producing exactly the wrong behavior. 14

It does not support equating retrieval recall with answer correctness. RAGChecker directly shows the need to diagnose retriever and generator separately. 12

It does not support equating answer correctness with agent reliability. Most classic memory evaluations terminate at text QA; active tool/action tests are only now emerging. 2

It does not support saying that human memory taxonomies are discovered architectural primitives. The papers instantiate episodic, semantic, procedural, working and forgetting concepts using heterogeneous data structures and policies. 8

It does not support lossless recursive summarization. Positive dialogue results establish utility, not preservation of every future-relevant detail. 28

It does not support optimal beneficial forgetting. Current evidence better establishes the cost of irrelevant active context than the benefit of irreversible deletion. 12

It does not support the claim that personalization necessarily benefits the user. Correctly remembered information can improve continuity; stale, wrongly inferred or maliciously planted information can make behavior less appropriate. Long-term user-centered outcome studies lag far behind recall benchmarks. 7

It does not support the claim that memory automatically produces cumulative self-improvement. Reflexion-like systems provide conditional evidence for learning from prior attempts; persistent-memory attacks show that the same feedback loop can accumulate harmful experience. 9

And it does not support universal prescriptions such as “always use embeddings,” “always use knowledge graphs,” “always summarize,” or “always stuff the full context.” Controlled experiments increasingly show interactions among chunking, retrieval, generator, context budget and task type. 25

Study ledger, research gaps, and frontier

Reading note: “NR” means a detail was not reported in the abstract/metadata/full-text record reviewed for this audit; it should not be interpreted as evidence that the authors did not report it elsewhere. Results are reported as the study reports them, not automatically endorsed as externally valid.

Study	Publication status / date	Model or system / memory architecture	Task, baseline, horizon, sample	Outcome and main finding	Main limitation / external validity	DOI / direct URL
Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” 1	NeurIPS 2020, peer reviewed	Pretrained seq2seq parametric memory + dense Wikipedia non-parametric index	Open-domain QA and knowledge-intensive generation; parametric-only and retrieve/extract baselines	SOTA on three tested open-domain QA tasks; more specific/diverse/factual generation than parametric-only baseline	Pre-modern LLM generation; not long-term user/agent memory	https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html
Liu et al., “Lost in the Middle” 17	TACL-era work, 2023/24	Then-current long-context LMs	Multi-document QA and key-value retrieval; relevant item moved by position	Strong position-dependent utilization; middle often worse	Model generations now obsolete numerically; should be treated as evaluation principle, not current performance estimate	https://arxiv.org/abs/2307.03172
RULER 18	COLM 2024, peer reviewed	17 long-context LMs	13 synthetic retrieval/tracing/aggregation tasks over growing context	Vanilla NIAH can saturate while harder tasks degrade; only about half maintained satisfactory 32K performance	Synthetic; 2024 models	https://arxiv.org/abs/2404.06654
Maharana et al., LoCoMo 11	ACL 2024 / research release	Full context and GPT-3.5-based RAG over dialogue/observations/session summaries	Ten long LLM-generated conversations; multi-session QA and event summarization	Enables standardized long-conversation memory comparisons	Only ten released conversations; synthetic agent dialogue; no action/tool-use endpoint	https://arxiv.org/abs/2402.17753
Ma et al., Query Rewriting in RAG 23	EMNLP 2023, peer reviewed	LLM query generator / trainable small rewriter + search + LLM reader	Open-domain QA and multiple-choice QA	Consistent improvement from Rewrite-Retrieve-Read	Task-specific; does not establish universal value of rewriting	DOI 10.18653/v1/2023.emnlp-main.322; https://aclanthology.org/2023.emnlp-main.322/
Li et al., RAG or Long-Context LLMs? 22	EMNLP Industry 2024, peer reviewed	Three then-current LLMs; RAG, full long context, Self-Route	Public QA datasets; matched RAG/full-context comparison	Full context more accurate on average when affordable; RAG substantially cheaper; hybrid routing retains much accuracy at lower cost	Model/cost landscape changes quickly; corpora must fit for full-context baseline	DOI 10.18653/v1/2024.emnlp-industry.66
RAGChecker 12	2024 preprint / open-source evaluation work	Diagnostic framework for RAG	Eight RAG systems across ten domains; human meta-evaluation	Separates retriever/generator; reveals retrieval-noise trade-offs and context over-trust	Diagnostic benchmark rather than intervention trial	https://arxiv.org/abs/2408.08067
LongMemEval 2	ICLR 2025, peer reviewed	Full history, retrieval, commercial assistants/LCLMs; indexing–retrieval–reading framework	500 questions; sustained multi-session histories; information extraction, multi-session/temporal reasoning, update, abstention	Approx. 30% accuracy degradation in tested sustained-interaction settings; retrieval/read optimizations improve QA	QA endpoint; synthetic/scalable histories; repository later cleaned noisy sessions	https://arxiv.org/abs/2410.10813; DOI 10.48550/arXiv.2410.10813
NoLiMa 46	ICML 2025	12 LLMs claiming ≥128K context	Long-context retrieval without literal lexical overlap	10/12 below half strong short-context baseline at 32K; GPT-4o 99.3%→69.7% in reported setup	Synthetic retrieval; not full agent workflow	https://arxiv.org/abs/2502.05167; DOI 10.48550/arXiv.2502.05167
HELMET 20	ICLR 2025	51 long-context models	Seven application-centric categories up to 128K	NIAH poorly predicts downstream long-context performance; category trends differ	Offline benchmark rather than longitudinal interaction	https://arxiv.org/abs/2410.02694
LongBench v2 21	ACL 2025	Contemporary long-context LLMs	Realistic deep-understanding/reasoning tasks; ~8K–2M-word contexts	Demonstrates continued difficulty of realistic long-context reasoning beyond literal retrieval	Measures supplied context, not persistence between sessions	https://arxiv.org/abs/2412.15204
MemGPT 32	arXiv 2023 preprint	Hierarchical/OS-inspired virtual context management	Long-document analysis, multi-session chat	Demonstrates explicit paging/context management beyond immediate window	Early models; limited standardized comparative evidence; architectural analogy stronger than causal proof	https://arxiv.org/abs/2310.08560; DOI 10.48550/arXiv.2310.08560
MemoryBank 7	AAAI 2024, peer reviewed	Retrieved conversation memories, user portrait, continuous updates, Ebbinghaus-inspired forgetting	Long-term dialogue; real qualitative and simulated quantitative interactions	Better reported recall, empathy and user-profile understanding	Simulation-heavy; does not isolate whether Ebbinghaus-style decay itself causes improvement	DOI 10.1609/aaai.v38i17.29946; https://ojs.aaai.org/index.php/AAAI/article/view/29946
Generative Agents 33	UIST 2023, peer reviewed	Full experience stream + retrieval + reflection + planning	25-agent simulated town; short multi-day interaction; component ablations	Integrated architecture increases human-rated believability; emergent coordination observed	Simulation and subjective believability, not objective real-world task success	DOI 10.1145/3586183.3606763
Reflexion 34	NeurIPS 2023	Verbal reflections stored across repeated attempts	Coding, reasoning, sequential decision tasks	Large gains in selected tasks; reported HumanEval pass@1 91% vs GPT-4 baseline 80%	Short repeated trials; not enduring user memory; architecture/model comparison not equivalent to longitudinal learning	https://arxiv.org/abs/2303.11366
MemBench 41	Findings of ACL 2025	Various memory-capable LLM setups	Factual vs reflective memory; participation vs observation; effectiveness/efficiency/capacity	Provides broader memory-specific evaluation axes	Construct labels remain benchmark-specific; limited behavioral action	DOI 10.18653/v1/2025.findings-acl.989
Mem0 35	ECAI 2025 proceedings / published record available 2026	Extraction/consolidation/retrieval; optional graph memory	LoCoMo; memory systems, RAG variants, full context and platform baselines	Reported 26% relative judge improvement over OpenAI memory baseline; graph ~2% additional overall; large latency/token savings vs full context	Developer-authored evaluation; LoCoMo/LLM-judge concentration; graph gain modest	DOI 10.3233/FAIA251160; https://arxiv.org/abs/2504.19413
Recursive summarization for long-term dialogue 28	Neurocomputing 2025, peer reviewed	Recursively updated LLM-generated dialogue summary	Long-term dialogue with GPT-3.5-Turbo, Llama, ChatGLM; context/RAG comparisons	Improved automatic and human-rated consistency; complements larger context and retrieval	Does not establish indefinite fidelity or quantify long-run recursive drift under adversarial/dynamic updates	DOI 10.1016/j.neucom.2025.130193
Bhat et al., Rethinking Chunk Size 24	2025 preprint	Fixed-size chunks × embedding models	Multiple short- and long-form retrieval datasets	64–128 often better for concise facts; 512–1024 better for broader context; model-dependent	Retrieval study, not full agent-memory evaluation	https://arxiv.org/abs/2505.21700
How Does Chunking Affect Retrieval-Augmented Code Generation? 25	2026 preprint	Four chunk strategies × four retrievers × five generators	RepoEval and CrossCodeEval; 864 settings	Chunking significant; context budget dominant in many cases; up to +4.2 pp from larger cross-file context; chunk-size effect ≤~1.9 pp	Code domain only; not general document QA	https://arxiv.org/abs/2605.04763
Mittal, “Did You Forget What I Asked?” 47	TrustNLP 2026 workshop	Three model families; persistent formatting/task constraints	>8,000 prompts; varying load/interference	2–21 pp compliance loss under load; some terminal constraints up to 50%; reminders restore many conditions	Within-prompt prospective-memory analogue, not real persistent deferred task	ACL TrustNLP 2026 proceedings
TriggerBench 48	2026 arXiv preprint	Prospective-trigger benchmark with matched retrospective controls	Daily/professional workflows; positive/negative/implicit/overloaded triggers; long context	Prospective recall degrades more sharply than retrospective recall; reasoning can improve hits but also false alarms	Synthetic scenarios; no long wall-clock persistence	https://arxiv.org/abs/2606.23459
LongMemEval-V2 4	2026 arXiv, explicitly work in progress	RAG AgentRunbook-R; file/coding-agent AgentRunbook-C	451 questions, ≤500 trajectories, ≤115M tokens; static/dynamic/workflow/environment/premise	AgentRunbook-C 72.5%; strongest RAG 48.5%; coding-agent baseline 69.3%	QA after evidence gathering, not action; recent preprint; strong baseline shrinks architecture-specific gain	https://arxiv.org/abs/2605.12493; DOI 10.48550/arXiv.2605.12493
Mem2ActBench 13	2026 arXiv preprint	Long-term memory + tool agent	Long interrupted assistant histories; tool selection and argument reconstruction	Explicitly evaluates memory-to-action and parameter grounding rather than only QA	New benchmark; evidence not yet broadly replicated	https://arxiv.org/abs/2601.19935
AgeMem / Agentic Memory 31	2026 arXiv preprint	Agent chooses store/retrieve/update/summarize/discard operations as tools	Unified short-/long-term memory management	Makes maintenance decisions part of agent policy	Architectural promise; too recent for broad independent validation; discard ability ≠ proven beneficial forgetting	https://arxiv.org/abs/2601.01885
Are We Ready For An Agent-Native Memory System? 15	2026 arXiv preprint	12 memory systems + two reference baselines; representation/extraction/retrieval/maintenance decomposition	Five workloads, 11 datasets	Important comparative/factorized evaluation of agent memory systems	Very recent; benchmark external validity still developing	https://arxiv.org/abs/2606.24775
MINJA 38	2025 arXiv preprint	Memory-injection attack against multiple LLM agents	Adversary interacts via normal queries/observed outputs	Demonstrates malicious records can be inserted and later influence victim behavior	Adversarial constructed settings; deployment prevalence unknown	https://arxiv.org/abs/2503.03704
MemoryGraft 37	2025 arXiv preprint	MetaGPT DataInterpreter + GPT-4o; BM25/FAISS persistent experience memory	100 benign + 10 poisoned seeds; 12 handcrafted clean queries	23/48 retrieved records poisoned = 47.9%; persistent unsafe behavioral patterns	Small handcrafted workload; specific ingestion/execution and trust assumptions	https://arxiv.org/abs/2512.16962
Hidden in Memory: Sleeper Memory Poisoning 14	2026 arXiv preprint	Contemporary stateful assistants including GPT-5.5 and Kimi-K2.6	External-content poisoning → memory write → later retrieval → agentic action	Poison write up to 99.8% / 95%; conditional retrieval-to-action success 60–89%	Security PoC/preprint; exact rates depend on attack/system configuration	https://arxiv.org/abs/2605.15338

Most important research gaps

End-to-end causal decomposition. The field needs a benchmark in which the same episodes can be run with controlled interventions at every stage: oracle storage, oracle retrieval, oracle relevance labeling, oracle temporal resolution, oracle interpretation and oracle tool arguments. This would produce a proper error budget—for example, 5% lost at storage, 12% retrieval, 8% conflict resolution and 4% execution—instead of attributing every final error to “memory.” LongMemEval and RAGChecker provide pieces of this decomposition; Mem2ActBench begins extending it to action. 2

Real longitudinal users. A decisive experiment would randomly assign hundreds of consenting users for several months to no persistence, full-history, retrieval memory, summarized memory and structured user-state conditions, using the same base model. Outcomes should include objective task success, time saved, corrections per interaction, preference-application errors, satisfaction, trust, perceived creepiness, deletion requests and inappropriate-personalization incidents. Current conversational benchmarks do not answer this. 49

Mutable-world memory. A serious dynamic benchmark should include hundreds of controlled state transitions: additions, corrections, temporary exceptions, contradictory sources, rescinded preferences, reinstated preferences, retroactive corrections and explicit deletion. Evaluation should score current-state accuracy separately from historical recall and require provenance/temporal justification. LongMemEval and V2 are useful starting points, not the finished benchmark. 2

Prospective memory across real interruptions. TriggerBench should be extended from long prompts to persistent agents that are shut down, restarted, switched between unrelated tasks and exposed to trigger events hours or days later. Both missed intentions and false alarms must count, because an agent that “remembers everything” by acting all the time is not successful prospective memory. 16

Beneficial forgetting. Randomize memory policies over the same workload: retain all, retrieval-only suppression, recency decay, salience decay, learned deletion, explicit user deletion and oracle deletion. Measure current-task performance, future regret, retrieval latency, storage cost, privacy risk and stale-information errors. This experiment would finally distinguish context filtering from true beneficial forgetting. 12

Recursive-summary drift. Feed a ground-truth event ledger through 50–500 sequential summary updates, including subtle corrections and exceptions. At regular checkpoints query every historically relevant proposition and compare current summary state against both the present truth and complete historical record. Vary model, summary budget and compression ratio. The recursive-summarization literature demonstrates benefit, but not the drift curve this experiment would reveal. 28

Memory-to-action transfer. Extend Mem2Act-style evaluation to real applications with calendar, CRM, email, code, browser and database tools. Separate tool choice, entity resolution, parameter grounding, authorization, temporal validity and final environmental state. A high-quality agent-memory claim should eventually report these stages, not only QA accuracy. 13

Architecture factorials rather than architecture bundles. Hold model, corpus, prompts, retrieval budget and tool environment fixed while independently varying raw transcript, summary, dense RAG, BM25, hybrid search, files, SQL state, knowledge graph and agentic search. Most architecture papers change several things simultaneously; the small gap between AgentRunbook-C and its strong coding-agent baseline demonstrates why factorial isolation matters. 4

Memory scale curves. Benchmarks should deliberately grow the store from hundreds to millions of records while holding the fraction of truly relevant memories fixed. Measure retrieval precision, current-state accuracy, stale collisions, latency and action accuracy. “Works with 50 sessions” is not evidence that the architecture behaves well after years of use. LongMemEval-V2’s 115M-token histories are a major step toward this question, although its final task is still evidence-gathering QA. 4

Security under adaptive defenses. Memory attacks should be evaluated jointly with provenance tracking, trust boundaries, write approval, retrieval sanitization, quarantined untrusted memories and deletion. Defenses should be tested against adaptive attackers over repeated sessions, not only fixed attack strings. Current attack evidence is stronger than the evidence for broadly effective defenses. 39

Model-generation replication. The field needs permanent benchmark suites that rerun the same factorial experiments as base models change. The history from Lost in the Middle to RULER, NoLiMa and HELMET shows why an architectural conclusion tied to GPT-3.5-era reading behavior can become obsolete while the underlying evaluation question remains valid. 17

Research frontier versus professionally defensible claims

As of October 3, 2026, these claims are robust enough to use professionally with appropriate qualification:

External retrieval can improve knowledge-intensive QA and factual generation relative to parametric-only baselines when useful evidence is retrieved. 1

Retrieval quality and downstream use are separate failure modes; retrieval recall alone is not enough. 12

Advertised context length is not a reliable measure of useful long-context reasoning or retrieval. Contemporary models have improved, but task difficulty, position and semantic cueing still matter. 19

Full-context prompting can outperform RAG on answer quality when the relevant corpus fits and resources permit, while RAG can be much cheaper. 3

Persistent conversational-memory systems can improve recall/QA on multi-session benchmarks relative to weaker history/retrieval baselines. 2

Records of prior experience can improve subsequent task attempts in selected agentic settings. 9

Prospective use of remembered intentions is measurably harder than retrospective recall and is vulnerable to interference and false triggering. 10

Persistent memory creates a demonstrated cross-session security surface: poisoned memories can survive, be retrieved later and alter actions. 14

The following are promising research directions but not yet robust enough to present as established professional facts:

AgeMem-style autonomous store/update/forget policies; code-agent/file-system memory as a generally superior alternative to RAG; MemHarness-style reconstruction of past experiences before action; proactive memory agents that autonomously decide when an old memory matters; general-purpose skill extraction from episodic traces; human-inspired consolidation and forgetting schedules; knowledge-graph superiority; reliable lifelong preference adaptation; and memory systems that demonstrably make users better off the longer they use them. These ideas now have increasingly serious benchmarks around them, but the strongest evidence is recent and frequently preprint-only. 31

The most defensible synthesis is therefore deliberately unromantic:

LLM “memory” is not one capability. It is a pipeline for preserving old information and making it causally useful later. The field has convincing evidence for several components—retrieval, selected long-context use, benchmarked cross-session recall, and some experience-to-action transfer—but much weaker evidence that today’s memory architectures reliably maintain changing state, preserve deferred intentions, forget beneficially, personalize users correctly over long periods, or produce cumulative real-world improvement.

The architectural intuition is ahead of the longitudinal evidence. The next decisive step is not another memory metaphor or storage layer. It is evaluation that follows information all the way from storage, through retrieval and interpretation, into consequential behavior over time. 12

Production Context and Memory Systems: A Practitioner Evidence Dossier

Research snapshot: October 3, 2026

The central operational conclusion is that a reliable production memory system should not be designed as “a vector database that remembers things.” It should be designed as a controlled information lifecycle in which evidence is admitted, interpreted, versioned, scoped, retrieved, challenged, superseded, forgotten, and traced. Long-term retrieval benchmarks continue to show substantial failures in knowledge updates, temporal reasoning, abstention, conflict handling, and long-range understanding; simply making more text retrievable does not solve those problems. 1

The architecture I would deploy today is comparatively conservative:

Keep raw evidence immutable, keep operational state deterministic, make durable memory structured and provenance-bearing, retrieve through hard scope/time/permission filters before semantic ranking, and treat every automatically created memory as a derived assertion rather than ground truth.

Persistent memory should be smaller and harder to write than most current agent implementations make it. Automatic memory creation is a new trust boundary: both AgentPoison and MINJA demonstrate that maliciously constructed interactions can poison long-term memory or RAG stores and later influence behavior, including without direct database access. 2

Executive operating model

A useful production decomposition is not “short-term versus long-term memory.” The distinctions that carry the most operational leverage are authority, durability, scope, mutability, provenance, and whether a datum is evidence or a derived interpretation. Contemporary frameworks are beginning to reflect this separation: LangGraph distinguishes thread-scoped state from long-term namespaced stores, while Google ADK separates session events/state from searchable long-term knowledge. 3

The recommended information flow is:

text

CONTROL PLANE<br> authn ─ tenant ─ permissions ─ policies ─ tool scopes<br> │<br> ▼<br> CONTEXT ASSEMBLER<br> │<br> ┌───────────────────┼────────────────────┐<br> │ │ │<br> privileged deterministic evidence plane<br> instructions task state + memory plane<br> │ │ │<br> │ │ raw events / documents<br> │ │ structured business data<br> │ │ durable memories<br> │ │ project/org knowledge<br> │ │ retrieved tool results<br> │ │ │<br> └───────────────────┴────────────────────┘<br> │<br> filtered / reranked /<br> conflict-resolved /<br> budgeted context<br> │<br> ▼<br> LLM<br> │<br> proposed answer or action<br> │<br> ▼<br> ACTION POLICY GATE<br> re-check permissions + parameters<br> │<br> ▼<br> tool / user<br> │<br> ▼<br> immutable event log<br> │<br> MEMORY ADMISSION GATE<br> │<br> candidate → validate → promote<br> │<br> ▼<br> durable derived memory<br>

The control plane must remain outside the model. Authentication, tenant selection, data permissions, tool authorization, allowed side effects, and destructive-action policies cannot merely be prose that the model is expected to remember. Prompt-injection research exists precisely because an LLM may fail to maintain a hard distinction between trusted instructions and untrusted data; OWASP continues to rank prompt injection as a primary GenAI security problem. 4

The evidence plane should be distinct from the memory plane. A transcript line, CRM record, source document, or tool response is evidence. “Radek prefers Slack” extracted from a conversation is an assertion derived from evidence. “Radek generally dislikes email” may be a further inference. Those three objects should not be interchangeable. That separation is what makes correction, provenance, temporal reasoning, and deletion tractable. Architectures such as A-MEM and Graphiti similarly move beyond undifferentiated text chunks toward richer memory representations and relationships; Graphiti additionally models changing facts temporally and retains source relationships. 5

A practical default for a new system is therefore:

Layer	Recommended representation	Default durability	May directly authorize an action?
Security/permissions	deterministic ACL/policy state	current	Yes, as enforcement
System/developer behavior	versioned configuration/instructions	release-scoped	Only through policy
Current request	raw current user input	event log	No
Workflow/task state	typed records/checkpoints	workflow lifetime	Yes, where application logic says so
Raw interaction history	immutable events	retention-policy dependent	No
User/project memory	structured assertions	cross-session	No
Organizational/business knowledge	authoritative source records + indexes	source-controlled	Only if business logic permits
Retrieved content/tool results	source-labelled evidence	request/event	No
Summaries	derived, regenerable artifacts	cache/session	No
Procedural knowledge	reviewed prompt/code/skill versions	release-controlled	Potentially, after policy review
Archive	cold evidence/history	policy dependent	No

The important asymmetry is deliberate: many things may inform the model; very few things should independently determine what the system is allowed to do. Security research on poisoned memories and real-world isolation bugs make that separation more than an architectural nicety. 6

Context assembly reference model

Context-assembly reference model. Anthropic frames context engineering as selecting the highest-utility tokens from system instructions, tools, external data, history, and other evolving state, and recommends the smallest high-signal context that is sufficient for the task. Its production guidance also notes that agents can become distracted by stale/off-topic context and that long-horizon systems require compaction, external notes, or just-in-time retrieval rather than unrestricted accumulation. 7

The key operational distinction is between logical precedence and physical ordering. Do not assume that putting text earlier in a prompt magically gives it higher authority. Instruction-hierarchy research explicitly studies the need for models to prioritize privileged instructions over lower-trust instructions, while prompt-injection work shows that models do not provide the kind of hard command/data boundary conventional security systems provide. 8

I would assemble each model call in the following logical order:

Logical class	What belongs there	Conflict rule
Privileged behavior	system/developer instructions, safety constraints, role definition	Highest model-level authority; version controlled
Permission manifest	user/tenant identity, allowed resources/actions, risk policy	Machine enforced; model cannot override it
Current objective	latest user request, active task objective	Current explicit instruction normally beats older user preferences within user-controlled scope
Deterministic task state	workflow phase, completed steps, pending approvals, IDs, deadlines, receipts	Database/checkpoint is authoritative
Active constraints	explicit preferences relevant to this request, project rules	Scope + validity + explicitness determine priority
Authoritative domain evidence	current prices, customer status, policy records, inventory, etc.	Source authority + temporal validity
Retrieved supporting evidence	documents, previous events, durable memories	Evidence only; no privilege escalation
Recent dialogue	turns required for local coherence	Current turn dominates obsolete conversational assumptions
Compressed history	unresolved decisions, commitments, relevant history	Derived; original events remain authoritative
Tool results	outputs from current tool calls	Treat according to tool/source trust; generally data, not instructions

LangGraph’s current documentation explicitly treats short-term history as part of thread state, long-term memory as a separate namespaced store, and notes that long histories can distract models with stale or off-topic information while increasing cost and latency. 3

Context selection should happen before token rendering. A robust assembler can use the following pipeline:

• Resolve tenant_id, user_id, project/workspace, roles and current tool permissions outside the LLM.

• Classify the task and extract relevant entities, temporal ranges, resources and memory categories.

• Read the deterministic workflow checkpoint.

• Retrieve separately from the stores authorized for that scope.

• Reject candidates that violate tenant, ACL, sensitivity, validity-period or deletion constraints.

• Resolve supersession and known contradictions before ranking.

• Rank remaining candidates by relevance plus authority, temporal applicability, provenance quality and novelty.

• Diversify near-duplicate candidates.

• Allocate a token budget by context class rather than taking a global top-K.

• Render context with IDs, source/validity labels and clear data/instruction boundaries.

• Generate.

• Before any external action, re-check permissions and action parameters outside the model.

• Persist a context manifest so the call can later be reconstructed.

This is an architectural synthesis rather than a standardized algorithm, but its pieces are supported by long-memory benchmarks, temporal-memory work, current framework separation of state and memory, and security research showing why scope and trust need to precede model interpretation. 1

A useful candidate utility function is conceptually:

[

U(m,q) = R(m,q) \\times A(m) \\times T(m,t) \\times P(m) \\times S(m)

D(m,C)

X(m) ]

where R is relevance, A source authority, T temporal applicability, P provenance quality, S scope compatibility, D redundancy with context already chosen, and X penalties for contradiction, staleness or trust risk. This is not a recommendation to blindly collapse everything into one learned score: access restrictions, deletion, scope mismatches and explicit invalidation should be hard filters rather than weak ranking features. That recommendation follows directly from the security and cross-tenant failure evidence discussed later. 9

Preventing context crowd-out. There are four high-leverage controls.

First, reserve budgets. Do not allow retrieved documents to consume the space needed by the current goal, active constraints and workflow state. Second, deduplicate before rendering. Third, retrieve progressively: a compact index/result list first, full content only when needed. Anthropic describes this as progressive disclosure or just-in-time context and reports using lightweight references plus targeted retrieval in agentic workflows. 7

Fourth, aggressively remove obsolete bulk. Anthropic specifically identifies old tool outputs as low-hanging compaction candidates, while warning that overly aggressive summarization can lose details whose importance becomes visible only later. 7

This matters even within nominal context limits. Lost in the Middle found that models often performed substantially better when relevant evidence occurred near the beginning or end of long contexts than when it appeared in the middle. 10 Chroma’s later Context Rot experiments similarly reported degradation as additional context was introduced, reinforcing that “fits in the window” is not equivalent to “will be used reliably.” 11

The operational rule is therefore:

Do not maximize context utilization. Maximize expected decision utility per token.

That rule is consistent with Anthropic’s production guidance and with long-context empirical results. 7

Memory architecture and write lifecycle

Memory-tier architectures. The industry often discusses semantic, episodic and procedural memory, a distinction also reflected in LangChain’s current conceptual documentation and in CoALA’s cognitive architecture. 3 But for production engineering, I would organize storage around failure containment rather than psychology.

A maintainable architecture usually needs six or seven logical stores, though several can share the same physical database.

Store	Purpose	Why it should be separate
Working context	current model call, ephemeral scratch, current tool results	No reason to pollute durable history
Workflow state/checkpoints	what the process is doing now	Must be exact, typed, recoverable and idempotent
Evidence/event store	raw messages, tool events, source snapshots, action receipts	Provides reconstruction and correction
Durable semantic memory	facts, preferences, stable relationships and learned constraints	Needs update/supersession logic
Episodic/experience store	past actions, outcomes, environment events, failures	Useful for “what happened before?” and runbook learning
Knowledge corpus	project/org documents and structured business data	Source ownership and freshness differ from personal memory
Procedural/configuration store	skills, prompts, runbooks, operating rules	Has a much stronger trust requirement than ordinary memories
Cold archive	old raw data that should not participate in normal retrieval	Keeps audit/recovery without crowding live memory

Google ADK independently separates single-conversation session events/state from long-term searchable memory and offers both extracted memory and full-conversation RAG variants, illustrating that raw history and interpreted memory answer different operational needs. 12

User memory and project memory do not necessarily need different databases. They need non-negotiable scopes or namespaces. LangGraph’s long-term stores support custom namespaces; this is the right conceptual direction because scope is a retrieval/security property, not merely a prompt-labeling convention. 3

Task state versus memory. This is one of the most important distinctions in the dossier.

“What happened in this workflow?” should be represented by durable workflow state: identifiers, status transitions, inputs, completed side effects, pending approvals, retry counters, transaction receipts and deadlines.

“What is generally worth remembering?” belongs in memory.

LangGraph explicitly stores thread state through checkpoints, and Google ADK explicitly distinguishes temporary conversation state from long-term searchable memory. 3

A long-running purchasing agent, for example, should not “remember” in prose that:

“I think I already sent the purchase order.”

It should have typed state such as:

text

purchase_order.status = SENT<br>purchase_order.id = PO-48219<br>purchase_order.sent_at = 2026-10-03T13:41:22Z<br>purchase_order.tool_receipt = ...<br>purchase_order.idempotency_key = ...<br>

The prose may be useful context, but the typed state is what prevents duplicate side effects. That recommendation follows the durable-state architecture of modern agent frameworks and ordinary transaction-safety principles; it should be verified with interruption/replay tests in each implementation. 3

The same rule applies to prospective memory. “Remind the customer next Thursday” is not safely implemented as a vector-retrievable note. It needs a scheduler/workflow record with a deterministic trigger; memory may provide the contextual explanation when the trigger fires.

Memory write/promotion patterns. Current systems expose several write pathways. Google ADK supports completed-session ingestion, incremental event ingestion, and explicit memory entries; LangGraph describes both hot-path writes and background memory creation. 12

There is no credible evidence that one write mode universally dominates. The practical trade-offs are:

Write mechanism	False positives	False negatives	Latency	Cost	Auditability	Correction
Explicit user “remember this”	Low	High	Low	Low	Excellent	Excellent
Deterministic extraction from typed fields/events	Low where schema fits	High outside schema	Very low	Low	Excellent	Excellent
Model-selected hot-path write	Medium–high	Medium	Adds turn latency	Medium	Moderate	Good if provenance retained
Post-session extraction	Medium	Medium	Off critical path	Medium	Good	Good
Background synthesis/consolidation	Medium	Medium	Eventual consistency	Medium–high	Moderate	Harder
Repeated-observation promotion	Lower FP	Higher/delayed FN	Delayed	Medium	Good	Good
Human-reviewed promotion	Very low	Depends on reviewers	High	High	Excellent	Excellent

These ratings are an operational synthesis rather than results of a head-to-head benchmark. Framework documentation establishes the available patterns, while systems such as Mem0, A-MEM and Generative Agents demonstrate various model-driven extraction/reflection approaches rather than proving their universal reliability. 3

My production default would be a three-lane write path:

Lane A — deterministic. Explicit preference changes, application settings, accepted user profile fields, approvals and workflow state are written directly through typed APIs.

Lane B — candidate memory. A model may propose new facts/preferences/episodes, but they enter a staging area with provenance and confidence rather than becoming authoritative immediately.

Lane C — reviewed/high-impact. Procedural rules, security-sensitive facts, organization-wide knowledge, financial/payment instructions and changes that could authorize consequential actions require stronger source authority or human/workflow approval.

This design directly addresses the security implication of MINJA: if ordinary conversation can cause the LLM to write trusted persistent state, the attacker has acquired a durable influence channel. 13

Repeated observations can promote confidence, but only after lineage deduplication. Five summaries ultimately derived from the same user sentence are one observation, not five independent confirmations. This is one reason provenance needs to survive consolidation.

Schema, provenance, consolidation, updates and forgetting

Memory schema and provenance. Free-text memory is attractive because it is easy to build. It becomes painful when the system must answer “which current preference does this supersede?”, “was this user-stated or inferred?”, “which customer does this concern?”, “is it still valid?”, “which source produced it?”, or “must this be deleted?”

A durable memory record should therefore look more like a versioned assertion than a note:

Field	Operational purpose
memory_id	stable identifier
tenant_id / workspace_id	isolation boundary
scope	user, project, organization, task, etc.
subject_id	canonical entity
memory_type	fact, preference, event, relationship, procedure
predicate	e.g. preferred_contact_channel
value	normalized machine-readable value
original_text	source-faithful evidence excerpt where permitted
assertion_mode	explicit, extracted, inferred, synthesized
source_id / locator	raw event/document/tool record
source_version / hash	exact version used
observed_at	when evidence was observed
valid_from / valid_to	when it applies in the represented world
ingested_at	when system learned it
authority_class	user-direct, system-of-record, inferred, unknown
confidence	extractor uncertainty—not a probability of objective truth
sensitivity	privacy/security classification
owner	responsible subject/system
access_policy	who can read/use it
status	candidate, active, superseded, quarantined, deleted
superseded_by	replacement memory
expires_at / review_at	lifecycle control
dependencies	upstream memories/evidence used to derive it
extractor_version	model/parser/prompt version
embedding_version	retrieval reproducibility
write_reason	explicit, rule, consolidation, operator action

Not every application needs every field. The evidence for structured representations is directional rather than definitive: A-MEM creates structured notes with contextual descriptions, keywords and evolving links; Graphiti models temporal relationships and source-linked events; LangGraph’s own documentation notes that structured JSON profiles are useful but become error-prone as profiles grow, motivating stricter schemas or smaller documents. 5

That last point is important: structured memory does not mean “one giant user JSON blob.” LangGraph explicitly warns that continuously rewriting larger profiles becomes error-prone and contrasts this with collections of narrower memory objects, which avoid repeatedly regenerating an entire profile at the cost of more search/update complexity. 3

Provenance model. Each downstream artifact should be traceable through:

text

source event/document<br> ↓<br>source version/hash<br> ↓<br>extraction run<br> model/parser version<br> prompt/rule version<br> ↓<br>candidate assertion<br> ↓<br>promotion / merge / supersession decision<br> ↓<br>durable memory version<br> ↓<br>retrieval event<br> query + filters + scores<br> ↓<br>context-manifest entry<br> ↓<br>model call/version<br> ↓<br>answer or proposed action<br> ↓<br>action validation<br> ↓<br>tool side effect / receipt<br>

This mirrors provenance ideas used in other high-integrity domains: provenance systems record what artifact was produced, from what inputs and by which process so that production can later be verified or reconstructed. 14

With such lineage, an operator can answer:

• Why was this remembered? Follow write_reason and extraction run.

• Where did it come from? Follow source_id and source version.

• Was it inferred? Inspect assertion_mode.

• Does the source still exist? Resolve source and tombstone state.

• Which version was retrieved? Inspect retrieval/context manifest.

• Which output depended on it? Reverse-query context manifests/action traces.

These capabilities are architectural recommendations derived from provenance practice and the need to reconstruct memory-induced failures, not claims that current memory frameworks universally provide them. 14

Consolidation and deduplication. Treat consolidation as a materialized-view pipeline over immutable evidence:

text

raw events<br> ↓<br>candidate assertions<br> ↓<br>entity resolution<br> ↓<br>duplicate candidate search<br> ↓<br>classify relationship:<br> exact duplicate<br> equivalent paraphrase<br> refinement<br> temporal successor<br> contradiction<br> independent corroboration<br> unrelated<br> ↓<br>update derived memory graph/collection<br>

The dangerous operation is not summarization itself; it is allowing a generated summary to replace the evidence from which it was generated.

Generative Agents demonstrated the usefulness of synthesizing higher-level reflections from an experience stream, while newer memory systems such as Mem0 and A-MEM implement extraction, consolidation or evolving memory representations. 15 Those systems establish that consolidation can improve downstream performance; they do not establish that generated consolidations are truth-preserving.

The safe rule is:

Raw events are append-only evidence; memories and summaries are rebuildable views.

An inferred memory should never silently become a “source” with the same authority as its upstream observation. Otherwise one extraction hallucination can be repeatedly summarized, duplicated, embedded and eventually treated as corroboration.

For deduplication, exact hash or normalized-key matching should precede embedding similarity. Semantic similarity is useful for finding candidate duplicates but should not be allowed to merge assertions whose temporal periods, entities, scope or predicates differ. A statement that “Plan A costs €20 in 2025” is not a duplicate of “Plan A costs €30 from January 2026” merely because the sentences are almost identical.

Conflict and update management. Do not use naive last-write-wins for semantic truth.

Consider:

Monday: “I prefer email.”
October: “Please stop emailing me; use Slack.”

These are not contradictory records to collapse. They are a temporal sequence.

A sensible representation is:

text

preferred_channel = email<br>valid_from = t1<br>valid_to = t2<br>source = explicit user statement<br>status = superseded<br><br>preferred_channel = slack<br>valid_from = t2<br>valid_to = null<br>source = explicit user statement<br>status = active<br>

A separate explicit negative constraint could record email_allowed = false if the domain needs it.

Temporal knowledge systems such as Graphiti explicitly distinguish changing facts and preserve temporal relationships rather than overwriting all history, making this pattern practical for agent memory. 16

For conflicting business prices, the correct choice may have nothing to do with which record entered the vector store last. Resolve in roughly this order:

scope/access → applicable validity interval → source authority → explicitness/directness → source version → independent corroboration → recency of the underlying fact → extraction confidence.

A current billing database may therefore beat yesterday’s scraped website; a contract effective next month should not replace today’s current price simply because it has the newest publication timestamp.

A bitemporal representation improves debugging by distinguishing valid time—when the assertion was true in the domain—from system time—when the AI system learned or stored it. Temporal graph-memory work uses this type of distinction to represent evolving information. 16

When authoritative sources genuinely disagree and the system cannot resolve the conflict, ambiguity should survive retrieval. Hiding disagreement behind a ranker converts uncertainty into false confidence. LongMemEval explicitly includes knowledge updates and abstention among the competencies that long-term memory systems must handle. 1

Forgetting and deletion. There are at least six different operations that teams casually call “forgetting”:

Mechanism	Meaning
TTL	stop using item after a defined time
relevance decay	lower retrieval priority as usefulness declines
confidence decay	reduce trust absent refresh/corroboration
eviction	remove from fast storage but possibly retain in archive
source invalidation	disable derived assertions because upstream source changed/disappeared
explicit deletion	remove information due user/operator/policy request

MemoryBank explored time/importance-based forgetting and reinforcement, showing that decay-style policies are a viable research pattern, but this remains workload-dependent rather than a universally validated production rule. 17

Deletion deserves separate engineering because data may exist in multiple materializations. OpenAI’s current consumer memory documentation is a useful concrete illustration: it explicitly states that deleting a chat does not necessarily delete a separately stored saved memory and that removing remembered information can require addressing multiple sources; deletion and memory updates can also take time to propagate. This is product-specific behavior, not a prescription, but it demonstrates the general danger of assuming one delete operation covers every derived representation. 18

A production deletion graph should therefore look like:

text

delete source S<br> │<br> ├── tombstone S immediately<br> ├── suppress all retrieval of S<br> ├── find derived assertion IDs<br> │ ├── delete/recompute memories<br> │ ├── recompute summaries<br> │ └── invalidate graph edges<br> ├── remove embedding/index records<br> ├── invalidate prompt/retrieval caches<br> ├── update derived materialized views<br> ├── publish delete event to downstream indexes<br> └── record purge status for archives/backups<br>

The important distinction is logical deletion versus physical erasure. The query path should stop returning a deleted object immediately via tombstones even if physical cleanup of indexes or retained backups takes longer. Restoring an old backup should replay deletion/tombstone events before serving traffic. These are operational recommendations that must be tested against the actual persistence/index/backup technologies used.

Do not decay everything uniformly. A restaurant preference may reasonably expire; a user’s birthday does not become less true because it is old; an API endpoint may become obsolete rapidly; a historical event should remain historically true forever. Forgetting policy belongs to the schema or memory type.

Retrieval, compaction and long-context strategy

Retrieval patterns. No single retrieval mechanism covers the heterogeneous information that memory systems store.

Mechanism	Strongest use	Characteristic failure
Dense/vector similarity	paraphrases, thematic similarity	semantically similar but wrong entity/time
Lexical/BM25/full-text	IDs, names, exact terminology, numbers	misses paraphrases
Hybrid lexical + dense	broad general-purpose baseline	still requires filtering/reranking
Metadata filtering	scope, user, project, type, date, authority	bad metadata causes hard false negatives
Entity retrieval	known people/projects/accounts	entity-resolution mistakes
Recency retrieval	recent events/tasks	overvalues recent but irrelevant material
Graph traversal	relations, multi-hop and temporal dependency	schema/graph complexity and noisy edges
Learned reranking	difficult semantic discrimination	model cost, drift and opacity
Model-selected recall	exploratory/agentic evidence gathering	latency, non-determinism, missed search paths

Google ADK illustrates keyword, semantic and vector-backed memory variants in a single framework, while temporal graph systems combine vector, lexical and graph retrieval. 12

The strongest default I would test first is:

hard scope/permission/time filters → hybrid lexical+dense candidate generation → reranking → dedup/diversification → calibrated acceptance threshold.

Vector similarity must not decide tenancy or permissions.

LongMemEval found that session decomposition, fact-enriched retrieval keys and time-aware query expansion improved retrieval and downstream memory question answering, indicating that retrieval quality depends materially on representation and query construction rather than simply embedding raw conversation chunks. 1

Query rewriting should therefore include relevant entities, aliases and time windows where confidence is high, but both the original and rewritten query should be logged because rewrite drift becomes another failure mode.

Top-K is a tuning parameter, not architecture. Larger K increases recall until extra results become noise; long-context evidence shows that additional irrelevant material can actively hurt model performance. 10 Test K against end-to-end task accuracy, not retrieval recall alone.

A good fallback strategy is progressive:

text

high-confidence structured memory<br> ↓ insufficient<br>hybrid search over active evidence<br> ↓ insufficient<br>raw/session event search<br> ↓ insufficient<br>source/tool exploration just in time<br> ↓ still insufficient<br>abstain / obtain new evidence<br>

That approach matches the progressive-disclosure strategy Anthropic describes and avoids converting a retrieval miss into a fabricated memory. 7

LongMemEval-V2 provides interesting 2026 evidence in favor of this more agentic retrieval model. Its history sets can contain up to 500 trajectories and 115 million tokens; a file-oriented coding-agent evidence gatherer reached 72.5% average accuracy, compared with 48.5% for the strongest RAG baseline reported by the authors, although they explicitly note substantially higher latency for coding-agent methods. 19 This is a benchmark/preprint result rather than production proof, but it is an important warning against assuming that one-shot vector top-K retrieval is the endpoint of memory architecture.

Long context versus retrieval versus memory.

Strategy	Best fit	Advantages	Main liabilities
Raw long context	bounded one-off histories; exact replay; small corpus	Simple; no indexing; highly reconstructable	token/latency cost, middle-position effects, irrelevant/conflicting history
RAG/retrieval	large external corpus; source-grounded lookup	selective, scalable, independently refreshable	retrieval misses, stale indexes, ranking complexity
Structured durable memory	repeated users/projects/tasks; evolving preferences/facts	update semantics, compact context, personalization	difficult write path, poisoning, inference errors
Agentic/JIT search	very large/dynamic environments	can explore based on emerging task	latency, cost, non-determinism
Hybrid	most serious production agents	complementary strengths	most operational complexity

Lost in the Middle provides strong empirical evidence against assuming that nominal context length equals dependable access to all tokens. 10 Chroma’s Context Rot report extended this observation across larger token loads. 11 LongMemEval reported substantial degradation for assistants and long-context models across sustained interactive histories and specifically evaluates extraction, multi-session reasoning, temporal reasoning, updates and abstention. 1

At the same time, do not infer from those results that every application needs an elaborate memory stack. Anthropic explicitly recommends doing the simplest thing that works and describes direct file/reference navigation as a way to avoid stale indexing in some agentic workflows. 7

The graph-memory case is particularly worth being skeptical about. In the Mem0 authors’ LoCoMo evaluation, the graph extension improved the reported overall result by roughly 2% over base Mem0, while the reported average memory footprint rose from about 7k to 14k tokens. 20 That does not show graphs are bad; it shows that graph complexity should have to earn its production cost on your multi-hop/temporal workload.

The same Mem0 paper reports 91% lower p95 latency and more than 90% token-cost savings compared with its full-context baseline. 20 Those are vendor-authored empirical results on a particular benchmark and configuration, not a general expectation for production systems.

Summarization and compaction. Different compression strategies fail differently.

Technique	Good for	Main risk
Rolling summary	continuous chat	cumulative summary drift
Hierarchical summaries	very long histories	compounded omissions/errors
Structured summary	known fields/constraints	schema may omit unexpected future-relevant facts
Event extraction	preserving discrete happenings	loses conversational nuance
Task-state extraction	workflows	model-generated state may be wrong unless validated
Deterministic trimming	predictable budgets	removes context without understanding importance
Tool-result clearing	repeated agent loops	may remove evidence needed later

Anthropic reports using compaction for long-horizon tasks and recommends first optimizing summary prompts for recall, then reducing superfluous content; it also warns that overly aggressive compaction can discard details whose importance becomes apparent only later. 7

The safest compaction architecture is:

text

immutable raw trace<br> +<br>typed current task state<br> +<br>versioned structured summary<br> +<br>last N relevant raw turns<br> +<br>on-demand retrieval into older evidence<br>

The summary should contain decisions, unresolved questions, active constraints, identifiers, commitments, outstanding errors, important results and references back to supporting events. It should not become the only surviving representation of history.

Summary drift is a lineage problem as much as a language-model problem. If summary version 12 summarizes version 11, which summarized version 10, errors become increasingly difficult to distinguish from source observations. Periodically rebuild important summaries from raw evidence rather than perpetually summarizing summaries. This is an operational inference supported by the known compaction/omission risk and by the broader principle that derived memory should remain reconstructable. 7

Evaluation, observability, security and economics

Evaluation suite. Memory quality cannot be judged by “the system successfully retrieved stored text.” LongMemEval already evaluates extraction, multi-session reasoning, temporal reasoning, knowledge updating and abstention; MemoryAgentBench extends evaluation toward retrieval, test-time learning, long-range understanding and conflict resolution. 1

A production suite should explicitly contain the following scenarios:

Test	Setup	Required outcome	Primary metrics
Correct recall	relevant durable fact exists	recall and use correct version	end-to-end accuracy; recall@K
Correct non-recall	similar but irrelevant memory exists	omit it	false-recall rate
Preference change	email → later Slack	use Slack; old preference retained historically but inactive	stale-use rate
Contradictory sources	two current prices with authority metadata	choose authoritative/valid one or expose ambiguity	conflict-resolution accuracy
Stale memory	expired address/API/policy	reject stale entry	stale-use rate
Irrelevant memory	many highly similar distractors	maintain task accuracy	precision; distraction impact
Duplicate memory	paraphrased duplicate assertions	avoid confidence amplification/context duplication	duplicate exposure rate
Missing memory	required item absent	search elsewhere or abstain	unsupported-answer rate
Memory in tool parameters	stored shipping/contact value feeds tool call	correct parameter and current permission	exact parameter accuracy; action success
Prospective memory	future commitment	deterministic trigger at correct time	trigger precision/recall; lateness
Deletion	create → retrieve → delete	no retrieval from any live representation	deletion residue; propagation time
Permission boundary	memory exists but user lacks access	never retrieve/use it	unauthorized recall rate = zero target
Adversarial injection	malicious conversation/document attempts persistence	reject/quarantine or neutralize	poison-write rate; attack success
Cross-user isolation	semantically identical data for users A/B	never cross boundary	cross-user leakage = zero target
Interrupted long task	crash/restart after partial side effects	resume exact state without repeating effects	recovery accuracy; duplicate-side-effect rate

For each scenario, evaluate four layers separately:

text

WRITE<br>Did the right memory get created?<br><br>RETRIEVAL<br>Did the right candidates appear?<br><br>CONTEXT<br>Did the correct evidence reach the model<br>without dangerous/irrelevant competitors?<br><br>BEHAVIOR<br>Did the final answer or external action do the right thing?<br>

A memory architecture can score well on recall and still be a bad system if it causes the wrong invoice, uses a superseded address, sends email after consent was revoked, or leaks another tenant’s data.

LongMemEval’s explicit inclusion of abstention and knowledge updates supports testing negative behavior, not just recall. 1 MemoryAgentBench’s focus on conflict resolution and long-range behavior likewise argues for end-to-end evaluation rather than isolated vector-search metrics. 21

For retrieval, measure at least precision/recall at candidate and final-context stages, MRR or nDCG where rankings matter, wrong-scope retrieval rate, stale-result rate, duplicate-result ratio, conflict coverage and abstention quality. For production behavior, add action correctness, tool-parameter correctness, constraint violations, side-effect retries, permission violations and task completion.

Observability model. Every model call should have a reconstructable context manifest:

text

trace_id / request_id<br>tenant/workspace/user scope<br>task/workflow/checkpoint version<br><br>model + model version<br>system/developer prompt version<br>summary version<br><br>retrieval:<br> original query<br> rewritten query<br> store/index version<br> filters<br> candidate memory IDs<br> candidate scores<br> reranker version<br> accepted/rejected IDs + reason<br><br>memory mutations:<br> created candidates<br> promotion decision<br> merged/superseded IDs<br> deleted IDs<br> source IDs<br> extractor model/rule version<br><br>context:<br> ordered context-item IDs<br> token counts by layer<br> source/authority labels<br><br>output:<br> generated response/action proposal<br> dependency memory IDs<br><br>tools/actions:<br> permission snapshot<br> tool + version<br> validated parameters<br> result/receipt<br>

OpenTelemetry provides a vendor-neutral framework for traces, metrics and logs and is an appropriate substrate for connecting memory/context events to normal distributed-system telemetry. 22

Do not solve observability by dumping all prompts, memories, retrieved documents and outputs indefinitely into a logging warehouse. That simply creates a second, weakly governed memory system. OWASP separately identifies sensitive-information disclosure as a GenAI risk, and the underlying principle applies directly to telemetry. 4

Prefer stable IDs, hashes, metadata and redacted previews in routine logs. Full payload capture should be limited, access-controlled, encrypted, retention-bound and intentionally enabled for debugging or evaluation datasets.

Useful operational dashboards include:

• memory writes per active user/task;

• automatic-write acceptance/rejection rates;

• duplicate and contradiction rates;

• retrieval candidate count versus rendered count;

• stale-memory retrieval rate;

• source-missing rate;

• memory growth per user/project;

• summary compaction ratio and regeneration count;

• p50/p95 retrieval and consolidation latency;

• cross-scope query attempts;

• deletion propagation latency;

• percentage of tool actions influenced by durable memory;

• rollback/recovery frequency.

Security controls. Persistent memory creates a new attack surface because a malicious input that survives the current conversation can influence future sessions.

AgentPoison demonstrated backdoor attacks on RAG-equipped agents by inserting very small amounts of poisoned long-term memory/knowledge-base content; the paper reports strong attack success while having minimal measured impact on benign behavior in its evaluated settings. 23

MINJA goes further: it demonstrates memory injection through normal query interaction and output observation, without requiring direct write access to the memory database. 24 Later 2026 work investigating memory poisoning under more realistic pre-existing-memory conditions found that attack effectiveness could drop substantially and that defensive trust thresholds involve precision/recall trade-offs, so the extreme attack rates in idealized settings should not be treated as universal production estimates. 25

This evidence strongly favors a separate memory-admission boundary:

text

model/user/tool observation<br> ↓<br>candidate memory<br> ↓<br>SOURCE TRUST CHECK<br> ↓<br>SCHEMA + TYPE VALIDATION<br> ↓<br>SCOPE / TENANT CHECK<br> ↓<br>SENSITIVITY CLASSIFICATION<br> ↓<br>PROMPT-INJECTION / CONTENT-RISK CHECK<br> ↓<br>CONTRADICTION + DUPLICATE CHECK<br> ↓<br>AUTHORITY / IMPACT POLICY<br> ├── reject<br> ├── quarantine<br> ├── human review<br> └── promote<br>

Normal model generation should not have unrestricted INSERT INTO memories.

Retrieved content likewise must arrive labelled as untrusted evidence, not as privileged instructions. OWASP explicitly recognizes direct and indirect prompt injection, and OpenAI’s public agent security material describes third-party content encountered during agentic tasks as a prompt-injection risk. 4

Procedural memory deserves particularly strong isolation. Letting user-provided documents automatically evolve durable “rules for how the agent should behave” converts ordinary data ingestion into configuration/code modification.

For memory-based exfiltration, apply ACLs before retrieval, not after the model has seen candidates. Sensitive memories should carry sensitivity classification and allowed principals, and retrieval credentials should be request-scoped.

The importance of request-scoped isolation has direct 2026 practitioner evidence. A Graphiti GitHub issue reported that shared mutable database-driver state under concurrent different group_id requests could silently persist an episode into the wrong graph. The reporter described 19 misplaced episodes across five graphs in production; crucially, no error was raised. 26

The merged fix replaced shared mutation with a request-scoped driver/client bundle. 27 This is self-reported open-source production evidence rather than an independently audited incident, but it provides an unusually concrete example of how a memory system can cross isolation boundaries despite correct-looking application-level group IDs.

Therefore test isolation under concurrency, retries and failures, not just sequential unit tests.

Cost/performance trade-offs. A meaningful memory cost model is:

[ C_{total} = C_{inference} + C_{retrieval} + C_{indexing} + C_{writes} + C_{summarization} + C_{consolidation} + C_{storage} + C_{observability} + C_{maintenance} + C_{errors} ]

The last two terms are commonly ignored.

Measure:

Area	Metrics
Context	input tokens/task; tokens by context layer; compaction ratio
Retrieval	p50/p95/p99 latency; candidates scanned; reranker calls
Writes	LLM/extractor calls; write amplification; promotion rate
Indexing	embeddings generated; bytes/index growth; reindex duration
Consolidation	jobs/user/day; tokens/job; backlog age
Storage	raw bytes, memories/user, graph edges, archive growth
Deletion	fan-out operations; purge completion latency
Reliability	stale/incorrect memory incidents per task
End-to-end	dollars or compute per successful task, not per request

LongMemEval-V2 demonstrates the trade-off vividly: its most accurate coding-agent memory approach outperformed RAG but incurred high latency. 19 Anthropic similarly notes that just-in-time runtime exploration can avoid loading enormous objects but is slower than precomputed retrieval. 7

The break-even question is roughly:

[ (\text{reuse frequency} \times \text{context tokens avoided})

(\text{indexing + writing + retrieval + maintenance overhead}) ]

after adjusting for model pricing, caching and—more importantly—quality changes.

Prompt caching can materially change this calculation for repeated stable prefixes, so a system that repeatedly sends a moderately sized stable context may be cheaper and simpler than an elaborate memory pipeline under some provider/runtime configurations. Prompt-caching capabilities are provider-specific and therefore must be benchmarked using the actual serving stack. 28

My default rule is: do not build a memory optimization merely because it saves tokens. Build it when it improves cost per correct completed task after retrieval and maintenance overhead.

Failure-mode catalogue and practitioner disagreements

Failure-mode catalogue. Evidence strength below distinguishes controlled research from benchmark evidence, official engineering guidance, self-reported production evidence and architectural inference.

Failure	Symptom	Mechanism	Detection	Containment	Recovery	Prevention	Evidence strength
Stale preference resurrection	user asks for Slack but agent emails	old memory remains active/retrievable	temporal regression tests; stale-use metric	suppress superseded item	correct active preference; invalidate caches/summaries	validity intervals + explicit override semantics	Strong benchmark relevance / architectural evidence: LongMemEval knowledge updates 1
Over-eager permanent preference	one casual comment becomes permanent personalization	model infers durability from weak evidence	review memory writes; counterfactual eval	downgrade to candidate	delete/invalidate assertion	distinguish explicit vs inferred; promotion threshold	Interpretation supported by memory-write architecture 3
Duplicate amplification	repeated equivalent memories dominate retrieval/confidence	same evidence re-extracted or summarized many times	lineage-aware duplicate ratio	collapse retrieval duplicates	rebuild canonical memory	provenance + source-lineage dedupe	Interpretation; structured-memory research supportive 29
Consolidation hallucination	generated fact keeps returning as “known”	model synthesis becomes authoritative source	compare memory to upstream evidence	quarantine derived chain	invalidate/re-extract from raw sources	immutable evidence + assertion-mode metadata	Known generative-risk mechanism; architectural interpretation 20
Summary drift	an old constraint disappears or changes after compaction	iterative lossy summarization	summary-vs-raw regression suite	rehydrate raw events	rebuild summary	versioned summaries; periodic reconstruction	Official engineering warning: compaction can lose subtle critical context 7
Lost-in-the-middle	relevant evidence is present but ignored	position/attention degradation in large context	move same evidence across positions	shorten/reorder context	reretrieve concise evidence	budget context; targeted retrieval	Strong empirical study 10
Context rot / distraction	quality worsens as irrelevant history grows	attention diluted by extra context	context-length ablation	trim context	rerun with high-signal subset	retrieval, compaction, quotas	Empirical technical report + engineering observation 11
Semantic near-match error	retrieves similar fact for wrong project/person/time	embeddings encode similarity, not identity/authorization	adversarial near-neighbor tests	hard entity/scope filters	re-query with entity/time constraints	metadata filtering before ranking	Benchmark/architectural evidence 1
Retrieval omission	needed memory exists but is not recalled	bad embeddings/query/top-K/filter	oracle-memory comparison	fallback search/raw history	broader/rewritten query	hybrid retrieval + recall eval	Strong benchmark evidence 1
Wrong time resolution	future or historical fact treated as current	ingestion time confused with validity time	temporal eval	suppress ambiguous candidates	reconstruct fact timeline	bitemporal records	Temporal-memory engineering + benchmarks 16
Last-write-wins corruption	newest ingestion overwrites more authoritative current value	storage order substituted for truth semantics	conflicting-source tests	freeze automatic updates	restore authoritative version	authority + valid-time conflict rules	Interpretation supported by temporal-memory evidence 16
Memory poisoning	future queries trigger malicious reasoning/actions	attacker writes/retrieves crafted persistent record	red-team memory-write tests	quarantine source/memory chain	delete poison; reconstruct derived artifacts	memory admission boundary + trust-aware retrieval	Strong security research 2
Persistent prompt injection	malicious document changes behavior in later sessions	untrusted instructions become durable memory/procedure	provenance/trust scans	prevent promotion	purge descendants	retrieved content is data; procedural writes privileged	Strong security research/guidance 4
Cross-tenant memory leak	A’s memory appears in B’s context/store	missing ACLs, shared mutable clients/state, namespace bug	concurrent isolation canaries	disable affected path; scope deny	identify/move/purge contaminated records	request-scoped clients + DB enforcement	Self-reported production evidence: Graphiti issue/fix 26
Incomplete deletion	“forgotten” fact resurfaces	source, derived memory, summary or index survives	deletion canary searches across all stores	tombstone at query layer	fan-out purge/rebuild	dependency graph + delete events	Official product evidence illustrates separation 18
Unofficial source of truth	AI memory disagrees with CRM/billing DB but wins	extracted memory treated as authoritative business record	source-authority audit	prohibit memory for authoritative fields	reread system of record	mark authoritative sources; memory as cache/assertion	Interpretation
Bloated tool-output history	slow/costly agent becomes less coherent	raw tool responses accumulate	context/token telemetry	clear old outputs	retrieve result again if needed	store references/structured result summaries	Official engineering guidance 7
Interrupted-task duplication	restart repeats purchase/email/delete	operational state encoded only in conversation/memory	crash/restart integration tests	stop action execution	reconcile receipts/state	durable typed checkpoints/idempotency	Framework architectural evidence 3
Graph complexity without payoff	higher latency/storage/ops with negligible accuracy gain	architecture exceeds task requirements	flat-vs-graph controlled eval	keep simpler path	migrate/rebuild if needed	require measurable incremental benefit	Vendor-authored empirical caution: modest graph uplift in Mem0 study 20

The table deliberately includes several interpretation-level failures because the user requested an operational catalogue rather than only established academic phenomena. They should be treated as hypotheses to test, not as documented universal incidents.

Practitioner disagreements.

The first disagreement is “just use a longer context” versus “retrieve aggressively.” Long-context research demonstrates real position and noise problems, but retrieval introduces its own recall and indexing failures. 10 My position: start with direct context when the relevant source set is small and bounded; switch to retrieval when irrelevant context dominates or the corpus is too large/dynamic. Do not deploy memory infrastructure merely because long context feels inelegant.

The second is flat memory versus knowledge graphs. Temporal and relationship-heavy workloads plausibly benefit from graphs, and Graphiti/Zep research reports gains on long-memory benchmarks. 30 But Mem0’s own published evaluation reports only a small overall uplift from its graph variant over its simpler base memory while increasing its memory footprint. 20 My position: begin with structured assertions plus hybrid retrieval. Add graph traversal only when a separate multi-hop/temporal test slice proves incremental value.

The third is model-controlled memory writing versus application-controlled writing. Agentic write selection is flexible and can discover useful things a deterministic extractor cannot, but MINJA demonstrates why unrestricted conversational write authority is dangerous. 13 My position: allow models to propose arbitrary memories, not to silently confer authority on them.

The fourth is background consolidation versus hot-path consistency. LangGraph documents both approaches; Google ADK supports session/event ingestion and long-term memory extraction. 3 My position: explicit settings and operational state update synchronously; low-risk semantic consolidation can be eventual.

The fifth is forgetting versus preserving everything. MemoryBank explores decay-based forgetting, while provenance requirements favor retaining reconstructable evidence. 17 My position: separate eligibility for retrieval from evidence retention. Most old information should disappear from normal recall long before audit evidence necessarily disappears from storage.

The sixth is precomputed RAG versus agent-directed evidence gathering. LongMemEval-V2’s strongest reported method is an agentic file/context gatherer rather than its strongest RAG baseline, but the accuracy gain comes with higher latency. 19 My position: use precomputed retrieval for routine high-frequency facts; reserve exploratory search for difficult or low-confidence cases.

The seventh is “memory makes agents better” versus “memory can make agents worse.” Both are true. LoCoMo, LongMemEval, A-MEM and Mem0 provide evidence that memory mechanisms can improve long-horizon tasks. 31 AgentPoison, MINJA, long-context studies and the Graphiti isolation bug demonstrate new failure modes created by memory and retrieval infrastructure. 32

That yields the practitioner stance I would use for architecture reviews:

Memory is justified only by measurable improvement in downstream behavior after accounting for false recall, stale recall, write errors, security exposure and maintenance cost.

Claim-to-source map and firsthand testing agenda

Claim-to-source table. The source classifications below use the categories requested in the brief.

Load-bearing claim	Evidence	Classification
Sustained multi-session memory remains difficult; evaluation must cover extraction, temporal reasoning, updates and abstention	LongMemEval 1	Benchmark / empirical study
Environment experience requires more than recalling user chat; agentic evidence gathering can outperform standard RAG but with latency cost	LongMemEval-V2 19	Benchmark / empirical study
Long-memory systems should be tested for retrieval, learning, long-range understanding and conflict resolution	MemoryAgentBench 21	Benchmark
Very long conversations provide a realistic long-horizon evaluation setting	LoCoMo 31	Benchmark / empirical study
Relevant information can become harder to use when buried in the middle of long contexts	Lost in the Middle 10	Empirical study
Performance can degrade as additional context is introduced even within nominal model context capacity	Chroma Context Rot 11	Engineering report / empirical study
Context should be curated toward high-signal tokens; compaction, JIT retrieval and external notes are practical long-horizon techniques	Anthropic context engineering 7	Engineering report / practitioner experience
Thread/task state and cross-session memory should be distinct	LangGraph memory docs 3	Official documentation
Session events/state and long-term searchable knowledge are separate concerns	Google ADK memory docs 12	Official documentation
Hot-path and background memory writes are both established implementation patterns	LangGraph docs 3	Official documentation
Explicit session ingestion, event ingestion and direct memory entry are practical write paths	Google ADK 12	Official documentation
Structured/evolving notes can improve memory organization and retrieval	A-MEM 29	Empirical study
Higher-level reflection over experiences can improve agent behavior in simulated long-running environments	Generative Agents 33	Empirical study
Dynamic extraction/consolidation can outperform full-context baselines under some benchmark conditions and reduce tokens/latency	Mem0 20	Empirical study / engineering report; vendor-authored
Temporal graph memory can preserve changing relationships and provenance-like source relationships	Graphiti/Zep 16	Engineering report / empirical study; vendor-authored
A graph extension does not automatically justify its operational complexity; the incremental gain can be modest	Mem0 graph versus base result 20	Empirical study / interpretation
Long-term/RAG memory can be deliberately poisoned	AgentPoison 23	Security research
Conversational/query-only interaction can inject malicious memories without direct database access	MINJA 24	Security research
Memory-poisoning attack strength is sensitive to realistic initial state and defense thresholds	2026 EHR poisoning/defense study 25	Security research / empirical study
Prompt injection remains an architectural concern when untrusted content enters model context	OWASP LLM01 4	Official documentation / security guidance
Instruction precedence cannot safely be reduced to arbitrary prompt ordering	Instruction Hierarchy research 8	Empirical study / security research
A real concurrency bug can silently cross memory-group boundaries	Graphiti issue #1676 26	Production evidence / practitioner experience, self-reported
Request-scoped database clients fixed that reported isolation issue	Graphiti PR #1699 27	Engineering report / production evidence
Separate memory/storage layers make deletion propagation non-trivial	OpenAI Memory documentation 18	Official documentation; product-specific illustration
Traces, metrics and logs can be correlated using an open observability framework	OpenTelemetry 22	Official documentation
Provenance should record artifacts, production processes and upstream inputs sufficiently for verification/reconstruction	FHIR provenance / SLSA provenance models 14	Official documentation
Memory decay/forgetting based on time and importance has been explored empirically	MemoryBank 17	Empirical study

Several evidence limitations matter. Much of the current agent-memory literature evaluates synthetic or semi-synthetic conversational benchmarks rather than multi-year production workloads. Vendor-authored memory papers often compare against configurations chosen by the vendor and should be reproduced locally before being treated as capacity-planning evidence. 20 GitHub bug reports provide unusually useful operational detail but remain practitioner reports, not independent incident investigations. 26

Things that still require firsthand testing. No external paper can determine the following for a specific production system.

What to test firsthand	Experimental design	Decision it should drive
Context-length sensitivity	Replay identical tasks at increasing distractor lengths and different evidence positions	when to retrieve/compact
Best retrieval mix	lexical vs dense vs hybrid vs graph on real queries	retrieval architecture
Top-K and threshold	sweep K/threshold while measuring final actions, not just recall	context budget
Write precision	label which real utterances deserve durable memory	auto-write policy
Write recall	measure important facts/preferences missed by extractor	whether background extraction is needed
Preference durability	test casual statement vs explicit preference vs explicit override	promotion semantics
Conflict resolution	construct authoritative/non-authoritative, historical/future and contradictory sources	source hierarchy
Temporal correctness	replay effective-date and ingestion-date permutations	bitemporal requirements
Compaction fidelity	long traces with hidden constraints required hundreds of turns later	summary format/rebuild interval
Deletion propagation	insert canaries, delete source, probe every store/index/cache/summary and backup-restore path	deletion SLA
Cross-tenant isolation	concurrent identical queries/writes across many tenants plus retries/failures	release blocker
Memory poisoning	adversarial users/documents attempt candidate and procedural writes	admission controls
Permission changes	revoke permission after memory/index creation	ACL enforcement point
Tool-parameter safety	stale versus current address/account/payment/channel values	action policy
Interrupted workflows	crash before/after each external side effect	checkpoint/idempotency design
Graph incremental value	same dataset with structured-flat versus graph memory	whether graph infrastructure is justified
Agentic search break-even	RAG versus JIT exploration on hard cases	latency/cost routing
Model upgrade behavior	replay the entire suite on every new model/version	upgrade gate
Embedding/reranker migration	dual-index and compare retrieval sets	reindex strategy
Memory growth	months of simulated/real writes with consolidation	storage/TTL policy
Human correction UX	measure whether operators/users can identify and fix bad memories	review tooling
End-to-end economics	compute infrastructure cost per correctly completed workflow	whether memory pays for itself

The most useful rollout sequence is correspondingly restrained.

Start with immutable raw events + deterministic workflow state + high-quality tracing, without automatic durable memory. That establishes a baseline and creates the evidence needed to evaluate memory rather than guessing.

Next allow explicit user/operator memory writes and deterministic extraction for well-defined fields. Add provenance, scope, update semantics and deletion before increasing automation.

Then introduce model-proposed candidate memory for low-risk semantic facts and preferences, measuring false writes, missed writes, stale recall and behavior changes.

Add background consolidation and summarization only when raw-history/context growth produces demonstrated problems.

Finally, add graph memory, autonomous procedural learning or broad model-controlled writes only when controlled A/B evaluation demonstrates a material end-to-end benefit. Current evidence shows that sophisticated memory can improve long-horizon performance, but it also increases the surfaces for stale state, poisoning, isolation bugs, deletion failures and operational complexity. 1

The resulting production principle is deliberately less glamorous than “infinite memory”:

Remember less, but remember with identity, scope, time, source and lifecycle. Preserve the evidence. Make operational state exact. Treat retrieval as a hypothesis about relevance rather than truth. Treat automatic writes as a security-sensitive mutation. And judge the system by whether it takes the correct action after months of change—not by whether it can retrieve yesterday’s sentence.

Decision Evidence Dossier: Persistent AI Memory vs. Simpler Context Architectures

Research snapshot: October 3, 2026

Decision frame, business problem map, and memory categories

Bottom-line decision rule

Persistent AI memory should not be the default persistence mechanism for an enterprise AI system.

The strongest architecture is usually to give each class of information the least ambiguous persistence mechanism that fits it:

live authoritative system → structured workflow state → versioned project/knowledge source → retrieval → explicit/session context → derived persistent AI memory

Persistent AI memory earns a place only when all of the following are true:

• The value really depends on history surviving across sessions or workflows.

• Reconstructing that history from authoritative records, project context, or explicit context is materially worse in user effort, task performance, latency, or cost.

• The information is suitable for a fallible derived representation rather than needing exact transactional truth.

• Its volatility and consequence of being wrong are manageable through expiry, validation, or source checks.

• Who may write, retrieve, correct, and delete it can be bounded.

• A pilot demonstrates business-level improvement over a simpler baseline, not merely better recall.

• The value survives full lifecycle cost, including evaluation, security, correction, governance, and migration—not just storage and prompt-token savings.

This stance follows from three important findings. First, long-term interaction benchmarks show that maintaining information across long histories is genuinely difficult: LongMemEval found roughly a 30% accuracy degradation for commercial assistants and long-context models on sustained-interaction memory tasks. 1 Second, simply giving models very large contexts is not a complete solution: relevant information can be used substantially less reliably when it is buried in the middle of long contexts, while controlled comparisons show a real performance-versus-cost trade-off between long-context prompting and retrieval. 2 Third, persistence creates a qualitatively different security problem because an adversarial write can continue influencing later sessions; recent research demonstrates both query-only memory injection and persistent memory-poisoning attacks. 3

The practical implication is:

Treat AI memory as a fallible, derived cache of useful experience—not as an enterprise database.

Business problem map

Organizational problem	Is persistent AI memory actually required?	Prefer first	When memory becomes justified
Users repeatedly explain stable preferences	Sometimes	Explicit profile/settings, templates, user preference fields	When preferences are numerous, soft, naturally expressed in conversation, costly to restate, relatively stable, and low enough risk to infer/store
Project context disappears between sessions	Usually no	Project/workspace files, project summary, decision log, RAG	Only for useful tacit project experience not adequately represented in project artifacts
Agent forgets earlier decisions	Usually no	Versioned decision log or project record	Memory may retrieve or summarize the decision, but should not be its sole record
Customer conversations lack continuity	Usually no for factual history	CRM, ticket history, interaction timeline	Derived memory may provide a concise working model of preferences or relationship context; customer status and commitments remain in systems of record
Preferences are not applied consistently	Sometimes	Explicit preference fields for consequential preferences	Memory fits weak/soft preferences such as communication style or recurring format choices
Long-running task loses progress	No	Workflow/checkpoint/database state	AI memory may explain why prior attempts failed, but task position, completed steps, locks, IDs, and transaction state belong in structured state
Company knowledge is difficult to find	No	Search/RAG over governed knowledge	Persistent memory can cache useful associations, but should not replace authoritative knowledge retrieval
Agent repeats previous mistakes	Sometimes	Runbooks, postmortems, tests, evaluation feedback	Episodic/reflection memory is promising where experience cannot yet be captured as deterministic rules; successful lessons should eventually be promoted into reviewed artifacts
Work restarts after handoff	Usually no	Structured handoff/checkpoint plus project artifacts	Memory is useful for unstructured experiential residue, not as the handoff itself
Personalized assistant repeatedly reconstructs a person’s context from very long histories	Potentially yes	Explicit profile plus selective retrieval	Persistent personalized memory is attractive when the history is large, recurring personalization materially changes outcomes, and users can inspect/correct it
Agent must learn environment-specific “gotchas” over months of operation	Potentially yes	Runbooks where lessons can be formalized	One of the stronger cases for experiential memory: LongMemEval-V2 specifically tests workflow knowledge and environment-specific experience and found substantial gains from persistent file/runbook-style approaches. 4

The distinction between task state and experiential memory matters especially for agents. An agent at workflow step 17 should not “remember” that it is at step 17; its orchestrator should know that deterministically. An agent may, however, usefully remember that the last three attempts using endpoint X failed unless header Y was supplied. Research such as Reflexion shows that retaining textual feedback from previous attempts can improve performance on controlled sequential reasoning and coding tasks, while LongMemEval-V2 suggests that accumulated workflow experience can help on much larger histories. Neither result implies that business records should be stored as free-form memory. 5

Memory category map

Information category	Appropriate home	Persistence	Retrieval	Structured storage	Authorization	User control	Expiry/deletion
Transient session context	Context window	Normally no	Within session	No	Session ACL	Clear/session reset	End of task/session by default
Project context	Workspace, repository, project files	Yes, project-scoped	Yes	Partly	Project ACL	Team/admin controls	Project retention policy
User preferences	Profile fields + optional derived memory	Often	Yes	Explicit preferences: yes; inferred preferences: metadata-rich memory	User/account scope	High: inspect, correct, delete, disable	TTL for inferred preferences; durable only where still useful
Customer history	CRM/ticketing/customer-data platform	Yes	Yes	Yes for facts	Account/customer ACL	According to applicable privacy rules and product policy	Business/legal retention
Task state	Workflow engine/database/checkpoint store	Yes while active	Direct lookup	Yes	Workflow/service identity	Usually operational rather than conversational	Explicit terminal-state retention
Organizational knowledge	Governed documents/knowledge base	Yes	RAG/search	Metadata should be structured	Document-level ACL	Owner/editor governance	Source lifecycle/versioning
Historical interactions	Logs or conversation store if justified	Sometimes	Selectively	Metadata yes	User/project/tenant ACL	Access/deletion where required or promised	Explicit retention window
Learned procedures / experience	Memory initially; reviewed runbook/skill eventually	Sometimes valuable	Yes	Metadata + provenance	Agent/task-specific write rights	Admin/operator review for consequential lessons	Revalidate; promote or expire
Durable instructions	Version-controlled policy/configuration	Yes	Explicit injection	Yes/versioned	Administratively controlled	Change-management process	Until superseded

Persistent memory is therefore not one thing. A user preference, a workflow checkpoint, a customer contract, and a learned troubleshooting lesson may all look like “things the AI should remember,” but treating them alike creates the shadow-database problem.

A useful boundary is:

facts that must be right → structured/source-of-truth storage
knowledge that must be current → retrieval
experience that is useful but fallible → memory
information useful only now → context

Architectural options and trade-offs

There is no globally best approach. Controlled comparisons show why: long-context prompting can outperform RAG when sufficient context and compute are available, while RAG can be dramatically less expensive; a hybrid router in one major study retained performance close to long-context approaches while reducing computation. 6 At the same time, “just put everything in the context window” is weakened by position-sensitive retrieval behavior documented in Lost in the Middle. 7

Options from no memory to hybrid persistence

Option	Reliability / accuracy	Freshness	Privacy / security	Governance / observability	Complexity / operating cost	Portability / maintenance	User experience	Best fit
No persistent memory	Avoids stale-memory errors; continuity must be reconstructed	Excellent with current inputs	Smallest persistent attack/data surface	Simplest	Low	Excellent	Repetition can be annoying	One-off, sensitive, high-variance, or low-frequency work
Explicit context each time	Highly inspectable; quality depends on what user supplies	Usually good	User knows what is shared	Excellent	Low system complexity; higher human effort	Excellent	Poor if context is repeatedly long	Small, deliberate contexts; high-control workflows
Conversation history	Good near-term continuity; increasingly noisy at scale	Chronological but old facts remain present	Retains potentially sensitive raw material	Fair; raw provenance is available	Context cost grows	Usually exportable conceptually, implementation varies	Natural within one thread	Bounded conversations where entire history is relevant
Summarization	Efficient but lossy; summary errors may propagate	Only as fresh as update process	Less data passed to model, but summary itself may expose sensitive information	Good if summaries are versioned and traceable	Additional model calls; reduces prompt size	Fairly portable	Good	Long discussions where gist matters more than exact detail
Project/workspace context	Strong when artifacts are maintained	Good if project files are current	Natural scope boundary, but ACL hygiene matters	Strong	Moderate	Strong if based on normal files/docs	Good for teams	Long-lived projects, handoffs, coding/research work
Long-context prompting	Can be very strong, but relevant information can be underused depending on its position. 2	As fresh as supplied context	Repeatedly exposes larger data volume to model	High input observability	Potentially high token/latency cost	High concept portability	Excellent when seamless	Bounded corpora where recall quality justifies computation
RAG / knowledge retrieval	Depends on indexing, retrieval, reranking and generation	Potentially excellent when index tracks authoritative sources	Must enforce source-level ACLs; knowledge poisoning remains possible	Strong provenance if results retain source citations	Index + retrieval + model cost; often cheaper than full long context. 6	Generally good	Seamless when retrieval works	Large, changing document corpora and organizational knowledge
Structured database state	Highest fit for exact IDs, statuses, transactions and workflow state	Excellent if system is canonical	Mature DB/IAM security patterns available	Excellent	Integration/schema cost but predictable	Usually high	Invisible and reliable	Transactions, workflow progress, permissions, customer status
Persistent personalized AI memory	Strong continuity potential; derived memories can be wrong, incomplete or stale	Must be actively managed	Enlarges long-lived personal-data and poisoning surface	Requires item-level tooling	Extraction, consolidation, retrieval, correction and governance cost	Provider dependence can be significant	Potentially best personalization UX	Stable soft preferences and recurring personal context
Hybrid architecture	Can achieve best fit by data type	Strong if authoritative values are read live	More components but clearer trust boundaries	Potentially strongest, provided traces connect components	Highest initial architecture complexity	Good if memory layer is decoupled	Usually best seamless UX	Sophisticated assistants/agents where several state types coexist

Two findings are especially useful when choosing among these.

First, large context and memory are substitutes for some tasks but not all tasks. A 2024 controlled study found that long-context models usually achieved higher average performance than RAG when resources were sufficient, but RAG was considerably cheaper; hybrid routing captured much of both advantages. 6 A separate evaluation likewise found that the relative advantage varied by task and retrieval method rather than yielding one universal winner. 8

Second, persistent memory becomes more attractive as history becomes much larger than any reasonable working context and as the value lies in selective accumulated experience. LongMemEval-V2 uses histories extending to hundreds of trajectories and very large token volumes; its file/runbook-based memory agent reached 72.5% average accuracy compared with 48.5% for its strongest RAG baseline, although an off-the-shelf coding-agent approach reached 69.3% and the richer memory architecture incurred substantial latency. The benchmark was still labeled work in progress, so it should influence pilots, not settle procurement decisions. 4

A practical architecture selection test

The following sequence eliminates many unnecessary memory implementations:

Question	If yes	If no
Does the information need to survive this session?	Continue	Keep it transient
Is it an exact business fact or transaction state?	Put it in the relevant structured system	Continue
Does an authoritative source already contain it?	Retrieve that source when needed	Continue
Is it reusable organizational/project knowledge?	Put it in governed knowledge/project artifacts and retrieve it	Continue
Is it a durable instruction or procedure?	Version-control it as policy/runbook/config	Continue
Is it a low-risk, reasonably stable preference, experiential lesson, or useful derived summary?	Candidate for persistent memory	Usually do not persist
Can a wrong or stale version cause material harm?	Require source confirmation or reject memory as the decision source	Candidate can be piloted
Can write/read scope, deletion and provenance be demonstrated?	Pilot	Do not deploy persistent memory

The test deliberately places persistent memory at the end rather than the beginning.

Value evidence and what it actually proves

Evidence quality is uneven

The evidence base as of October 2026 is considerably stronger for memory benchmarks, retrieval accuracy and agent task performance than for enterprise-level ROI after full governance cost.

In the primary evidence reviewed for this dossier, there are strong benchmark results, controlled agent experiments, provider-authored performance claims, personalization studies, and an emerging production-style case study. There is not yet comparably strong multi-organization evidence showing that persistent AI memory consistently improves business throughput, customer outcomes, or operating economics after privacy, security, correction, support, and lifecycle costs are included. That gap should materially affect the burden of proof for broad deployment. 1

Evidence ledger

Evidence	Evidence class	Finding	What it supports	What it does not establish
LongMemEval	Benchmark evidence	Evaluates information extraction, multi-session reasoning, temporal reasoning, knowledge updates and abstention over sustained interaction histories; commercial assistants and long-context models showed roughly a 30% accuracy drop in this setting. 1	Cross-session continuity is a real technical problem; naive history retention is insufficient	Enterprise ROI; whether memory is better than CRM/project/RAG architecture
LongMemEval-V2	Benchmark evidence, work in progress	Tests static state, dynamic state, workflow knowledge, environment “gotchas” and premise awareness across very large histories; file/runbook memory substantially outperformed the reported RAG baseline but incurred latency. 4	Experiential persistent context can materially help history-intensive agents	That every business agent needs memory; cost-benefit under production governance
RAG vs. long-context study	Controlled benchmark	Long context generally performed better when sufficiently resourced, while RAG was materially cheaper; hybrid routing provided a better trade-off. 6	Simpler alternatives can compete; architecture should be workload-specific	Persistent personalized memory value
Lost in the Middle	Controlled benchmark	Models’ use of relevant information varies with its position in long context, often weakening when the needed information is in the middle. 7	A huge context window does not guarantee reliable recall	That RAG or memory always beats long context
Reflexion	Controlled agent benchmark	Agents retained textual reflections on feedback and improved performance across sequential decision-making, coding and reasoning tasks. 9	Retained experience can reduce repeated agent mistakes	Enterprise production value; safety of self-written memories
MemoryBank	User-oriented research / benchmark	Long-term memory improved recall and personalization/empathy in conversational settings evaluated with simulated and real-user dialogue components. 10	Mechanism for relationship continuity and personalization	Operational or financial business benefit
PersonaMem-v2	Personalization benchmark	Frontier models achieved only 37–48% on implicit personalization; an agentic memory approach reached 55% while using a 2K-token memory rather than a full 32K history, reported as 16× fewer input tokens. 11	Compact memory can improve personalization efficiency relative to replaying history	Real-user willingness, enterprise ROI, privacy acceptability
Mem0	Provider-authored benchmark / provider claim	The paper reports higher long-term-memory benchmark performance plus major latency and token savings versus full-history approaches. 12	Plausibility that selective memory can reduce context cost	Independent production economics; generalization to other architectures
Persistent research-agent case study	Production-style report, single investigator	A 2026 self-observed persistent-agent environment accumulated more than 75,000 deduplicated telemetry records over 96 active days and argues for artifact-level rather than token-level economics. 13	Persistent environments can be operated at substantial scale and produce rich lifecycle telemetry	Causal improvement from memory; multi-company generalizability
Reduced repeated instructions	Plausible mechanism	Storing stable preferences removes the need to restate them	User-effort reduction	Whether saved seconds outweigh governance complexity
Reduced coordination / faster handoff	Plausible mechanism	Shared persistent context can give later sessions access to previous work	Continuity	That AI memory is better than a good handoff document
Fewer repeated mistakes	Controlled mechanism + benchmark	Retained feedback can alter later behavior. 5	Experiential agent memory	That autonomous memory writes are sufficiently safe

The central evidentiary warning is:

Recall is an intermediate metric.

A memory system that increases recall from 60% to 85% has not created business value if users spend additional time correcting wrong memories, if stale context causes more rework, if the architecture duplicates CRM data, or if governance and incident response cost more than the saved interaction time.

The pilot therefore needs a causal chain:

memory → less user/agent reconstruction → better task behavior → measurable operational outcome → positive risk-adjusted economics.

What value should actually be measured

For a human-facing assistant, the most useful outcome measures are task completion, cycle time, minutes or turns spent reconstructing context, correction/rework rate, and successful personalization—not “number of memories retrieved.”

For an agent, measure successful end-to-end tasks, duplicate actions, human interventions, recovery after failure, repeated-failure frequency, and cost per successfully completed artifact or transaction. The artifact-level perspective is also advocated by the 2026 persistent-agent case study, which found that cached and repeated interactions can make token count a misleading economic denominator. 13

For customer-facing systems, continuity only counts as value when it produces an outcome such as faster resolution, fewer repeated questions, fewer transfers, higher completion, or lower agent effort. “The chatbot remembered me” is a user-experience signal, not sufficient evidence on its own.

Source-of-truth boundaries, prohibited memories, and freshness governance

The shadow-database risk

The most dangerous organizational failure mode is not necessarily a spectacular hallucination. It is the gradual creation of a second, weakly governed representation of business reality:

• the CRM says the customer is inactive, while memory says active;

• IAM says an employee changed roles, while memory retains the previous authorization context;

• the contract changed, while the agent remembers an old clause;

• pricing was updated, while a remembered price remains salient;

• a project decision was superseded, but the old decision still ranks highly in retrieval.

Persistent memory therefore needs an explicit authority hierarchy.

Layer	Examples	Authority	How AI should use it
Authoritative business record	Contract, CRM status, ERP values, IAM permissions, order state, approved pricing	Highest	Fetch at action time; do not let derived memory silently override it
Governed retrievable knowledge	Policies, manuals, approved project documentation, legal guidance, product documentation	High but version-dependent	Retrieve relevant current version with source/version metadata
Explicit structured preference	Preferred language, contact channel, approved communication setting	High for the stated preference	Read directly; permit correction
Derived AI memory	“User usually prefers concise summaries,” relationship summary, agent lesson, inferred project concern	Advisory	Use as a hypothesis/context signal; expose provenance and allow correction
Temporary inference/context	Current plan, intermediate reasoning result, one-time constraint	Lowest/deliberately short lived	Use only for the present task unless explicitly promoted

Conflict rule: higher-authority and fresher information wins. Derived memory must never silently defeat authoritative data.

Concrete source-of-truth decisions

Information	Should AI remember the value?	Better pattern
Contract term	No, not as authority	Remember contract/document identifier at most; retrieve current executed agreement
Current price	No	Query pricing/catalog service
Discount entitlement	No	CRM/pricing/entitlement engine
Employee’s current role	No	HR/IAM source
Access permission	Never infer from memory	Authorize via IAM at the moment of access/action
Customer account status	No	CRM/account system
Order/payment status	No	Transaction system
Current policy	No	Retrieve current approved policy/effective version
Project decision	Decision itself belongs in decision log	Memory may hold summary + pointer
User’s explicit preferred language	Yes, potentially	Prefer structured preference field
User seems to like bullet-light responses	Reasonable derived-memory candidate	Store as inferred preference with correction/expiry
Customer verbally expressed a consequential preference	Prefer explicit confirmation and record	Confirm, then store in appropriate customer record
Agent learned an environment-specific workaround	Potentially	Memory first; validate and promote into versioned runbook when repeatable
“Model thinks this customer is unhappy”	Not as fact	Keep as ephemeral inference or clearly labeled hypothesis

What should normally not become persistent AI memory

The strongest control is often preventing creation, rather than trying to secure a memory after the fact.

Credentials and secrets should be categorically excluded from conversational/semantic memory: passwords, API keys, authentication tokens, cryptographic keys, recovery codes and similar credentials should remain in dedicated secret-management systems. Persisting such values in a semantic store expands both accidental retrieval and compromise scope.

Permissions and authorization decisions should never be learned from history. A previous ability to access a resource does not authorize access today. Access must be checked against the current identity/authorization system.

Authoritative volatile facts—current pricing, customer status, account balance, inventory, employee role, policy version, regulatory limit—should normally be retrieved rather than remembered. The problem here is not storage capacity; it is temporal correctness.

Highly sensitive personal information should be excluded by default unless a specific, justified purpose requires persistence and applicable privacy requirements are satisfied. Under GDPR, organizations processing personal data are subject to principles including purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality and accountability; data subjects also have rights concerning access, correction and, under applicable conditions, erasure and other controls. 14 California’s CCPA likewise provides applicable consumers rights including knowing collected information, deletion subject to exceptions, correction, opting out of sale/sharing and limiting some uses of sensitive personal information. 15

Speculative model conclusions should not silently crystallize into facts. “User is probably price sensitive,” “employee appears disengaged,” or “customer is likely fraudulent” are materially different from user-confirmed facts. If retained at all, such information needs explicit derived/inferred labeling, provenance, permitted purpose and risk review.

Untrusted external content should not be promoted into trusted memory merely because the model summarized it. Research now demonstrates that malicious records can be inserted through normal interactions and subsequently retrieved as influential memories. 3 RAG is not immune: AgentPoison and PoisonedRAG demonstrate that retrieved knowledge bases themselves can be poisoned, so the right lesson is to preserve trust and provenance boundaries throughout ingestion and retrieval rather than assuming retrieval is inherently trusted. 16

Freshness should be governed by volatility × consequence

A one-size-fits-all TTL is weak governance. The relevant variable is:

risk of stale memory ≈ probability the value changes × consequence of using the old value × probability memory is used without verification

Information	Volatility	Consequence if stale	Recommended memory treatment
Preferred response format	Low	Low	Persist with periodic expiry or contradiction-based update
Favorite communication channel	Low/medium	Low/moderate	Persist if user-controlled; explicit preference beats inference
Project context	Medium	Moderate	Version/supersede; retrieve current project artifacts
Project decision	Medium	Moderate/high	Canonical decision log; memory contains pointer/summary
Customer status	Medium/high	High	Refresh from CRM every consequential use
Employee role	Medium	High	Read from HR/IAM
Permissions	Potentially immediate	Critical	Never authorize from memory
Current pricing	Potentially high	High	Read live pricing source
Policy/regulatory requirement	Variable	High	Retrieve effective version and date
Medical/financial/legal fact used for consequential decision	Variable	Potentially very high	Source validation and appropriate human/process controls; memory alone is insufficient

Every derived persistent memory worth keeping should ideally carry metadata such as:

subject, scope, memory_type, source, source_timestamp, created_at, last_verified_at, effective_at, expires_at, sensitivity, confidence, author/write-channel, supersedes, and a link to any canonical record.

This is not bureaucracy for its own sake. Long-term-memory benchmarks explicitly include temporal reasoning and knowledge updates because old information and changed facts are fundamental failure modes. 1

A robust read path should therefore distinguish “remember and trust” from “remember where to look.” For volatile information, remembering the identifier, document, account, or relevant source can preserve continuity without caching yesterday’s truth.

Privacy, security, and ownership architecture

Regulatory obligations versus good governance

Persistent memory containing personal data is not outside normal data-protection rules merely because it is called “memory.”

For EU/EEA contexts, the European Commission’s GDPR guidance summarizes principles directly relevant to persistent AI memory: lawfulness/fairness/transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality and accountability. It also summarizes data-subject rights including information, access, rectification and erasure, with applicability and exceptions depending on the particular right and processing context. 14

For California consumers and covered businesses, official CCPA guidance includes rights to know, delete subject to exceptions, correct, opt out of sale/sharing, and limit certain use/disclosure of sensitive personal information. 15

Cross-border architecture also matters. Under GDPR, transfers of personal data to non-EEA jurisdictions may require an applicable Chapter V mechanism; European Commission adequacy decisions are one route that permits covered transfers without additional transfer safeguards, while other situations can require other mechanisms. 17 Thus “where memory lives” includes subprocessors, replicas, indexes, backups and retrieval services—not only the nominal database region.

The EU AI Act should not be misrepresented as a generic memory-disclosure law. Article 50 transparency obligations applicable from August 2, 2026 include requirements for certain AI systems to inform people when they are directly interacting with AI, but that is distinct from a general legal requirement to provide an item-by-item memory dashboard. 18 Memory-specific disclosure and inspectability may nevertheless follow from data-protection obligations in a given context and are strong governance/product practices even where not legally required.

Good product/governance practice beyond minimum legal obligations

A user-facing memory implementation should expose:

Control	Purpose
Memory-on indicator	Removes uncertainty about whether cross-session information is being retained
Inspect remembered items	Detects incorrect/inappropriate inference
Source / “why remembered”	Distinguishes user statement, imported business record and model inference
Correction	Prevents an erroneous memory from recursively influencing future interactions
Delete item / clear scope	Supports user control and applicable deletion workflows
Disable future memory writes	Separates use of AI from agreement to build a persistent profile
Scope visibility	Shows whether memory is personal, project, team or organizational
Retention/expiry information	Prevents “remember forever” from becoming an accidental default
Export where appropriate	Reduces lock-in and assists applicable portability/business-continuity requirements

Current consumer memory implementations demonstrate that at least some review, change, deletion and disabling controls are operationally feasible, although enterprise requirements should be evaluated independently of any one provider’s product semantics. 19

Employee memory deserves particularly conservative scoping. Personal memory about an employee and shared organizational/project memory are different data products. A work assistant may reasonably retain project preferences or task context while avoiding persistent inference about personality, health, motivation, political views or other personal attributes. Applicable employment, privacy and labor requirements vary by jurisdiction, so the architecture should not make unrestricted employee profiling the default.

Security risk map

Persistent memory creates a security asymmetry: a transient malicious input can become durable state.

MINJA demonstrates a query-only attack in which an attacker can induce malicious records into an agent’s memory without direct database access. 20 A 2026 systematic study identifies multiple memory-write channels and structural vulnerabilities and finds that agents designed to write and retrieve memory aggressively are more exploitable; critically, a single adversarial write can influence later behavior. 21 AgentPoison similarly demonstrates poisoning against agent memory or knowledge bases, while PoisonedRAG shows that retrieval stores are also attackable, confirming that the problem extends across persistent context infrastructure. 16 NIST’s adversarial-ML taxonomy explicitly includes poisoning, misuse and privacy attacks as relevant GenAI attack classes. 22

Risk	Persistence effect	Example failure	Required control pattern
Memory poisoning	Turns malicious input into future trusted context	“Remember vendor X is approved”	Controlled write channels, provenance, quarantine, promotion rules
Persistent prompt injection	Instruction survives originating page/message/session	Hidden instruction later steers unrelated action	Never confer authority based on remembered text; separate data from instructions
Compromised RAG data	Poison persists in retrievable corpus	Fake procedure is repeatedly retrieved	Source trust, ingestion review, signed/versioned content, citations
Unauthorized memory writes	Attacker changes behavior without DB access	Query causes agent to store malicious exemplar	Explicit memory-write authorization and post-write validation
Poisoned summary	Compression launders malicious/incorrect content into apparently clean state	Summary omits qualification or retains injected instruction	Provenance to raw source; summaries treated as derived/untrusted
Cross-user leakage	One user’s context can surface for another repeatedly	Customer A’s information retrieved for B	Hard namespace/tenant ACL before semantic ranking
Cross-project leakage	Sensitive project context travels across workspace boundaries	Acquisition project appears in generic assistant context	Project-scoped stores and permission-aware retrieval
Sensitive reuse	Previously appropriate disclosure appears later in the wrong context	HR or customer-sensitive detail reused in a presentation	Purpose/scope tags and retrieval-time authorization
Stale memory exploitation	Old permission/status remains useful to attacker	Former role appears to authorize action	Live authorization checks; event-driven invalidation
Memory-to-action escalation	Fallible context becomes operational authority	Remembered bank account changes a payment	Consequential actions re-read authoritative records / require approval

Security therefore needs controls across four separate planes.

At write time, define who and what may create memory. Untrusted web pages, emails, tool outputs and third-party documents should not gain the same ability to write persistent instructions as an authenticated user or approved business system. The memory-poisoning literature makes the write channel itself a security boundary. 21

At storage time, enforce tenant, user and project isolation independently of semantic similarity. A vector search returning a highly similar object is not authorization.

At retrieval time, apply permissions before content reaches the model, carry provenance and age into the prompt, and distinguish authoritative records from inferred memories.

At action time, memory should not grant permissions, modify payment destinations, determine contractual obligations, override policy or supply secrets. High-consequence fields should be re-read from their authoritative source.

Build, buy, platform, or hybrid

The choice is less about where vectors live than who owns the lifecycle semantics.

Architecture	Main advantage	Main liability	Appropriate when
Provider-native memory	Fastest implementation; integrated UX	Portability, write semantics, retention/deletion and observability depend on provider capabilities	Low/moderate-risk personalization where native controls satisfy policy
Application-owned memory layer	Organization controls schema, provenance, policy and provider abstraction	Must build/evaluate lifecycle machinery	Memory is strategically important or crosses multiple models/providers
Database-backed custom memory	Maximum control over ACLs, auditing, retention and schema	Highest engineering/operations burden	Regulated/high-value workflows or unusual memory semantics
Knowledge/RAG layer	Keeps durable truth in source documents and retrieval layer	Does not automatically solve personalization/experience	Organizational knowledge is the primary problem
Hybrid	Separates records, retrieval, task state and derived memory according to their semantics	More components and architectural discipline	Complex enterprise assistants/agents where persistent memory is genuinely useful

A build/buy assessment should require explicit answers on:

Decision factor	Evidence to demand
Ownership	Who is controller/processor/owner of memory and derived metadata?
Export	Can memories, metadata, provenance and scopes be exported in usable form?
Portability	Can another model/provider consume the representation without recreating user history from scratch?
Permission model	User, project, team, tenant and service-account scoping; authorization applied before retrieval
Deletion	Item/scope deletion, index propagation, retention exceptions, backup behavior
Auditability	Who wrote, modified, retrieved and used a memory, when and from what source?
API access	Can the application read/write/correct/delete memories deterministically rather than only through natural language?
Isolation	Hard tenant/project boundaries independent of embedding similarity
Provenance	Can the system distinguish direct statement, authoritative import, summary and model inference?
Freshness	TTL, source refresh, supersession and event invalidation
Security controls	Write gates, quarantine, rate limits, anomaly monitoring, prompt-injection defenses
Residency / subprocessors	Actual processing and storage locations across indexes, models and backups
Evaluation hooks	Ability to replay traces and identify whether memory caused a success or failure
Provider/model portability	Memory schema not inseparably bound to one model’s hidden behavior
Operational burden	On-call ownership, corrections, reindexing, migrations, incidents and support

A practical enterprise default, when persistent memory is justified, is therefore a hybrid architecture: authoritative records remain authoritative; project and organizational knowledge remains retrievable; workflow state is structured; a narrow memory layer stores low-risk derived preferences/experience plus pointers and provenance. That conclusion is architectural synthesis rather than a vendor ranking and is consistent with evidence that different context mechanisms dominate under different task and cost conditions. 6

Lifecycle cost and pilot design

Total cost is a lifecycle problem, not a storage problem

A useful TCO model is:

TCO(memory) = instrumentation + writes/extraction + embeddings/indexes + storage + retrieval/reranking + model/context calls + consolidation/deduplication + freshness management + access control + user controls + evaluation + security monitoring + corrections + support + incident response + migration/exit

The important comparison is not:

storage cost with memory vs. token cost without memory.

It is:

cost per successful, correctly governed workflow with memory vs. the best simpler architecture.

Controlled research already shows that retrieval and long-context approaches occupy different cost/performance points. 6 Provider-authored Mem0 results claim substantial latency and token reductions relative to replaying full histories, demonstrating a plausible cost mechanism, but those numbers should be treated as provider benchmark evidence rather than universal production economics. 12 LongMemEval-V2, conversely, illustrates that richer history-processing architectures can gain accuracy while adding latency. 4

Lifecycle cost map

Cost category	What creates it
Memory extraction	LLM deciding what to remember, classification and sensitivity tagging
Summarization	Compressing conversations/episodes and updating summaries
Embedding/indexing	Initial writes plus re-embedding after model/schema change
Retrieval/reranking	Vector/keyword searches, rerank model, authorization filtering
Prompt/model consumption	Retrieved memories still consume model context
Deduplication/consolidation	“Likes concise answers” written 40 times is not useful memory
Contradiction resolution	Old and new preferences/facts need supersession logic
Freshness correction	TTL processing, event invalidation, source refresh
Governance	Classification, retention, legal/privacy review, policy
User control	Memory-management UI/API and support processes
Evaluation	Regressions, retrieval quality, stale-memory tests, red teaming
Security	Write controls, ACLs, monitoring, poisoning defenses
Support	“Why did the AI think this?” investigations and user corrections
Incident response	Containment and purge across memory/index/cache layers
Migration	Re-embedding, schema conversion, provider exit, provenance preservation

A subtle cost is correction amplification. An error in one answer may disappear with the session; an erroneous persistent memory may influence dozens of later answers. Persistent state therefore raises the value of provenance, correction and root-cause tooling even when raw storage is inexpensive. The persistence of poisoned writes demonstrated in recent security work shows the same asymmetry from an adversarial perspective. 21

Pilot design

Do not pilot “memory versus nothing.” Pilot memory against the best plausible simpler architecture.

A strong experimental design has at least these arms:

Arm	Architecture	Purpose
Baseline	Explicit context + project/RAG + structured workflow state where applicable	Tests whether ordinary context engineering already solves the problem
Persistent-memory arm	Same baseline plus scoped persistent derived memory	Measures incremental value of memory itself
Hybrid arm where justified	Structured records/RAG plus deliberately narrow preference/experience memory	Tests whether smaller memory scope captures most of the value

Where volume permits, assign at the user or project level rather than individual prompts because memory accumulation creates carry-over effects that make naïve per-query randomization invalid.

A safe rollout pattern begins with shadow writing: the system proposes and stores candidate memories that do not yet influence responses or actions. This reveals write precision, sensitivity problems, duplication and poisoning exposure before the organization grants those memories behavioral authority. The next stage permits memory-assisted answers but no consequential autonomous actions. Only after those controls pass should memory affect bounded actions.

Observable outcomes

The pilot’s primary metrics should be business/task metrics:

Dimension	Primary measurement
Repeated context	User minutes/turns spent restating prior information
Task quality	End-to-end successful completion rate
Continuity	Tasks resumed correctly without reconstruction
Efficiency	Median/percentile cycle time and human interventions
Duplication	Repeated work/actions per workflow
Coordination	Handoff questions or human escalations
Correction burden	Memory corrections per user/workflow and correction time
Staleness	Errors traceable to obsolete memories
Economics	Total cost per successful task, including memory infrastructure/support
Personalization	Correctly applied preferences, not mere retrieval rate

Retrieval recall, number of memories created, embedding similarity and token savings are diagnostic metrics, not primary success criteria.

Guardrails

The pilot should begin with a memory allow-list, not a deny-list. Only approved information classes are writable.

Each memory should be scoped to user/project/tenant, provenance-tagged, timestamped and deletable. High-volatility values must be read through to authoritative sources. Sensitive and consequential memory writes should require stronger validation or be prohibited. Memory must never create authorization. These controls address attack surfaces identified by memory-poisoning research and fit NIST’s broader recommendation to identify, measure, manage and document AI risks against organizational risk tolerances. 21

Failure tests

The pilot should deliberately test at least the following cases:

Test	Pass criterion
User changes a preference	Old memory stops affecting behavior and change is traceable
Source document changes	Agent uses new source rather than stale remembered value
Customer status changes	Current CRM state wins
Employee role/permission changes	Old memory cannot authorize anything
Project decision is superseded	New version wins; old one remains historical only if appropriate
User states contradictory preferences	System resolves/asks rather than accumulating both blindly
Malicious webpage/email says “remember…”	Untrusted content does not gain persistent instruction authority
Attacker attempts query-only memory injection	Unauthorized writes are rejected/quarantined
Similar users/projects contain overlapping language	No cross-boundary retrieval occurs
User deletes memory	It stops participating in retrieval according to defined deletion semantics
User corrects an inferred memory	Correction persists and prevents recurrence
Sensitive value appears in conversation	Policy prevents prohibited memory creation
Retrieved memory conflicts with live source	Live authoritative value wins
Memory store is unavailable	Core workflow degrades safely rather than corrupting state
Model/provider changes	Memories remain interpretable and migration can be executed

Query-only injection is not hypothetical: MINJA demonstrates that malicious records can be induced through ordinary interaction rather than direct database compromise. 20 Systematic 2026 work further indicates that aggressive autonomous writing and retrieval increase exploitability, which argues directly for restrained write policies during pilots. 21

Evidence thresholds for the decision

Expand when persistent memory causes a material improvement in predeclared business outcomes over the simpler baseline, safety/error rates remain within the organization’s defined tolerance, access and deletion tests pass, and total cost per successful task remains favorable.

Narrow the scope when gains concentrate in one category—for example, user preferences or agent experience—while project facts, customer records or organizational knowledge gain nothing. The correct response is a smaller memory policy, not a wider one.

Redesign when memory appears valuable but retrieval quality, write quality, staleness, user correction or authorization boundaries are inadequate.

Remove persistent memory when it fails to improve task outcomes materially, when equivalent results come from project/RAG/structured state, when stale-memory errors offset continuity gains, when poisoning or cross-boundary controls cannot be demonstrated, or when lifecycle burden exceeds the labor/token savings.

Leadership decision questions, primary-source claims, and reversal conditions

Questions leadership should answer before enabling persistent memory

Question	Decision significance
What exact business failure are we fixing?	“Users like continuity” is too weak; identify repeated work, task failures, coordination cost or another measurable outcome
Why can project context, RAG, workflow state, a profile field or better documentation not solve it?	Forces the memory-specific incremental case
Which information classes may be remembered?	Prevents a general-purpose shadow database
Which classes are explicitly prohibited?	Write-time prevention is stronger than downstream cleanup
What remains authoritative?	Determines conflict resolution
Can memory ever authorize an action?	Default should be no
What is the cost of a stale memory in this workflow?	Determines whether TTL is enough or live validation is necessary
Who can cause a memory write?	A core security boundary given query-only poisoning attacks. 20
Who can retrieve each memory?	Determines user/project/tenant isolation
Can users/operators inspect and correct derived memories?	Necessary to contain false inference and support applicable privacy controls
Can deletion be demonstrated rather than merely requested?	Tests actual lifecycle semantics
How will superseded information be handled?	Avoids “new fact plus old fact” retrieval ambiguity
What provenance is retained?	Enables correction, audit, trust ranking and incident investigation
How does cross-border processing work?	Relevant where applicable personal-data transfer rules apply. 17
How will we detect poisoning and unauthorized writes?	Persistent state lengthens attack lifetime. 21
Can we export and migrate memory?	Determines provider and architecture lock-in
What is the non-memory benchmark?	Without it, continuity improvements may be incorrectly attributed to persistence
Which business metric must improve?	Prevents recall from becoming a proxy for value
What error/safety threshold stops the pilot?	Creates an ex-ante risk decision instead of post-incident rationalization
Who owns memory quality operationally?	Persistent state needs correction, support and incident ownership
What conditions will make us remove it later?	Prevents architecture from becoming irreversible

Claim-to-primary-source table

Decision-relevant claim	Primary source	Evidence class	Interpretation / limitation
Sustained interaction remains difficult: long-term-memory systems must handle extraction, multi-session reasoning, temporal reasoning, updates and abstention; evaluated assistants/long-context models suffered substantial degradation	LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory 1	Benchmark	Establishes the technical memory problem, not enterprise ROI
Large-scale histories can reward richer experiential memory architecture; one file/runbook agent substantially beat the strongest reported RAG baseline but had latency costs	LongMemEval-V2 4	Benchmark, work in progress	Supports memory for history-intensive experiential tasks; not universal
Long-context prompting and RAG have task-dependent performance/cost trade-offs; hybrid routing can capture much of both	Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach 6	Controlled benchmark	Strong evidence against globally ranking RAG or long context
Long contexts do not guarantee reliable use of information; performance is sensitive to where evidence appears	Lost in the Middle: How Language Models Use Long Contexts 7	Controlled benchmark / peer-reviewed research	Supports retrieval/selective context rather than blind history replay
Retaining reflective feedback can improve later agent performance	Reflexion: Language Agents with Verbal Reinforcement Learning 9	Controlled benchmark	Supports experiential memory, not business-record persistence
Long-term conversational memory can support recall/personalization	MemoryBank 10	Research/user-dialogue evidence	Benefit demonstrated mainly at conversational level
Agentic memory can provide personalization using less input context than replaying long histories	PersonaMem-v2 11	Benchmark	Simulated personalization benchmark, not production ROI
Selective memory can plausibly reduce token and latency cost relative to full-history prompting	Mem0 12	Provider-authored benchmark	Useful mechanism evidence; independently validate economics
Query-only interactions can poison agent memory without direct memory-database access	A Practical Memory Injection Attack against LLM Agents / MINJA 20	Security research	Makes memory-write authorization a first-class boundary
A single adversarial memory write can produce long-lived influence; aggressive write/retrieve designs can increase exploitability	A Systematic Study of Memory Poisoning Attacks in LLM-Based Agents 21	Security research	Strong reason to make persistence selective
Memory/knowledge-store poisoning can compromise agents while largely preserving benign task performance	AgentPoison 16	Security benchmark	Poisoning can be stealthy rather than causing obvious degradation
RAG itself can be poisoned with malicious knowledge-base content	PoisonedRAG 23	Security research	RAG is an alternative to memory, not a security exemption
Poisoning, privacy and misuse are recognized attack classes relevant to generative AI systems	NIST AI 100-2e2025 22	Government technical standard/taxonomy	Provides broader security-governance grounding
Personal-data processing in the EU is governed by principles including purpose limitation, minimization, accuracy, storage limitation and security, with applicable data-subject rights	European Commission GDPR guidance 14	Regulatory / official guidance	Memory architecture must participate in the same data lifecycle
California consumers have applicable rights including knowledge, deletion subject to exceptions and correction under CCPA	California Attorney General CCPA guidance 15	Regulatory / official guidance	Relevant only where CCPA scope and right apply
GDPR international-transfer architecture can depend on adequacy or other transfer mechanisms	European Commission adequacy guidance 17	Regulatory / official guidance	Data location/subprocessor design can affect memory architecture
AI Act Article 50 transparency duties apply from August 2, 2026 to specified AI interactions/content, but are not themselves a generic memory-management mandate	European Commission Article 50 guidelines 18	Regulatory / official guidance	Avoid conflating AI-interaction disclosure with memory-specific rights
Persistent-agent economics may need artifact/outcome-level measurement rather than token counts alone	Persistent AI Agents in Academic Research: A Single-Investigator Implementation Case Study 13	Production-style single-case report	Suggestive, non-causal and not independently generalizable

Decision reversals

Persistent memory should be considered reversible infrastructure, not a permanent maturity milestone.

Observed change	Why the original memory decision may no longer hold	Appropriate reversal
Better project documentation eliminates repeated context loss	Memory was compensating for information-management weakness	Replace memory with project artifacts
CRM/ERP gains required fields/integration	Previously implicit information now has authoritative representation	Migrate facts to system of record; retain at most pointers
RAG/search quality improves enough to match outcomes	Persistence no longer creates incremental value	Remove knowledge-like memories
Larger/cheaper context models eliminate measurable advantage	Cost/quality trade-off changed	Return to explicit/history context where safer
Memory gain exists only for preferences	Broad memory scope was unnecessary	Restrict to user-preference namespace
Learned agent lessons stabilize	Experience has become repeatable procedure	Promote memories into reviewed runbooks/tests and delete redundant free-form copies
Stale-memory errors rise as business changes faster	Assumed half-life is invalid	Shorten TTL, add live validation, or remove value caching
Memory becomes a de facto CRM/knowledge database	Authority boundary has failed	Move data into proper system and rebuild memory as derived cache
Users frequently correct inferred preferences	Inference precision/value is too low	Require explicit preference capture
Deletion/correction cannot be reliably propagated	Lifecycle control is inadequate	Disable new writes; redesign or remove persistence
Cross-user/project isolation cannot be demonstrated	Security boundary is unacceptable	Disable affected memory layer immediately
Poisoning tests reach consequential actions	Write/read/action boundary is inadequate	Return to shadow/read-only mode or remove memory until redesigned
Provider cannot export data/provenance	Lock-in risk became material	Move to application-owned representation
Governance/support cost exceeds user-effort savings	Unit economics changed	Simplify or remove memory
Task success is statistically/practically equivalent to simpler baseline	Memory has no demonstrated incremental value	Use simpler architecture
Regulatory or contractual constraints change	Previously acceptable persistence may no longer be permissible or economical	Reduce scope, residency, retention, or eliminate persistence
A high-severity incident shows memory can grant durable attacker influence	Expected security loss changed materially	Suspend writes and reconsider whether persistence belongs in the workflow

The most important reversal signal is not that memory occasionally makes mistakes; all context mechanisms can fail. It is that persistent memory ceases to deliver incremental value over a simpler architecture after the cost of corrections, stale state, security controls, privacy governance and operations is counted.

The defensible organizational posture at the October 3, 2026 research snapshot is therefore:

Use persistent AI memory narrowly for information whose value genuinely comes from accumulated cross-session experience—especially stable soft preferences and validated experiential lessons. Keep authoritative facts in authoritative systems, changing knowledge in retrievable sources, transactions and workflow progress in structured state, durable instructions in version-controlled artifacts, and temporary information transient. Expand memory only after a controlled pilot proves better task outcomes and positive lifecycle economics against those simpler alternatives. The research supports the technical value of selective long-term memory, but it simultaneously shows that retrieval architecture, context strategy, latency, freshness and persistent attack surfaces are material enough that “more memory” is not a valid proxy for a more capable enterprise AI system. 1