ResearchAnalysis
Anthropic: the components of agent memory
On November 6, 2026 Anthropic published how it now thinks about agent memory: notes that persist across sessions, offline dreaming, wiki-style representations, and a small injected layer loaded at the start of every session. Memory can raise scores, but a bad note or several agents writing to one file can wipe out the gain.
· 7 min read

What counts as agent memory
Anthropic published the research on November 6, 2026. By agent memory it means knowledge Claude gains from experience, including interactions with users and assigned tasks, and then keeps between sessions as context it can read later.
That definition excludes changes to the model's weights, in-context learning inside a single conversation, and compaction, where Claude replaces older turns with a summary so it can keep working in a new context window.
During a live session the model can write notes to a memory store, such as a folder. In idle time it can go back over the logs to correct mistakes, write new notes, or build new representations. Anthropic calls this process dreaming, and points to sleep-time compute work from Letta and UC Berkeley.
Memory is a prediction about the future
Writing down a rule predicts that the pattern will matter again. Writing down a verified fact predicts that a later session will want to rely on it without checking it twice.
They studied that loop on a Continual Learning Bench (CL-Bench) 1.0 database task. Claude started each question in a fresh session, with one exception: it could read a memory directory that persisted from question to question. After each answer it was told the correct solution and could write a memory to help with later questions.
Models closed that learning loop at different levels. Claude Sonnet 4.6 generated theories about its mistakes, but its folder held a scatter of files and untested guesses. Opus 4.7 consolidated notes into a single reference document and marked what it had checked. Sonnet 5 marked answers as confirmed after the grader checked them, and wrote a correction when it had been wrong.
Opus 5 was the first of these models to close the loop. Most of its entries included a rule, how it knew the rule was true, earlier answers, and warnings about traps it had found. Opus 5.5 and Sonnet 5.5 also closed the loop. With memory they scored about the same as Opus 5, even though their baseline without memory was slightly higher.
What is worth remembering? The Pokémon test
They also used Pokémon Red to test Claude's judgment about what to save. Around 10,000 steps in, Sonnet 3.7 had written 413 memory files across 225 folders and earned one badge. It treated almost everything as worth saving, but the game state kept changing, so the archive went stale. At one point it spent 17 steps creating six files and deleting nine others, and took no actions in the game itself.
Claude Fable 5, at the same stage, kept nine files in two folders plus a top-level global.md, and earned four badges. It wrote down things the game does not state outright: strategy, plans, and rules it had tested. It did not store facts it could read off the screen every turn, such as money or map position. Opus 5.5 took a similarly small folder and beat the game.
Steering: say what memory is for, not how to use it
With frontier Claude models, Anthropic found it works better to say what memory is for and leave the method to the model. On CL-Bench, simply telling Claude that a memory folder was available was enough for Opus 4.7 and Opus 5 to get a clear boost.
When the team added a rule to "record only failures," both Opus 5 and Opus 4.7 lost much of the gain memory had given them. For stronger models, freedom to judge salience beat fixed rules set in advance.
Older models benefited more from tighter steering. Sonnet 4.6 often did not read its memory files and failed to test its theories. Prompting it to read memory before answering, and then to test those theories explicitly, nearly doubled its score. Sonnet 5 already did this on its own: it read memory before answering 9 times out of 10, compared with less than half the time for Sonnet 4.6.
Dreaming can correct, build, and promote
Because notes are written from in-the-moment salience, a note that is wrong from the start, or that drifts as the environment changes, can be trusted by a later session. Dreaming lets Claude check notes against the original transcripts.
In a Pokémon example set in Mt. Moon, Claude incorrectly wrote that the PokéCenter was on the east side of the mountain, declared the cave done, and walked off a one-way ledge back onto the route it came from. Dreaming checked the note against the transcript and rewrote it. With the corrected memory, Claude went back into the cave and reached Cerulean City. With the uncorrected note it dropped back three times, would have stopped, and never made it past the mountain. A run with no memory did not get past the mountain either.
Dreaming can also build wiki-style pages, with links, so Claude can find what it knows later. On an internal Stainless corpus of about 350,000 files (roughly 420 million tokens), wiki-only performance on 25 questions rose from 13% to 48% across 128 dreaming sessions. Combined with search, the aggregate score rose from 54% to 61% as the wiki grew, compared with 53% for search alone. That combination also saved about 20,000 tokens per question.
Wikis do not help every task. On 24 questions about a merger, items that needed several documents plus judgment or math scored 87% with the wiki and 73% with search alone. On a Harvey LAB task where most graded criteria could be retrieved from a single document with text search, the wiki showed no clear gain. On another task the wiki grew larger than the source documents themselves.
Dreaming can also promote notes to the top of the hierarchy, where the harness injects them into every new session. That saves a search, but it costs tokens, and a wrong note then rides into every session. Longer instruction files also reduce adherence. Claude Code's auto memory therefore loads only the first 200 lines or 25 KB of MEMORY.md, as an index.
Several agents, one file: facts go missing
On a contracts task from the LAB benchmark, several agents wrote at once to a shared table. Only 41 of 57 graded contract facts survived, or 72%. After dreaming rewrote the instructions, each contract got its own page from a single agent, quoting terms word for word. All 57 facts survived.
A second dreaming pass found nine links to a missing page and pointed them at an existing one. It also added three new pages, including an index.
We previously looked at whether agents learn from their own past at all, through Letta's FrontierMemory benchmark: FrontierMemory: can agents learn from their own past?. Anthropic's write-up adds a design guide: what belongs in which layer, and what to avoid.
What to take into your own harness
- Keep the injected top layer small. Push detail down, and leave links behind.
- For stronger models, explain the purpose of memory rather than the procedure.
- Do not let several agents write to one file if the facts need to survive.
- Dreaming is most useful when it can check notes against the original transcripts.
Produced with the help of AI, reviewed by an editor. How we make our articles
Reviewed and edited by the Neural Daily desk. About


