# 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](https://arxiv.org/abs/2410.10813)

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](https://arxiv.org/abs/2407.12784)

## 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](https://docs.langchain.com/oss/python/concepts/memory)

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](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

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](https://arxiv.org/abs/2502.12110)

A practical default for a new system is therefore:

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

</table>

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](https://arxiv.org/abs/2407.12784)

## 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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://arxiv.org/abs/2404.13208)

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

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

</table>

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](https://docs.langchain.com/oss/python/concepts/memory)

**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](https://arxiv.org/abs/2410.10813)

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](https://arxiv.org/abs/2503.03704)

**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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://aclanthology.org/2024.tacl-1.9/) 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](https://www.trychroma.com/research/context-rot)

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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

## 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](https://docs.langchain.com/oss/python/concepts/memory) 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.

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

</table>

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](https://google.github.io/adk-docs/sessions/memory/)

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](https://docs.langchain.com/oss/python/concepts/memory)

**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](https://docs.langchain.com/oss/python/concepts/memory)

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](https://docs.langchain.com/oss/python/concepts/memory)

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](https://google.github.io/adk-docs/sessions/memory/)

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

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

</table>

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](https://docs.langchain.com/oss/python/concepts/memory)

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](https://arxiv.org/abs/2503.03704)

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:

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

</table>

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](https://arxiv.org/abs/2502.12110)

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](https://docs.langchain.com/oss/python/concepts/memory)

**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](https://hl7.org/fhir/provenance.html)

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](https://hl7.org/fhir/provenance.html)

**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](https://doi.org/10.1145/3586183.3606763) 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.”<br>
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](https://github.com/getzep/graphiti)

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](https://github.com/getzep/graphiti)

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](https://arxiv.org/abs/2410.10813)

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

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

</table>

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](https://ojs.aaai.org/index.php/AAAI/article/view/29946)

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](https://help.openai.com/en/articles/8590148-memory-in-chatgpt)

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.

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

</table>

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](https://google.github.io/adk-docs/sessions/memory/)

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](https://arxiv.org/abs/2410.10813)

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](https://aclanthology.org/2024.tacl-1.9/) 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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://arxiv.org/abs/2605.12493) 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.**

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

</table>

*Lost in the Middle* provides strong empirical evidence against assuming that nominal context length equals dependable access to all tokens. [10](https://aclanthology.org/2024.tacl-1.9/) Chroma's Context Rot report extended this observation across larger token loads. [11](https://www.trychroma.com/research/context-rot) 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](https://arxiv.org/abs/2410.10813)

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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://journals.sagepub.com/doi/10.3233/FAIA251160) 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](https://journals.sagepub.com/doi/10.3233/FAIA251160) 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.

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

</table>

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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

## 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](https://arxiv.org/abs/2410.10813)

A production suite should explicitly contain the following scenarios:

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

</table>

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](https://arxiv.org/abs/2410.10813) MemoryAgentBench's focus on conflict resolution and long-range behavior likewise argues for end-to-end evaluation rather than isolated vector-search metrics. [21](https://arxiv.org/abs/2507.05257)

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](https://opentelemetry.io/)

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](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

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](https://arxiv.org/abs/2407.12784)

MINJA goes further: it demonstrates memory injection through normal query interaction and output observation, without requiring direct write access to the memory database. [24](https://arxiv.org/abs/2503.03704) 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](https://arxiv.org/abs/2601.05504)

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](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

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](https://github.com/getzep/graphiti/issues/1676)

The merged fix replaced shared mutation with a request-scoped driver/client bundle. [27](https://github.com/getzep/graphiti/pull/1699) 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:

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

</table>

LongMemEval-V2 demonstrates the trade-off vividly: its most accurate coding-agent memory approach outperformed RAG but incurred high latency. [19](https://arxiv.org/abs/2605.12493) Anthropic similarly notes that just-in-time runtime exploration can avoid loading enormous objects but is slower than precomputed retrieval. [7](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

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.

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

</table>

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](https://aclanthology.org/2024.tacl-1.9/) 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](https://arxiv.org/abs/2501.13956) 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](https://journals.sagepub.com/doi/10.3233/FAIA251160) 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](https://arxiv.org/abs/2503.03704) 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](https://docs.langchain.com/oss/python/concepts/memory) 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](https://ojs.aaai.org/index.php/AAAI/article/view/29946) 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](https://arxiv.org/abs/2605.12493) 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](https://aclanthology.org/2024.acl-long.747/) AgentPoison, MINJA, long-context studies and the Graphiti isolation bug demonstrate new failure modes created by memory and retrieval infrastructure. [32](https://arxiv.org/abs/2407.12784)

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.

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

</table>

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](https://journals.sagepub.com/doi/10.3233/FAIA251160) GitHub bug reports provide unusually useful operational detail but remain practitioner reports, not independent incident investigations. [26](https://github.com/getzep/graphiti/issues/1676)

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

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

</table>

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](https://arxiv.org/abs/2410.10813)

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.**