Agent Memory: remembering without blowing the budget

Persistent state for long-horizon agents.

LinkTec Labs · Research Note N°02 · Applied AI & Data · Edition 2026

Abstract

A bigger context window solves capacity within a session; it does nothing for continuity across them. Yet the agents now reaching production run for hundreds of steps and return day after day, and the naive answer (keep everything in the window) is both ruinously expensive and quietly inaccurate. This note treats memory as a first-class engineering discipline: a typed system of working, episodic, semantic and procedural stores, with an explicit lifecycle (encode, consolidate, retrieve, forget) governed by policy rather than left to grow. We survey the architectures that define the state of the art (OS-style memory hierarchies, extraction-based external stores, file-based memory with context editing, and temporal knowledge graphs), the learned write policies now emerging from reinforcement learning, the cost mechanics that make memory cheaper than context, and the benchmarks that keep the claims honest. We then turn to what decides deployability: failure modes. Unbounded growth, stale facts, memory poisoning, and privacy are where memory becomes a liability, and where most systems are still untested. We close with the governed, sovereignty-ready memory architecture LinkTec Labs builds, and five working hypotheses that define our research agenda.

01 · Capacity is not continuity: why memory, not just a bigger window

The most common mistake in agent design is to treat memory as a context-length problem. It is not. A long context window solves capacity: how much an agent can read at once. Memory solves continuity: what an agent carries from one step, one session, one week to the next. The two are orthogonal, and conflating them produces agents that are simultaneously expensive and forgetful.

The symptom is familiar to anyone who has shipped one. An agent performs beautifully for the first dozen turns, then degrades: by the fortieth step the window is choked with tool transcripts and earlier decisions, and the model loses the thread [8]. The reflex (enlarge the window and pour everything back in) fails twice over. It is expensive, because attention cost grows super-linearly with sequence length, so every retained token is paid on every subsequent turn. And it is inaccurate, because, as we argued in Research Note N°01, models do not use long contexts uniformly, so a fuller window is often a less reliable one. Continuity bought by brute capacity is continuity that erodes exactly when it is needed most.

Memory is the alternative: a deliberate system that decides what to keep, in what form, where to put it, and when to let it go, so that the working window stays small and sharp while the agent's knowledge of its task, its user and its history persists outside it. The framing that has stabilised across the field is exactly this: long context addresses capacity; memory addresses continuity [6].

Key terms

A shared vocabulary for the rest of this note. Specialists may skip ahead.

02 · A working taxonomy: four memories, one agent

Useful memory systems are not monolithic. The canonical academic frame, CoALA, adapts cognitive science for language agents and distinguishes working memory from three long-term stores: episodic, semantic and procedural [2]. The distinction is not pedantic. Each store has a different write policy, retrieval pattern, and decay rate, and conflating them is a primary cause of bloated, unreliable memory.

Episodic memory is the agent's log: "on Tuesday the user rejected vendor A on price." Semantic memory is what that log distils into: "the user is price-sensitive on infrastructure." Procedural memory is the skill that crystallises from repetition: "to reconcile invoices, call tool X then Y." The clearest demonstration of the third category remains Voyager, whose agent stores every verified routine as executable code indexed by a natural-language description, then composes those skills to solve new tasks it has never seen, improving continuously without a single gradient update [13]. The arc of a maturing agent is the steady promotion of episodes into semantics and procedures: experience becoming expertise [3][13].

03 · The memory lifecycle: encode, consolidate, retrieve, forget

Memory is a loop, not a database. Four operations define it, and each is a design decision with cost and quality consequences.

Encode (write). After each interaction the agent must decide what, if anything, is worth keeping, and extract it as a structured entry rather than a raw transcript. This write path is itself an inference cost, and recent systems attack it directly: Mem0's single-pass extraction reduces write-time model calls by 60-70% with negligible quality loss against its own multi-call baseline [10]. The write decision itself is also becoming learned rather than hand-crafted. Memory-R1 trains a memory manager with reinforcement learning to choose among ADD, UPDATE, DELETE and NOOP from outcome rewards alone [15]; Mem-α extends the idea to richer memory structures and reports policies trained on 30k-token interactions that generalise to sequences over 400k tokens, thirteen times the training horizon [16]. Hand-written write heuristics are, on current evidence, a transitional technology.

Consolidate. Periodically, raw episodes are synthesised into durable insight: the "reflection" mechanism popularised by Generative Agents, which turns a stream of events into higher-level semantic memory [3].

