Agentic Systems

Research Brief — Agent Memory: SOTA Systems, Storage, and Context Efficiency (2025–2026)

Working research note — source-verified but not part of the reviewed reference site; citations resolve within this document's own Sources section.

Prepared: 2026-07-09. Audience: agentic-systems knowledge base; expands content/foundations/memory.md (status: reviewed) into a state-of-the-art survey of memory systems, memory-specific storage, and context-efficient memory usage. Sources cited in-text by id; full list (URLs verified 2026-07-09, AriGraph entries 2026-07-13) in the Sources section in references.yaml format. Companion briefs: retrieval-rag-sota.md, agent-loops-planning-sota.md, orchestration-algorithms-sota.md. This brief keeps the foundations page's vocabulary — context window vs durable memory, parametric vs non-parametric memory (Lewis et al.), the episodic/semantic/procedural taxonomy, hot-path vs background formation, context engineering, compaction — and deepens each term rather than redefining it.


1. Executive summary

Six shifts define agent-memory SOTA in 2025–2026:

  1. Memory became self-managed. MemGPT's OS metaphor — a small in-context core plus large out-of-context storage, with the agent itself editing memory through tools — went from paper (Oct 2023) to product default: Letta memory blocks, LangMem manage-memory tools, and Anthropic's API-level memory tool all implement the same self-editing pattern [memgpt-paper] [letta-memory-blocks] [langmem-concepts] [anthropic-memory-tool-docs].
  2. Files became a legitimate SOTA memory backend. The strongest coding agents persist memory as plain markdown read and written with ordinary file tools — Claude Code's CLAUDE.md + auto-memory, Anthropic's /memories file tool, Manus's filesystem-as-context; transparency, git versioning, and zero infrastructure beat a vector store here [claude-code-memory-docs] [anthropic-memory-tool-docs] [manus-context-engineering].
  3. The storage differentiator moved past the vector index. The ANN/vector-DB layer is a commodity (see retrieval-rag-sota.md §3–4); what distinguishes memory stores is mutability (Mem0's ADD/UPDATE/DELETE/NOOP consolidation) and time (Graphiti's bi-temporal knowledge graph, which invalidates edges instead of deleting them) [mem0-paper] [graphiti-github] [zep-paper].
  4. Efficiency = context engineering. Memory design is budgeted in tokens and cache hits: context rot caps how much to preload [context-rot-chroma] [anthropic-context-engineering]; KV-cache economics (10× cached/uncached price gap) punish churning memory blocks in the prompt prefix [manus-context-engineering]; Anthropic measured memory + context editing at +39% over baseline with 84% fewer tokens on a 100-turn task [anthropic-context-management-news].
  5. Evaluation is genuinely contested. Mem0 and Zep both claim LoCoMo victory with incompatible numbers (§3.2, §6.2); on Mem0's own table a full-context baseline beats every memory system tested. LongMemEval (ICLR 2025) is the more diagnostic bar — commercial assistants drop 30% accuracy [mem0-paper] [zep-mem0-response] [longmemeval-paper].
  6. The frontier is trained, not prompted, memory management. RL now shapes memory operations themselves: Memory-R1 (PPO/GRPO over ADD/UPDATE/DELETE/NOOP), MemAgent (RL-trained overwrite memory extrapolating to 3.5M-token inputs), Memp (learned procedural memory) — the prompted→trained arc the companion briefs document for retrieval and loops [memory-r1-paper] [memagent-paper] [memp-paper].

2. Architectures and methodologies

2.1 The MemGPT paradigm: virtual context management

MemGPT ("MemGPT: Towards LLMs as Operating Systems", Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez; arXiv:2310.08560, Oct 2023) framed the problem as the foundations page does — the context window is scarce working memory, durable memory lives outside — and added the OS analogy: virtual context management, inspired by how operating systems create "the appearance of large memory resources through data movement between fast and slow memory" [memgpt-paper]. Concretely:

  • Main context (in-window): system instructions + a read/write core memory + a FIFO message queue. External context (out-of-window): recall storage (full message history) and archival storage (arbitrary documents/facts), searched on demand.
  • The LLM edits its own memory via tool calls, with OS-style interrupts managing control flow. Memory management becomes part of the agent's policy, not the host's plumbing — the key break from static RAG pipelines, and the direct ancestor of Anthropic's "structured note-taking / agentic memory" pattern [anthropic-context-engineering].
  • Productization: Letta (the same team; the repo is explicitly "formerly MemGPT", Apache-2.0) turned core memory into memory blocks — labeled, size-limited sections "of the agent's context window that persist across all interactions … always visible - no retrieval needed," editable by the agent's built-in memory tools and shareable between agents [letta-github] [letta-memory-blocks].

2.2 CoALA: the organizing taxonomy

Cognitive Architectures for Language Agents (CoALA; Sumers, Yao, Narasimhan, Griffiths; arXiv:2309.02427, TMLR) is the frame the field converged on: an agent = modular memory components + a structured action space (internal memory actions vs external environment actions) + a decision loop [coala-paper]. Its memory split — working memory (the active context) vs long-term episodic / semantic / procedural stores — is the taxonomy the foundations page adopts via LangMem [langmem-concepts]:

