What should an AI agent carry from one session into the next: a transcript, a short list of lessons, or a searchable map of what it has learned? Anthropic explored that design question in a November 6, 2026 engineering research post. Its central idea is to keep different kinds of memory in layers and use work between sessions to organize and correct them. The post offers detailed evaluations, but they are Anthropic's own experiments on selected tasks, not an independent comparison of agent-memory products.
What does Anthropic mean by agent memory?
Anthropic defines agent memory as knowledge retained from earlier tasks or user interactions and saved in a form the agent can read later. It distinguishes that from model training, knowledge picked up inside one conversation, and conversation compaction. The distinction matters: the research concerns an external store that persists across sessions, not a model that permanently changes its weights after each task.
The post describes a hierarchy. At the bottom are session transcripts, which preserve what happened. An agent can write salient observations as memory notes. A later organization pass can use those notes and transcripts to build linked representations such as a wiki. A small set of high-value context can then be placed where the next session sees it immediately; detailed material stays available for search. Anthropic calls the between-session organization step “dreaming.” The term is its label for a process that reads prior work and updates stored memory, not a claim that the model sleeps or thinks continuously.
That separation addresses a practical tension. Writing every possible detail during a task distracts from the task and creates an unwieldy store. Saving too little loses useful lessons. A background pass can use later evidence to refine notes, join related facts and remove stale or duplicate material. Anthropic's open cookbook shows one way to build such a pass for Managed Agents: analyze transcripts into small linked files, organize them, and mount the resulting store read-only in later sessions.
What did the memory evaluations measure?
Anthropic reports results from several task setups rather than one general test of memory. In a Continual Learning Bench database task, models began each question in a fresh session but could access a directory that persisted between questions. The reward figures in the post are benchmark scores, not percentages of users or production tasks solved. For example, Opus 5.5's mean reward rose from 0.655 without the memory store to 0.838 with it; Sonnet 5.5 rose from 0.644 to 0.833. These results support the narrower claim that memory helped on that repeated database-question task under Anthropic's setup.
The post also describes an internal document corpus with roughly 350,000 files and 420 million tokens. Anthropic built an evaluation of 25 questions over the corpus and used repeated sessions to grow a linked wiki. On those questions, the share of graded criteria met rose from 13% after two dreaming sessions to 48% after 128. When the agent also had search, the aggregate score rose from 54% to 61% as the wiki developed, compared with 53% for search alone. The result suggests that a maintained map can help when answers require connecting documents; it does not show that a wiki beats search on every task.
Anthropic reports a similar task-dependent pattern in a simulated merger-document exercise: on 24 questions that often required combining several documents, its agent scored 87% with a wiki and 73% with search alone. But the post also says a separate legal-brief task showed no clear wiki advantage when most criteria could be found in a single document. In one contract-term setup, changing the instructions so each agent handled a separate contract page raised the number of captured graded facts from 41 of 57 to 57 of 57. That is a useful reminder that memory quality depends on how the information is split and checked, not just on whether a system stores more text.
Why can more memory make an agent worse?
The Pokémon example in Anthropic's post illustrates the maintenance problem. In one run, Sonnet 3.7 wrote 413 files across 225 folders and earned one badge after about 10,000 game steps. In a separate run, Fable 5 wrote nine topic files plus a top-level index and earned four badges. These are individual examples in a vendor-authored study, not a controlled product benchmark. Anthropic's explanation is that an oversized record of changing game state became costly to search and went stale, while a smaller set of strategies and tested rules was more useful.
Stored facts can also be wrong. Anthropic describes an agent that misremembered which side of a cave held a landmark and repeated a route mistake. In a later pass, the system compared the note with the original session transcript, corrected it and completed the route in that run. This illustrates the value of retaining a way back to evidence: a memory note should not automatically become truth merely because it was saved earlier.
The costs are real. A post-session organization pass uses additional model calls and compute. An indexed memory can grow larger than the material it summarizes, and a mistaken note promoted into every new session can repeatedly mislead the agent. Anthropic explicitly identifies when to write memories, how to keep them current and how often to reorganize them as open design questions. Its documentation for Claude Code offers one concrete product implementation: the first 200 lines or 25 KB of `MEMORY.md` are loaded at startup, while topic files are read when needed. That implementation detail should not be assumed to describe every system in the research post.
What should builders take from the results?
For makers building agents, the practical lesson is to match memory to the shape of the work. Keep the immediately loaded context short. Store durable decisions and tested procedures separately from facts that change every run. Preserve source transcripts or other evidence so a later process can challenge a note. Use a linked index when a task repeatedly combines information across documents, and compare it with ordinary search when answers usually sit in one file. Then test memory and no-memory versions on the same tasks, including stale facts and correction cases.
Anthropic's post is a useful design study, not proof that a particular memory architecture improves every agent or that its results transfer unchanged to unrelated models, datasets or applications. Developers should measure retrieval accuracy, stale-memory errors, task quality, latency and total cost in their own workflow. The durable asset is not a large memory folder; it is a small, inspectable body of context that helps the next session do better without hiding where its claims came from.
How to protect your app when using an AI coding agent
As more makers use agents to build software, they also need to decide which work belongs in persistent notes and which changes need review before reaching an app. VIBPS gives makers a place to publish their software and help people follow what they are building.