Retrieve (read). At decision time, a small set of relevant memories is selected and injected, scored by recency, importance and relevance, keeping the working window lean [3].

Forget. The least-developed and most-needed operation. Without decay, stores grow without bound and retrieval quality collapses under the accumulated weight [11]. Concrete mechanisms exist and are underused: MemoryBank modulates retention with an Ebbinghaus-style forgetting curve, reinforcing memories that are recalled and letting untouched ones fade [14]; simpler regimes assign each store a time-to-live and an importance floor. What matters is that forgetting is a policy with parameters, not an accident of database growth.

04 · Architecture patterns: four ways to hold state

Four architectures dominate production, and they are complementary rather than competing.

The OS-style hierarchy (self-editing memory)

MemGPT, now the Letta framework, frames the LLM as a process on a memory-constrained operating system, with a tiered hierarchy: core memory in the window (RAM), recall memory for searchable history (a disk cache), and archival memory for cold storage [1]. Crucially, the agent edits its own memory through tool calls during its normal loop: when the user says "call me Alice," the model itself writes that to its core block. Memory becomes an action, not a side-effect.

The extraction-based external store

Mem0 takes the opposite tack: a dedicated memory layer that extracts salient facts from each exchange, consolidates them into a structured store, and retrieves a compact set on demand, keeping per-call context far below a full-history approach [6]. This is the pattern when memory must scale across many users and sessions with predictable cost.

File-based memory and context editing

The newest production primitive treats memory as a filesystem the model can read and write outside the window. Anthropic's memory tool persists information across conversations via files in the developer's own infrastructure, while context editing automatically clears stale tool results as the window fills; together they complete long workflows that would otherwise exhaust context [7].

The temporal knowledge graph

Flat fact stores struggle with the question every longitudinal deployment eventually faces: not "what do we know" but "what was true, when." Zep's Graphiti engine represents memory as a temporally-aware knowledge graph in which every edge carries validity intervals, so "the customer's plan is Enterprise" can be superseded without being erased. Against strong baselines it reports up to 18.5 points of accuracy improvement on LongMemEval's temporal-reasoning-heavy tasks alongside a 90% latency reduction, and it slightly outperforms MemGPT on the DMR recall benchmark (94.8% vs 93.4%) [12]. When an agent must reason over how facts evolved (contracts, org charts, account state), graph-structured memory is currently the strongest answer.

05 · The cost equation: remembering without blowing the budget

The promise of memory is not only accuracy; it is doing better and cheaper than stuffing history into context. The numbers are now decisive. Against a full-context baseline, Mem0 reports 91% lower p95 latency and over 90% token-cost savings, while improving answer quality by 26% (LLM-as-judge) over a leading commercial memory [6]. Across the major long-memory benchmarks, structured memory averages under roughly 7,000 tokens per retrieval where full-context approaches consume 25,000 or more, a 70-85% reduction in active context (vendor-reported synthesis; treat as indicative) [10].

The deeper lever is when the work happens. Memory operations (extraction, consolidation, re-indexing) do not have to sit on the user's critical path. Sleep-time compute moves them to idle periods: the agent "thinks" offline, turning raw context into learned context, cutting the test-time compute needed for equal accuracy by roughly 5× and, amortised across related queries, the average cost per query by about 2.5× [9]. Memory, done well, is not a tax on every turn; it is an investment made when the meter is cheapest.

06 · Measuring memory: benchmarks and the abilities that matter

Memory claims are cheap; measured memory is not. Three benchmarks anchor the field. LoCoMo evaluates very long-term conversational memory over dialogues averaging around 300 turns across up to 35 sessions [4]. LongMemEval isolates five distinct abilities (information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention) and finds commercial assistants and long-context models suffering roughly a 30% accuracy drop on sustained interaction [5]. BEAM pushes to the extreme, probing memory over conversations of up to ten million tokens and pairing the benchmark with a cognitive-science-inspired memory framework [17].

One measurement gap deserves naming: almost all public benchmarks test declarative memory (facts and events). Procedural memory, the store that compounds into genuine capability, is barely measured at all, and early probes suggest agents struggle to recognise a known procedure when it reappears in new vocabulary. Buyers should ask vendors which of the four stores a reported score actually exercises.

The two abilities people underestimate. Knowledge updates (overwriting a fact when it changes: "she switched jobs") and abstention (knowing when the answer was never stored). Pure-recall systems quietly fail both: they surface stale facts and confabulate rather than admit ignorance. These, not raw recall, separate a toy from a trustworthy agent [5].