CoALA term Foundations-page term Typical 2025–26 realization
Working memory context-window / short-term-memory transcript + scratchpad + core memory blocks
Semantic memory semantic-memory (facts) profile documents or searchable collections
Episodic memory episodic-memory (experiences) stored trajectories / few-shot exemplars; Reflexion's verbal lessons (see agent-loops-planning-sota.md §2)
Procedural memory procedural memory (how to behave) evolving system prompts, CLAUDE.md-style instruction files, Memp's learned scripts

CoALA's extra distinction — memory reads and writes are actions in the agent's action space — predicts the hot-path tool designs below.

2.3 Memory formation: hot path, background, reflection, forgetting

The foundations page's LangMem distinction — hot path (extract during the conversation) vs background ("subconscious" reflection after it) [langmem-concepts] — is the right axis for all current write-path designs:

  • Hot-path tools. Letta's self-editing block tools, LangMem's create_manage_memory_tool, Anthropic's memory tool (file edits during the task) — the agent decides now what to persist [letta-memory-blocks] [langmem-github] [anthropic-memory-tool-docs].
  • Background extraction/consolidation. Mem0's pipeline is the canonical shape: an extraction phase (LLM reads the new message pair + conversation summary + recent context, emits candidate facts) then an update phase comparing each fact against existing memories and choosing one of four operations — ADD (no semantic equivalent exists), UPDATE (augment with complementary detail), DELETE (contradicted information), NOOP [mem0-paper].
  • Reflection. Generative Agents (Park, O'Brien, Cai, Morris, Liang, Bernstein; arXiv:2304.03442, Apr 2023) introduced the mechanism the field still copies: a memory stream of timestamped observations, retrieval scored score = α·recency + α·importance + α·relevance (exponential recency decay 0.995; LLM-rated importance 1–10; embedding relevance; all α = 1), and reflection triggered when summed importance of recent events exceeds a threshold (150), synthesizing observations into "higher-level, more abstract thoughts" stored back into the stream [generative-agents-paper]. LangMem's episodic "preserve successful interactions as learning examples" is this pattern narrowed to wins [langmem-concepts].
  • Forgetting/decay. Still engineered, not learned: recency-decayed retrieval [generative-agents-paper], LlamaIndex's priority-ordered truncation of memory blocks [llamaindex-memory], guidance to expire memory files not accessed recently [anthropic-memory-tool-docs]. No forgetting policy has benchmark-backed consensus (§7).
  • Sleep-time compute. Letta's verifiable form of background formation: a sleep-time agent shares memory blocks with the primary agent and runs asynchronously, transforming "raw context" into "learned context" between interactions [letta-sleep-time-blog]. The paper (Lin, Snell, Wang, Packer, Wooders, Stoica, Gonzalez; arXiv:2504.13171, Apr 2025) shows offline pre-thinking about a context cuts test-time compute ~5× at equal accuracy on Stateful GSM-Symbolic / Stateful AIME, raises accuracy up to +13%/+18% when scaled, and amortizes 2.5× across related queries [sleep-time-compute-paper].

2.4 The frontier: RL-shaped memory management

Three verifiable 2025–26 research lines train what §2.3 prompts:

  • Memory-R1 (Yan et al.; arXiv:2508.19828, Aug 2025, revised Jan 2026): fine-tunes a Memory Manager (learns ADD/UPDATE/DELETE/NOOP decisions) and an Answer Agent (filters retrieved candidates before reasoning) with outcome-driven PPO/GRPO — from only 152 QA pairs — and reports gains over static-pipeline baselines on LoCoMo, MSC, and LongMemEval across 3B–14B models [memory-r1-paper]. Consolidation becomes a learned policy.
  • MemAgent (Yu et al.; arXiv:2507.02259, Jul 2025): reads documents in segments while maintaining a fixed-length, overwritable memory, trained end-to-end with a multi-conv RL extension of DAPO. Trained with an 8K context on 32K-token texts, it extrapolates to 3.5M-token QA with <5% performance loss and scores 95%+ on 512K RULER [memagent-paper] — memory as a learned compression policy, the RL counterpart of compaction (§5.4).
  • Memp (Fang et al.; arXiv:2508.06433, Aug 2025; ACL 2026 Findings): distills past trajectories into procedural memory — "fine-grained, step-by-step instructions and higher-level, script-like abstractions" — with explicit build/retrieve/update strategies; success climbs as the repository is refined (TravelPlanner/ALFWorld), and procedural memory from a stronger model transfers to weaker ones [memp-paper].

Same arc as retrieval (Search-R1) and loops (SWE-RL) in the companion briefs: prompted scaffold first, then its decisions internalized by RL.

2.5 AriGraph: episodic + semantic memory in one knowledge-graph world model

AriGraph ("AriGraph: Learning Knowledge Graph World Models with Episodic Memory for LLM Agents"; Anokhin, Semenov, Sorokin, Evseev, Kravchenko, Burtsev, Burnaev — AIRI, Skoltech, London Institute for Mathematical Sciences, Oxford; arXiv:2407.04363, Jul 2024; IJCAI-25 main track, pp. 12–20) is the research architecture that takes §2.2's episodic/semantic split most literally: "the agent constructs and updates a memory graph that integrates semantic and episodic memories while exploring the environment" [arigraph-paper]. The frame is a world model learned by acting, not a conversation store: "As an agent interacts with environment, it learns joint semantic and episodic world model by updating and extending knowledge graph based memory" [arigraph-ijcai]. Mechanics:

  • One graph, two memory types. Semantic memory is a knowledge graph of (object1, relation, object2) triplets the LLM extracts from each textual observation; episodic memory lives in the same graph: every observation becomes an episodic vertex, and an episodic edge "connects all semantic triplets" extracted from that observation "with each other and corresponding episodic vertex" — episodic edges "represent temporal relationship 'happened at the same time'" [arigraph-ijcai].
  • Write path — §4's mutability, by deletion. On each new observation the agent extracts fresh triplets, gathers existing semantic edges incident to the objects mentioned, and stale edges are "detected by comparing them with" the new triplets "and removed from the graph" before the new knowledge is added [arigraph-ijcai]. Where Graphiti invalidates superseded edges with timestamps and keeps history (§4.2), AriGraph deletes them — simpler, but it forfeits "what was true before X?" queries.
  • Read path — embedding search plus graph traversal. Two stages: a semantic search (a pre-trained Contriever retriever selects relevant triplets, then traversal recursively expands from their incident vertices; "Depth and breadth of the search can be controlled by respective hyperparameters d and w") feeds an episodic search that ranks past observations by how many retrieved triplets they connect, with a log weighting factor "to prevent high scores for low information observations" [arigraph-ijcai].
  • The agent on top: Ariadne. AriGraph as long-term memory + a working memory (goal, current observation, recent actions, retrieved semantic/episodic knowledge) + a planning module that maintains task-relevant sub-goals + a decision module following ReAct, "requiring the agent to articulate the rationale behind an action before execution". The graph also extends the action space: "go to location" commands infer "an optimal route to a target location using spatial relations stored in a semantic graph" [arigraph-ijcai].

Evaluation is games-and-QA, not assistant-memory benchmarks. In TextWorld POMDP games (Treasure Hunt, Cleaning, Cooking, plus Hard/Hardest variants — environments "difficult even for human players" [arigraph-paper]), agents differed only in the memory module; baselines: "full history of observations and actions, iterative summarization, RAG, RAG with Reflexion, and Simulacra" (the Generative-Agents scoring of §2.3), all on gpt-4-0125-preview [arigraph-ijcai]. The abstract's claim that the approach "markedly outperforms other established memory methods and strong RL baselines" [arigraph-paper] cashes out as: "Baseline agents are unable to solve the Treasure Hunt, and fail to find even second key in the Treasure Hunt Hardest," while Ariadne solves the basic version "in about fifty steps"; "Ariadne outperforms average human player from our sample on all tasks, and scores similarly to the best human plays in the Cooking and the Treasure Hunt, but underperforms in the Cleaning"; and it beats the GATA / LTL-GATA / EXPLORER RL agents on all four cooking difficulty levels [arigraph-ijcai]. On NetHack (GPT-4o, NetPlay scaffold), Ariadne restricted to room-only observations scored 593.00 ± 202.62 game score (6.33 ± 2.31 dungeon levels) vs 341.67 ± 109.14 for NetPlay with the same partial view — "comparable to the baseline with memory oracle" (NetPlay with full-level observations: 675.33 ± 130.27) [arigraph-ijcai]. On static multi-hop QA (MuSiQue, HotpotQA; 200 samples each) AriGraph (GPT-4) scored 45.0 EM / 57.0 F1 and 68.0 EM / 74.7 F1 respectively — above ReadAgent, GraphReader, GPT-4 RAG, and GPT-4 full-context; HOLMES leads MuSiQue (48.0 EM) with AriGraph "comparable"; and the paper reports its approach "more then 10x cheaper" [sic] than GraphRAG [arigraph-ijcai].

Position in this brief's landscape — the difference is the direction of fit. Zep/Graphiti and Mem0-g build graphs from conversation so an assistant can answer later questions (§3, §4); the KG-RAG line — GraphRAG, HippoRAG (retrieval-rag-sota.md §6.2) — builds graphs from static corpora; AriGraph builds its graph from the agent's own exploration and spends it on planning, navigation, and action selection. The paper positions itself against GraphRAG/HippoRAG/GraphReader/HOLMES on exactly this: "these studies do not address the context of functioning within an interactive environment, nor do they take into account the updates to knowledge graphs prompted by new experiences" [arigraph-ijcai]. Honest caveats: it is a research prototype, not a product — the official repo (AIRI-Institute/AriGraph, MIT, ~171 stars) covers the five TextWorld environments plus the QA benchmarks and has had no pushes since Sep 2024 [arigraph-github]; there are no LoCoMo/LongMemEval numbers, so §3.2/§6 evidence does not transfer; deletion-based updates lose temporal history (§4.2); and the authors list the missing pieces themselves — "multi-modal observations, procedural memories, and more sophisticated graph search methods" [arigraph-ijcai]. Its durable contribution here is the demonstration that a jointly episodic+semantic graph, updated on experience, turns memory into a world model an agent can plan over — the interactive counterpart of §4's temporal knowledge graphs.


3. The memory-systems landscape (tools)

3.1 Comparative map

System Core design (one sentence) Read path Write path Storage backend License/hosting
Letta (MemGPT) Stateful-agent server; in-context memory blocks + out-of-context archival/recall per the MemGPT hierarchy Preloaded blocks (always in-window) + retrieval tools over archival/recall Hot-path self-editing tools; optional background sleep-time agents Server database; block/archival state persisted server-side Apache-2.0 OSS + Letta Cloud [letta-github] [letta-memory-blocks]
Mem0 Extraction→update pipeline distilling conversations into consolidated facts Retrieval API (semantic search over memories), per user/agent/session Per-exchange pipeline: extract candidate facts, then ADD/UPDATE/DELETE/NOOP against the store Vector store (+ optional graph memory in Mem0-g); pluggable Apache-2.0 OSS + hosted platform (app.mem0.ai) [mem0-paper] [mem0-github]
Zep (Graphiti) Memory service over a temporally-aware knowledge graph that "dynamically synthesizes both unstructured conversational data and structured business data" Hybrid search: semantic embeddings + BM25 + graph traversal (no LLM in the read path; sub-second target) Background ingestion of episodes → entity/edge extraction with temporal edge invalidation Graph DB: Neo4j, FalkorDB, Amazon Neptune (Kuzu deprecated) Graphiti engine Apache-2.0; Zep is a commercial service [zep-paper] [graphiti-github]
LangMem SDK of memory primitives (managers, tools, prompt optimizer) over LangGraph's BaseStore create_search_memory_tool (semantic/metadata search) or preloading from the store Hot-path create_manage_memory_tool and/or background memory manager Any BaseStore: InMemoryStore, Postgres (store is optional) MIT OSS [langmem-github] [langmem-concepts]
LlamaIndex memory One Memory object: FIFO short-term queue that flushes into pluggable long-term memory blocks Blocks injected into the system or user message (insert_method), merged with chat history Automatic: when history exceeds chat_history_token_ratio (0.7 of a 30K default token_limit), the oldest ~token_flush_size (3K) tokens flush into blocks StaticMemoryBlock / FactExtractionMemoryBlock (LLM facts, summarized at max_facts) / VectorMemoryBlock (vector DB) OSS (LlamaIndex framework) [llamaindex-memory]
OpenAI ChatGPT memory Product-level design: explicit "saved memories" plus automatic profiling from chat history (expanded to reference all past conversations, Apr 10, 2025) Preloaded into the system prompt: timestamped "Model Set Context" plus generated profile sections (response preferences, user insights, ~40 recent-conversation summaries per independent analysis) Hot-path bio tool for saved memories; background profile building from history Proprietary Closed product feature [chatgpt-memory-analysis] [chatgpt-memory-april-2025]
Anthropic memory tool API-level file-based memory: Claude requests file operations under /memories; your application executes them Just-in-time: Claude is instructed to view its memory directory before starting a task, then reads files on demand Hot-path file ops: view, create, str_replace, insert, delete, rename Client-controlled (filesystem, DB, object store — the /memories prefix maps to storage you own) Tool type memory_20250818, GA on the Messages API; pairs with context editing and server-side compaction [anthropic-memory-tool-docs]
Claude Code Files-as-memory for a coding agent: user-authored CLAUDE.md instructions + agent-authored auto-memory notes CLAUDE.md files loaded in full at launch (ancestor directories; subdirectory files on demand); auto-memory MEMORY.md preloaded up to 200 lines / 25KB, topic files read on demand You write CLAUDE.md; Claude writes auto memory itself during sessions ("Writing memory") Plain markdown on disk (./CLAUDE.md, ~/.claude/CLAUDE.md, ~/.claude/projects/<project>/memory/) Product feature; files are user-ownable/versionable [claude-code-memory-docs]

Convergent design across all rows: a small always-in-context core (blocks, profiles, MEMORY.md index, Model Set Context) plus a large retrieved store (archival, collections, graph, topic files) — the foundations page's context-window vs durable-memory split, engineered twice at different scales.

3.2 The LoCoMo dispute — report, don't adjudicate

Both Mem0 and Zep claim LoCoMo victory, with irreconcilable numbers; the honest summary:

  • Mem0's paper (arXiv:2504.19413) reports LLM-as-a-Judge (J) scores: Mem0 66.88 ± 0.15, Mem0-g 68.44 ± 0.17, and — as measured by Mem0's harness — Zep 65.99 ± 0.16, LangMem 58.10 ± 0.21, OpenAI memory 52.90 ± 0.14; plus 91% lower p95 latency than full-context (1.44 s vs 17.12 s) and >90% token savings (~7K vs ~26K tokens) [mem0-paper].
  • Zep's response ("Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory?", May 6, 2025, since corrected in-place) claims Mem0's Zep integration was misconfigured — both speakers assigned the user role in a single-user graph model, timestamps embedded in message text instead of Zep's created_at field, sequential rather than concurrent searches inflating latency — and reports a corrected Zep score of 75.14 ± 0.17, ~10% relative above Mem0-g. Zep itself initially published a larger margin and had to correct its own arithmetic [zep-mem0-response].
  • The most load-bearing number is uncontested: in Mem0's own table the full-context baseline scores 72.90 ± 0.19, beating every memory system Mem0 tested including its own [mem0-paper]. On this benchmark, memory systems buy latency and token savings, not accuracy. Newer self-reported scores (e.g., Mem0's Apr 2026 claim of 92.5 LoCoMo / 94.4 LongMemEval for a new algorithm [mem0-github]) are vendor-run and not independently replicated — treat LoCoMo leaderboard claims as marketing until a neutral harness reproduces them (§6.2).

