← logs/

Agent memory 2026: the taxonomy year

For years, "agent memory" meant a vector store plus a retriever, or a summarizer for long transcripts. By late 2025 and into 2026 the field grew a vocabulary. A survey named the parts, a benchmark said what to test, and a wave of systems started treating memory management as a learnable policy rather than a storage detail. This is my map of that year.

Field map: forms, functions, dynamics

Memory in the Age of AI Agents: A Survey (Hu, Liu, et al., December 2025) does the taxonomy work, and it has the right shape for builders:

forms      token-level | parametric | latent
functions  factual     | experiential | working
dynamics   formation   | evolution | retrieval

Token-level memory lives in the context: history, retrieved documents. Parametric memory lives in weights: the model actually changed. Latent memory lives in hidden representations. Functions split what memory stores: facts, episodes, and the task-local scratchpad. Dynamics is how memory is formed, evolves, and is retrieved over time.

The survey also draws the boundary lines: agent memory is not RAG, not context engineering, not the pretraining corpus. That boundary is the same weights-versus-context question I wrote about from the models side, and it keeps showing up in every memory design meeting.

Close read: MemoryAgentBench

MemoryAgentBench (Hu, Wang, McAuley; ICLR 2026) is the eval answer to the taxonomy. It identifies four competencies a memory agent needs:

  1. Accurate retrieval: the right information comes back.
  2. Test-time learning: new information from the conversation changes behavior.
  3. Long-range understanding: earlier turns still matter later.
  4. Selective forgetting: stale or contradicted information stops mattering.

The design move: existing long-context datasets get converted into incremental, multi-turn interactions. Memory is behavior over time, so you test it over many turns with information arriving bit by bit, not as a book dump. The empirical finding is sobering: current memory agents do not master all four competencies.

Selective forgetting is the one nobody wants to build. Conflict resolution means the agent learned something, the world changed, and the old belief must be superseded. It is also the hardest to evaluate: what is the ground truth for "should have forgotten X?" A benchmark that includes it is making the right bet.

I have measured the mechanism behind two of these competencies first-hand. In my first-author editing preprint (under review; venue deliberately unnamed), we found that an edit trained on one phrasing often fails to produce the stored passage under another, even when retrieval finds the right edit every time. That is test-time learning failing at the smallest possible scale: the new information arrived, and behavior still did not change under a new query shape. Selective forgetting is the same rigidity with the sign flipped: a write that cannot generalize past its training phrasing is also a write you cannot reliably weaken when the world moves on.

Close read: Mem0

Mem0 (Chhikara et al., 2025) is the production-shaped answer: an extract, consolidate, retrieve pipeline plus a graph variant that captures relations between conversational elements. Evaluated on the LoCoMo long-conversation benchmark — vendor self-reported numbers from the Mem0 team — it reported a 26% relative improvement in the LLM-as-judge metric over the OpenAI baseline, 91% lower p95 latency, and more than 90% token cost savings versus processing full context.

Two takeaways. The pipeline shape, extract-consolidate-retrieve, is now the default architecture for product memory. And the cost story is the adoption story: full context is the lazy baseline, and memory systems beat it on cost by a wide margin while matching or exceeding quality.

One honest caveat: the headline metric here is an LLM judge. That is normal for memory evals in 2026, and it is the weakest link. Judge drift is exactly what MemoryAgentBench's design sidesteps: rather than asking one judge whether memory works globally, it transforms existing long-context datasets into incremental, multi-turn QA and scores the four competencies separately — answer accuracy over many turns, not a single impression.

Memory management as a policy

Two papers converge on the same move: memory management is a decision problem, so train the decision end to end.

MemSearcher (Yuan et al., 2025) makes the backbone LLM its own memory manager. Multi-context GRPO propagates trajectory-level advantages across turns, and the agent keeps a compact memory so the context stays nearly constant in token count instead of growing linearly.

Memory-as-Action (Zhang et al., 2025) frames working memory edits as policy actions: delete, insert. Dynamic Context Policy Optimization makes the joint optimization tractable, and the 14B model matches the accuracy of models 16× larger while cutting average context length by 51%.

The direction is clear: memory is an action space, not a storage layer. Once "what to keep" is a policy, the evaluation problem shifts from retrieval quality to decision quality, and the taxonomy's dynamics axis becomes the product spec.

An eval-driven memory stack

An eval-driven memory stack. MemoryAgentBench's four competencies as regression gates. The survey's forms, functions, and dynamics as the design vocabulary, so every component says which form it writes and which function it serves. And a write-side attribution requirement: every memory write must be able to explain itself, because memory that cannot be audited is a liability.

Notes from my own work

Two pieces of mine sit on opposite sides of the forms axis.

Engram is a continuous-learning memory system built around belief-to-weights routing. Facts, documents, and schedule-like records stay in a reversible RAG store. Durable beliefs and preferences are consolidated into model-weight edits through a HoReN editing backend. The attribution demo is the point, and it runs as a fixed six-step protocol: teach a belief, consolidate it into weights, ask the probe with retrieval off, show retrieved == [] while the answer still contains the belief, toggle the edit module off and watch the belief disappear, toggle it back on and watch it return. That is parametric memory with a proof attached. The toggle earned its own hardening from a real UI bug: with an empty codebook (k=0, nothing written yet) the switch is now disabled, because every ON click otherwise 409'd with "no edit module to enable". Details are in the build note.

Map it onto the survey: the RAG store is token-level memory, the weight edits are parametric memory, and the router is the dynamics layer, deciding what gets formed where. It is the strongest concrete example I know of the weights-versus-context tradeoff made literal.

Second, my Hopfield memory-reranker design notes. The idea, at design-notes level: treat retrieval as an associative, energy-based process. A Hopfield-style energy function over the candidate memories reranks the raw retrieval list, so the final selection is the lowest-energy configuration rather than the top cosine-similarity hit. In design terms it is a third option between brute-force vector top-k and learned rerankers, and it sits on the survey's latent-memory thread: the associative structure lives in the interactions between candidates, not inside the candidates alone. It is a design exploration; I claim no results for it.

The open bet I would watch: whether selective forgetting ever gets a non-synthetic ground truth — a corpus of beliefs that genuinely went stale, rather than contradictions planted by construction. Whoever builds that changes what memory systems have to prove. For the harness context, this sits under the agent taxonomy overview.

Sources linked in this post were fetched and verified.