07 · Failure modes and governance: where memory becomes a liability

Memory introduces failure modes that retrieval alone never had, and they are precisely the ones a serious buyer asks about.

Unbounded growth. Reflection improves coherence but does not regulate the size of the store; without an explicit decay policy, traces accumulate until retrieval degrades [11].

Stale and conflicting memory. An old fact that should have been overwritten resurfaces as a confident error. This is the knowledge-update failure LongMemEval measures, and it is the everyday form of memory rot [5].

Memory poisoning. The adversarial form is worse than the accidental one, and it is no longer hypothetical. MINJA demonstrated that an attacker interacting with an agent through perfectly ordinary queries (no privileged access, no compromised infrastructure) can plant records in its memory that later trigger attacker-chosen behaviour when an innocent user's query happens to match them, with injection success rates above 95% in the evaluated settings [18]. A poisoned retrieval corrupts one answer; a poisoned memory corrupts every future session that recalls it, across users if the store is shared. The defences are architectural and mirror Research Note N°01: the write path is a security boundary, so writes carry provenance, low-trust writes are quarantined until reviewed or corroborated, and memories that influence privileged actions require a higher trust tier than those that merely inform phrasing.

Privacy. A memory that remembers a customer remembers their personal data, indefinitely, across sessions. This is where memory stops being a performance feature and becomes a governance one. A persistent store of user information is regulated data; under the EU's GDPR it carries a right to rectification and erasure. An agent memory that cannot be inspected, corrected, and deleted on request is not production-ready in Europe; it is a liability. And there is a subtlety most designs miss: consolidation copies information. Deleting the source episode is not deletion if a derived semantic summary still carries the fact. Erasure must cascade through the consolidation lineage, which is only tractable if every derived memory records what it was derived from. Data minimisation belongs at the write path too: personal data that is never encoded never needs erasing.

An agent that cannot forget on request cannot be deployed on real customer data. Forgetting is not a feature gap; it is a compliance primitive.

08 · A reference architecture: governed memory, as LinkTec Labs builds it

The patterns above compose into a single governed layer. The design below is the one we deploy: typed by memory class, explicit at every operation, and auditable end to end.

Five principles govern it. Memory is typed: episodic, semantic and procedural stores have distinct write and decay policies; one undifferentiated blob is the road to bloat. Every operation is explicit: writing, retrieving and forgetting are governed by policy and instrumented, never emergent. The budget is the constraint: retrieval returns a small, ranked working set, and consolidation runs off the critical path. The write path is defended: every memory carries provenance and a trust tier, and low-trust writes are quarantined before they can influence behaviour. And everything is governed: each memory is source-attributed, editable and erasable, with lineage-aware deletion and a full audit trail. The first three buy performance; the last two are what make the system deployable on real customer data.

09 · Open problems: five working hypotheses

The field's hardest questions are still open, and several of the answers above are provisional. These five hypotheses define LinkTec Labs' research agenda for memory; each is falsifiable, and we intend to publish results either way.

H1. Write policies should be learned, not written. Early reinforcement-learning results (Memory-R1, Mem-α) suggest learned ADD/UPDATE/DELETE decisions outperform hand-crafted heuristics and generalise far beyond their training horizon [15][16]. We hypothesise this holds on messy enterprise interaction data, and that the gains concentrate exactly where trust is won: knowledge updates and abstention, not raw recall.

H2. Forgetting can be tuned like cache eviction. Decay today is either absent or a single global curve. We hypothesise that per-store half-lives (fast for episodes, slow for semantics, slower still for procedures), tuned against downstream task accuracy, dominate any single policy, with cognitive forgetting curves [14] as good priors rather than final answers.

H3. Erasure is a graph problem. If every consolidation records its sources, the memory store forms a lineage graph, and GDPR-grade deletion becomes a reachability query: erase the node and everything derived from it that lacks an independent source. We hypothesise this can be made a routine, auditable operation with negligible accuracy cost, and that architectures without lineage cannot retrofit it.

H4. Poisoning is detectable at the write path. Injected memories differ from organic ones in provenance and in usage pattern (they are written to be retrieved by others). We hypothesise that a quarantine-and-corroborate gate, requiring low-trust memories to be confirmed by independent interactions before gaining influence, collapses MINJA-style success rates [18] at a small cost in memory freshness.

H5. Organisational memory is the next layer. Today each agent remembers alone. The valuable and dangerous step is a shared semantic store across agents and teams: expertise compounds across the organisation, and so do errors and poisoned entries. We hypothesise that the governance model of section 08 (typed stores, provenance, lineage, quarantine) is the precondition that makes shared memory net-positive, and that without it shared memory amplifies failure faster than expertise.