4. Storage for memory — what memory needs beyond a vector index

The vector-database landscape, index internals, and quantization are owned by the companion brief — see retrieval-rag-sota.md §3–4; none of that is repeated here. A memory store is non-parametric memory in the Lewis et al. sense (inspectable, updatable, grown without retraining), but memory imposes requirements a document RAG corpus never exercises:

  1. Mutability and updates-in-place. RAG corpora are append-mostly; memories are about a changing world ("moved to Berlin", "switched from Postgres"). Two production answers: consolidation at write time — Mem0's UPDATE/DELETE against semantically equivalent facts [mem0-paper] — and invalidation instead of deletion — Graphiti marks superseded edges invalid with timestamps, preserving history [graphiti-github]. Naive append-only collections accumulate contradictions that retrieval surfaces side-by-side; LongMemEval's knowledge-updates ability tests exactly this failure [longmemeval-paper].
  2. Temporal validity (bi-temporal modeling). Graphiti tracks both when a fact became true in the world and when the system learned/superseded it, so the graph can be queried as of any point in time; Zep credits this temporally-aware design for its LongMemEval gains (up to +18.5% accuracy, ~90% latency reduction vs full-context baselines) and its DMR result (94.8% vs MemGPT's 93.4%) [zep-paper] [graphiti-github]. Flat vector stores have no native answer to "what did the user prefer before March?"
  3. Namespacing and isolation. Memory is per-principal by construction. LangGraph's store organizes JSON documents by namespace tuples + keys (the foundations page's store.put(namespace, key, value) model) [langgraph-persistence]; Letta scopes blocks per agent and shares them deliberately [letta-memory-blocks]; Anthropic's memory tool maps the /memories prefix onto per-user storage the application controls, with path-traversal validation called out as the application's security obligation [anthropic-memory-tool-docs]. Isolation is also an attack surface: memory written today is prompt input tomorrow (§7).
  4. Relational structure — when each shape wins. Three tiers seen in practice: profile documents (schema-constrained JSON, one per user — LangMem profiles) when the fact set is small and stable — cheapest to preload, trivially auditable; flat collections (searchable facts — LangMem collections, Mem0 default) when knowledge is unbounded but questions are single-hop; temporal knowledge graphs (Zep/Graphiti, Mem0-g) when answers require joining entities across sessions and time — Mem0's ablation gives the graph variant ~2% overall (more on temporal/multi-hop) at roughly double the token cost [mem0-paper] [langmem-concepts] [zep-paper]. Graph wins track the query classes GraphRAG serves (retrieval brief §6.2); the memory-specific addition is time.
  5. Hybrid deployments in practice. Memory state rarely lives in one engine: LangGraph pairs a checkpointer for short-term thread state (SqliteSaver for local development, PostgresSaver in production) with a store for cross-thread memory (InMemoryStore, PostgresStore) [langgraph-persistence] — Postgres+pgvector keeping transcripts, checkpoints, memories, and vectors in one transactional system (retrieval-rag-sota.md §4 covers when pgvector suffices); Zep adds Neo4j/FalkorDB/Neptune for the graph tier [graphiti-github]; Mem0 splits vector + optional graph store [mem0-paper] [mem0-github].
  6. Plain files as a SOTA endpoint. For coding agents, markdown searched with grep/read is not a fallback but a deliberate design: Claude Code loads CLAUDE.md hierarchies and an auto-memory index at session start and greps/reads the rest on demand [claude-code-memory-docs]; the memory tool generalizes the same file model to any API agent [anthropic-memory-tool-docs]; Manus treats the filesystem as unlimited, persistent, agent-operable context, using restorable compression (keep the path/URL in context, drop the content — it can always be re-read) [manus-context-engineering]. Why it works: transparency (the user can read and edit every memory), versioning for free (git history, code review of CLAUDE.md changes), zero infrastructure, and a perfect impedance match with tools the agent already has. Trade-offs: lexical not semantic search; machine-local scope (Claude Code's auto memory is explicitly not shared across machines) [claude-code-memory-docs].

5. Efficient memory usage = context engineering

The foundations page's closing claim — good agent design is deciding what occupies the window each moment — is now a costed engineering discipline. Anchors: Anthropic's attention-budget framing and context rot [anthropic-context-engineering]; Chroma's measurement of it — across 18 models (GPT-4.1, Claude 4, Gemini 2.5, Qwen3), reliability degrades with input length even on trivially simple tasks, faster when needle-question similarity is low or distractors are present, and — counterintuitively — structured haystacks hurt more than shuffled ones [context-rot-chroma]. Every preloaded memory token spends this budget.

5.1 Progressive disclosure: index in context, fetch on demand

The pattern that reconciles "always available" with "never bloated": preload a small index, retrieve details just-in-time (the foundations page's just-in-time retrieval, applied to memory). Claude Code is the cleanest production instance: only the first 200 lines / 25KB of MEMORY.md — kept deliberately as a concise index of the memory directory — load at session start; topic files (debugging.md, api-conventions.md) are read on demand with standard file tools [claude-code-memory-docs]. The memory tool bakes the same protocol into its system prompt ("ALWAYS VIEW YOUR MEMORY DIRECTORY BEFORE DOING ANYTHING ELSE"), making memory lookup the first just-in-time retrieval of every task [anthropic-memory-tool-docs] [anthropic-context-engineering].

5.2 KV-cache economics: why churning a memory block breaks the bank

Manus's production lesson: KV-cache hit rate is "the single most important metric for a production-stage AI agent" — with Claude Sonnet, cached input tokens cost $0.30/MTok vs $3.00/MTok uncached, a 10× gap [manus-context-engineering]. Prefix caching only reuses the prefix up to the first changed token, so a memory block that sits early in the prompt (the system region — where Letta blocks and ChatGPT's Model Set Context live) and is rewritten every turn invalidates the cache for everything after it, forcing a full re-prefill of the transcript each turn. Practical rules [manus-context-engineering]: keep the prompt prefix stable (a timestamp in the system prompt is a one-token cache killer), make context append-only with deterministic serialization, and mask tools rather than add/remove them. For memory specifically: batch block edits, place volatile state late in the context or in files, and let stable instruction memory (CLAUDE.md-style) stay byte-identical across turns.

5.3 Token-cost arithmetic: preloaded block vs retrieval tool

  • A preloaded block of B tokens is re-sent on every request: T turns cost T×B input tokens (discounted, not eliminated, by caching). A retrieval tool costs only its schema plus retrieved content when used. Preloading wins for small, high-frequency, every-turn content (identity, rules, task state); retrieval wins for large or rarely-needed content — which is why every system in §3 caps its preloaded tier: Letta block character limits; Claude Code's 200-line/25KB MEMORY.md ceiling and its guidance to keep CLAUDE.md under ~200 lines because "longer files consume more context and reduce adherence" [letta-memory-blocks] [claude-code-memory-docs].
  • The same arithmetic is Mem0's entire pitch against full-context replay: ~7K tokens per query vs ~26K full context, >90% token savings, 91% lower p95 latency — bought, per §3.2, at some accuracy cost vs full context on LoCoMo [mem0-paper].

5.4 Compaction and summarization — and their failure modes

The foundations page defines context-compaction and warns it is lossy; the SOTA additions are mechanical and numeric:

  • Context editing (Anthropic, Sep 29, 2025, with Claude Sonnet 4.5): automatically clear stale tool results instead of summarizing — +29% over baseline alone; +39% combined with the memory tool, and 84% token reduction on a 100-turn web-search evaluation [anthropic-context-management-news]. The division of labor: compaction/editing keeps the live window small; memory preserves what must survive summarization [anthropic-memory-tool-docs].
  • Failure modes. (1) Detail loss: "overly aggressive compaction can result in the loss of subtle but critical context" whose value appears only later [anthropic-context-engineering]. (2) Error snowballing: once a summary replaces primary text, later summaries compound its omissions — Manus prefers restorable compression (drop content, keep the identifier) over irreversible summarization [manus-context-engineering]. (3) Instruction loss across resets: Claude Code re-injects the project-root CLAUDE.md from disk after /compact because conversation-only instructions do not survive compaction [claude-code-memory-docs]. MemAgent (§2.4) is this trade-off trained: RL learns what to keep under a fixed budget [memagent-paper].

5.5 Structured note-taking and recitation

Anthropic's structured note-taking — the agent persists notes outside the window and retrieves them later (Claude playing Pokémon keeping strategy notes across thousands of steps; NOTES.md/to-do files) [anthropic-context-engineering] — has a cheap attention-level variant: recitation. Manus's agent rewrites a todo.md at each step, pushing the global plan into the end of context where attention is strongest, explicitly to fight lost-in-the-middle effects, and keeps failed actions in context so the model updates away from them [manus-context-engineering]. This is the memory-side twin of the progress-file harness pattern in agent-loops-planning-sota.md §8 (memory files + git).


6. Evaluating memory

6.1 LongMemEval — the current diagnostic bar

LongMemEval (Wu, Wang, Yu, Zhang, Chang, Yu; arXiv:2410.10813; ICLR 2025): 500 questions embedded in freely scalable multi-session chat histories, testing five abilities — information extraction, multi-session reasoning, temporal reasoning, knowledge updates, abstention. Headline: commercial assistants and long-context LLMs show a 30% accuracy drop on sustained-interaction memory; the paper also frames memory-system design as indexing / retrieval / reading, with session decomposition, fact-augmented key expansion, and time-aware query expansion as effective optimizations [longmemeval-paper]. Its ability split maps onto §4 (knowledge updates ↔ mutability; temporal reasoning ↔ bi-temporal modeling; abstention ↔ not retrieving).

6.2 LoCoMo — widely used, seriously criticized

LoCoMo (Maharana, Lee, Tulyakov, Bansal, Barbieri, Fang; arXiv:2402.17753, Feb 2024): machine-generated very-long-term dialogues (LLM agents with personas grounded in temporal event graphs, human-verified), ~300 turns / ~9K tokens on average over up to 35 sessions per the paper — with QA, event summarization, and multimodal dialogue tasks [locomo-paper]. It became the de-facto vendor benchmark (§3.2), and that is the problem:

  • Zep's critique: the evaluated conversations (~16K–26K tokens) fit inside modern context windows, so LoCoMo does not truly test long-term memory; it barely tests knowledge updates; and it has quality defects — missing ground truth, wrong speaker attributions, ambiguous questions [zep-mem0-response].
  • The full-context baseline outscoring every memory system in Mem0's own results (72.90 J, §3.2) confirms the benchmark under-rewards actual memory management [mem0-paper].
  • Confound in all vendor numbers: each vendor runs competitors through its own harness and prompts (Mem0's Zep misconfiguration claims cut both ways) — scores are comparable only within one harness, never across papers [zep-mem0-response].

6.3 MemBench and what is still unmeasured

MemBench (Tan, Zhang, Ma, Chen, Dai, Dong; arXiv:2506.21605; ACL 2025 Findings) broadens the probe: factual and reflective memory levels, participation vs observation scenarios, metrics covering effectiveness, efficiency, and capacity [membench-paper] — a mainstream benchmark finally scoring efficiency (§5's concern) rather than accuracy alone.

The benchmark↔production gap remains wide: benchmarks measure QA over synthetic dialogue history; production memory quality is dominated by write-path judgment (what to store, update, forget), latency budgets, cache behavior, per-user isolation, and robustness to memory poisoning — none of which public benchmarks score. Memory has no pass^k-style reliability metric yet (see agent-loops-planning-sota.md §7 for that metric class).


7. What to add to the knowledge base

  1. New concept page memory-systems.html ("The Memory-Systems Landscape"): the §3 table, the core-vs-archival convergence diagram, and a LoCoMo-dispute box as a worked example of reading vendor benchmarks critically.
  2. Fold into content/foundations/memory.md at its next review (page is status: reviewed; not edited now): (a) a MemGPT/CoALA lineage note under long-term memory — its LangMem taxonomy descends from CoALA; (b) a "files as memory" paragraph under context engineering, citing Claude Code's CLAUDE.md/auto-memory and the memory tool; (c) a sentence tying hot-path/background formation to sleep-time compute.
  3. New glossary terms: memory-block, temporal-knowledge-graph, bi-temporal-model, sleep-time-compute, prefix-caching, progressive-disclosure, memory-consolidation.
  4. Extend the evaluation story: add LongMemEval (five abilities, 30% drop), LoCoMo + its criticisms, and MemBench to whatever evals page emerges from the companion briefs' proposals, distinguishing retrieval-quality from memory-quality metrics.
  5. Cross-link storage: memory.md's vector-store section should point to retrieval-rag-sota.md §3–4 for index/DB internals and this brief's §4 for the memory-specific deltas (mutability, bi-temporality, namespacing, files).
  6. Open question worth a deep-dive — memory security: memories are attacker-influenced prompt input (ChatGPT's opaque profile injection [chatgpt-memory-analysis]; the memory tool's path-traversal warnings [anthropic-memory-tool-docs]); no page covers poisoning or isolation yet.
  7. Open questions to track before page promotion: whether RL-managed memory (Memory-R1/MemAgent/Memp) beats engineered pipelines outside its training distributions, and whether any forgetting/decay policy (§2.3) acquires benchmark-backed support.

Sources (references.yaml format; URLs verified 2026-07-09, arigraph-* entries 2026-07-13)

memgpt-paper: {title: "MemGPT: Towards LLMs as Operating Systems (Oct 2023)", url: "https://arxiv.org/abs/2310.08560", accessed: "2026-07-09"}
coala-paper: {title: "Cognitive Architectures for Language Agents (CoALA, TMLR 2024)", url: "https://arxiv.org/abs/2309.02427", accessed: "2026-07-09"}
generative-agents-paper: {title: "Generative Agents: Interactive Simulacra of Human Behavior (Park et al., Apr 2023)", url: "https://arxiv.org/abs/2304.03442", accessed: "2026-07-09"}
sleep-time-compute-paper: {title: "Sleep-time Compute: Beyond Inference Scaling at Test-time (Letta/UC Berkeley, Apr 2025)", url: "https://arxiv.org/abs/2504.13171", accessed: "2026-07-09"}
letta-sleep-time-blog: {title: "Sleep-time Compute — Letta Blog (Apr 2025)", url: "https://www.letta.com/blog/sleep-time-compute", accessed: "2026-07-09"}
letta-memory-blocks: {title: "Memory Blocks — Letta Documentation", url: "https://docs.letta.com/guides/agents/memory-blocks", accessed: "2026-07-09"}
letta-github: {title: "Letta (formerly MemGPT) — GitHub Repository", url: "https://github.com/letta-ai/letta", accessed: "2026-07-09"}
mem0-paper: {title: "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (Apr 2025)", url: "https://arxiv.org/abs/2504.19413", accessed: "2026-07-09"}
mem0-github: {title: "Mem0 — Universal Memory Layer for AI Agents (GitHub)", url: "https://github.com/mem0ai/mem0", accessed: "2026-07-09"}
zep-paper: {title: "Zep: A Temporal Knowledge Graph Architecture for Agent Memory (Jan 2025)", url: "https://arxiv.org/abs/2501.13956", accessed: "2026-07-09"}
zep-mem0-response: {title: "Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory? — Zep Blog (May 2025, corrected)", url: "https://blog.getzep.com/lies-damn-lies-statistics-is-mem0-really-sota-in-agent-memory/", accessed: "2026-07-09"}
graphiti-github: {title: "Graphiti: Temporally-Aware Knowledge Graphs for Agent Memory — getzep (GitHub)", url: "https://github.com/getzep/graphiti", accessed: "2026-07-09"}
langmem-concepts: {title: "Long-term Memory in LLM Applications — LangMem Conceptual Guide", url: "https://langchain-ai.github.io/langmem/concepts/conceptual_guide/", accessed: "2026-07-09"}
langmem-github: {title: "LangMem — LangChain AI (GitHub, MIT)", url: "https://github.com/langchain-ai/langmem", accessed: "2026-07-09"}
langgraph-persistence: {title: "Persistence (Checkpointers and Stores) — LangGraph Documentation", url: "https://docs.langchain.com/oss/python/langgraph/persistence", accessed: "2026-07-09"}
llamaindex-memory: {title: "Memory — LlamaIndex Framework Documentation", url: "https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/memory/", accessed: "2026-07-09"}
chatgpt-memory-analysis: {title: "How ChatGPT Remembers You: A Deep Dive into Its Memory and Chat History Features — Johann Rehberger, Embrace The Red (May 2025)", url: "https://embracethered.com/blog/posts/2025/chatgpt-how-does-chat-history-memory-preferences-work/", accessed: "2026-07-09"}
chatgpt-memory-april-2025: {title: "ChatGPT Can Now Reference All Past Conversations (Apr 10, 2025) — OpenAI Developer Community", url: "https://community.openai.com/t/chatgpt-can-now-reference-all-past-conversations-april-10-2025/1229453", accessed: "2026-07-09"}
anthropic-memory-tool-docs: {title: "Memory Tool (memory_20250818) — Claude Platform Documentation", url: "https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool", accessed: "2026-07-09"}
anthropic-context-management-news: {title: "Managing Context on the Claude Developer Platform (Sep 29, 2025)", url: "https://claude.com/blog/context-management", accessed: "2026-07-09"}
claude-code-memory-docs: {title: "How Claude Remembers Your Project (CLAUDE.md and Auto Memory) — Claude Code Documentation", url: "https://code.claude.com/docs/en/memory", accessed: "2026-07-09"}
anthropic-context-engineering: {title: "Effective Context Engineering for AI Agents — Anthropic Engineering (Sep 2025)", url: "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents", accessed: "2026-07-09"}
context-rot-chroma: {title: "Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research (Jul 2025)", url: "https://www.trychroma.com/research/context-rot", accessed: "2026-07-09"}
manus-context-engineering: {title: "Context Engineering for AI Agents: Lessons from Building Manus (Jul 2025)", url: "https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus", accessed: "2026-07-09"}
memory-r1-paper: {title: "Memory-R1: Enhancing LLM Agents to Manage and Utilize Memories via Reinforcement Learning (Aug 2025)", url: "https://arxiv.org/abs/2508.19828", accessed: "2026-07-09"}
memagent-paper: {title: "MemAgent: Reshaping Long-Context LLM with Multi-Conv RL-based Memory Agent (Jul 2025)", url: "https://arxiv.org/abs/2507.02259", accessed: "2026-07-09"}
memp-paper: {title: "Memp: Exploring Agent Procedural Memory (Aug 2025, ACL 2026 Findings)", url: "https://arxiv.org/abs/2508.06433", accessed: "2026-07-09"}
arigraph-paper: {title: "AriGraph: Learning Knowledge Graph World Models with Episodic Memory for LLM Agents (Anokhin et al., Jul 2024)", url: "https://arxiv.org/abs/2407.04363", accessed: "2026-07-13"}
arigraph-ijcai: {title: "AriGraph — IJCAI-25 Proceedings, Main Track, pp. 12–20", url: "https://www.ijcai.org/proceedings/2025/2", accessed: "2026-07-13"}
arigraph-github: {title: "AriGraph — AIRI Institute (GitHub, MIT)", url: "https://github.com/AIRI-Institute/AriGraph", accessed: "2026-07-13"}
longmemeval-paper: {title: "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory (ICLR 2025)", url: "https://arxiv.org/abs/2410.10813", accessed: "2026-07-09"}
locomo-paper: {title: "Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo, Feb 2024)", url: "https://arxiv.org/abs/2402.17753", accessed: "2026-07-09"}
membench-paper: {title: "MemBench: Towards More Comprehensive Evaluation on the Memory of LLM-based Agents (ACL 2025 Findings)", url: "https://arxiv.org/abs/2506.21605", accessed: "2026-07-09"}