10 · Practitioner's playbook: what to do on Monday

• Separate capacity from continuity. Don't solve a memory problem with a bigger window [6].
• Type your memory. Working, episodic, semantic, procedural: each with its own write and decay rules [2].
• Write structured, not raw. Extract salient facts; single-pass extraction cuts write cost 60-70% [10]. Watch the learned-policy results closely [15][16].
• Consolidate off-peak. Reflect and re-index during idle time; sleep-time compute pays for itself [3][9].
• Retrieve a small set. Rank by recency, importance and relevance; keep the window lean [3].
• Use time-aware memory for facts that change. If your domain asks "what was true when," flat stores will fail you; graph memory with validity intervals will not [12].
• Make forgetting a feature. Decay policy bounds growth; explicit, lineage-aware deletion satisfies the law [11][14].
• Defend the write path. Provenance, trust tiers, quarantine for low-trust writes; assume MINJA-class attacks [18].
• Test updates and abstention, not just recall. That is where trust is won or lost [5].
• Audit every memory. Source, edit, delete, cascade: or you cannot ship on customer data.

Capacity lets an agent read. Memory lets it learn. The discipline is keeping the second from eating the budget, or the trust.

LinkTec Labs designs governed, sovereignty-ready memory layers for agents that run long and return often: auditable, editable, and sized for real cost. Second in our 2026 research series; the first, Beyond RAG: Context Architecture, is its natural companion. linktec.fr / labs

References

1. Packer et al. MemGPT: Towards LLMs as Operating Systems. 2023. arXiv:2310.08560. https://arxiv.org/abs/2310.08560
2. Sumers, Yao, Narasimhan & Griffiths. Cognitive Architectures for Language Agents (CoALA). TMLR 2024. arXiv:2309.02427. https://arxiv.org/abs/2309.02427
3. Park et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. arXiv:2304.03442. https://arxiv.org/abs/2304.03442
4. Maharana et al. Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo). ACL 2024. arXiv:2402.17753. https://arxiv.org/abs/2402.17753
5. Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. ICLR 2025. arXiv:2410.10813. https://arxiv.org/abs/2410.10813
6. Chhikara et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. 2025. arXiv:2504.19413. https://arxiv.org/abs/2504.19413
7. Anthropic. Managing Context on the Claude Developer Platform (memory tool & context editing). 2025. https://www.anthropic.com/news/context-management
8. Anthropic. Effective Context Engineering for AI Agents. Anthropic Engineering, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
9. Lin et al. Sleep-time Compute: Beyond Inference Scaling at Test-time. 2025. arXiv:2504.13171. https://arxiv.org/abs/2504.13171
10. Mem0. AI Memory Benchmarks 2026: LoCoMo, LongMemEval & BEAM (cross-benchmark figures; vendor-reported, secondary). 2026. https://mem0.ai/blog/ai-memory-benchmarks-in-2026
11. Survey. Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers. 2026. arXiv:2603.07670. https://arxiv.org/abs/2603.07670
12. Rasmussen et al. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. 2025. arXiv:2501.13956. https://arxiv.org/abs/2501.13956
13. Wang et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. 2023. arXiv:2305.16291. https://arxiv.org/abs/2305.16291
14. Zhong et al. MemoryBank: Enhancing Large Language Models with Long-Term Memory. AAAI 2024. arXiv:2305.10250. https://arxiv.org/abs/2305.10250
15. Yan et al. Memory-R1: Enhancing LLM Agents to Manage and Utilize Memories via Reinforcement Learning. 2025. arXiv:2508.19828. https://arxiv.org/abs/2508.19828
16. Wang et al. Mem-α: Learning Memory Construction via Reinforcement Learning. 2025. arXiv:2509.25911. https://arxiv.org/abs/2509.25911
17. BEAM / Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs. 2025. arXiv:2510.27246. https://arxiv.org/abs/2510.27246
18. Dong et al. A Practical Memory Injection Attack against LLM Agents (MINJA). 2025. arXiv:2503.03704. https://arxiv.org/abs/2503.03704

© 2026 LinkTec, LinkTec Labs. Research Note N°02. Figures are original schematics by LinkTec Labs, after the cited studies. Quantitative results are attributed to their primary sources; industry and secondary syntheses are indicated as such in-text. This note is informational and does not constitute a benchmark claim by LinkTec.