Anthropic on Agent Memory: What "Dreaming" Does and the Numbers Behind It

Anthropic has published its working theory of agent memory, and the headline idea is dreaming: an offline pass in which Claude rereads its session transcripts to fix wrong notes, build linked wikis, and decide which facts get loaded into every future session. The post, The components of agent memory, is by Lance Martin. It is a design write-up with test results, not a product launch.

It matters to anyone building agents because the numbers are concrete. A wiki built over 128 sessions took one test from 13% to 48% of graded criteria. A single wrong note sent a Pokémon run into a loop until dreaming corrected it. And telling a strong model how to remember made it worse. We walk through each result below, then list what to copy.

TL;DR: the claims, the evidence, the caveats

What is "agent memory" in this post?

Anthropic defines it narrowly: knowledge Claude gains from experience, retained between sessions as context it can read later. It excludes weight updates, in-context learning inside one conversation, and compaction (summaries that replace older turns).

The post frames the problem with a line from Kierkegaard: life is understood backward but lived forward. An agent has to decide what is worth saving before it knows what will matter. Humans handle this partly by replaying experience during rest, which is thought to move some of it into long-term knowledge. Anthropic cites researchers at Letta and UC Berkeley who proposed sleep-time compute as a way for models to use idle time. Dreaming is the agent version.

Image: Anthropic

The diagram shows four layers. At the bottom are transcripts, a searchable event log. Above them sit memory notes written by Claude, then memory representations such as wikis, then injected context loaded into every session. Dreaming runs between all of them. If you have read our guides on what MEMORY.md is and the Karpathy LLM wiki pattern, you can map both onto this stack.

Memory as a prediction

Anthropic's first idea is that a memory note is a prediction. Writing down a rule predicts the pattern will come back. Writing a verified fact predicts a future session will want to trust it without checking.

The test is a task from Continual Learning Bench (CL-Bench) 1.0. Claude answers questions by looking up information in a database. After each answer it learns the correct solution and may write a memory. Each question starts in a fresh session, except that Claude can read a persistent memory directory. Anthropic ran it on Claude Managed Agents.

The models differed in how far they got:

• Sonnet 4.6 generated theories about wrong answers. Its folder held scattered files of untested guesses.
• Opus 4.7 consolidated notes into one reference document and began marking facts as checked or unconfirmed.
• Sonnet 5 marked answers as confirmed after grading and wrote corrections when wrong.
• Opus 5 was the first to close the loop. Entries carried a rule, how it knew the rule was true, earlier answers, and warnings about traps.
• Opus 5.5 and Sonnet 5.5 also closed the loop and scored about the same as Opus 5 with memory, though their no-memory baselines were slightly higher.

Image: Anthropic

The figure's alt text in Anthropic's page gives the mean rewards, stateless baseline then memory store: Opus 5.5 0.655 and 0.838, Sonnet 5.5 0.644 and 0.833, Opus 5 0.564 and 0.828, Opus 4.7 0.383 and 0.700, Sonnet 5 0.306 and 0.610, Sonnet 4.6 0.330 and 0.364. The pattern is clear. Newer models gain far more from the same folder, and Sonnet 4.6 barely moved. For how these models compare more broadly, see our Opus 5.5 FrontierCode coverage.

Salience: Pokémon and the 413-file problem

The second test asks whether Claude can judge what deserves saving. Anthropic gave each model a memory folder while playing Pokémon Red and compared one run each of Sonnet 3.7 and Fable 5, both about 10,000 steps in.

Image: Anthropic

Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge. It logged every battle, item and character. Because game state changes constantly, those records went stale. Around step 10,000 it started its fourth folder of "master" files and, over 17 steps, created six files, deleted nine, and took no game actions.

Fable 5 wrote nine files in two folders plus a top-level global.md, and earned four badges. It skipped what the screen already shows, such as money and map position, and stored only what it had worked out: strategy, plans, tested rules. Its global.md held the current goal, a gym plan, and its own memory rules. One saved rule, after seven failed Poké Balls on a Magikarp: vary the timing with extra wait presses. Opus 5.5 took a similar small-folder approach and beat the game.

The lesson: do not store what the environment already tells you. Store what you had to figure out.

Do not over-instruct the model

Anthropic reports that it helps to tell Claude what memory is for, not how to use it. On CL-Bench, simply saying a memory folder was available was enough for Opus 4.7 and Opus 5 to gain noticeably.

It then tried one rule per test. With "record only failures", both Opus 5 and Opus 4.7 lost much of their gain. The figure's alt text gives the change in gain: Opus 5 minus 0.234, Opus 4.7 minus 0.150, Sonnet 4.6 minus 0.020.

Older models were the exception. Sonnet 4.6 often did not read its files or test its theories. Prompting it to read memory first and to test theories nearly doubled its score, from 0.330 at baseline to 0.641 with memory plus refined instruction, per the same figure. Sonnet 5 read memory before answering 9 of 10 times unprompted. Sonnet 4.6 did so less than half the time.

Anthropic's current advice for frontier models: give simple guidance to write notes when a person asks or when something is clearly worth remembering, and leave the rest to Claude. This is a useful counterweight to long, rigid memory prompts. Our guide to Cognition's Devin dreaming and Agent Memory Repo shows a different design that leans more on structure.

Dreaming corrects mistakes: the Mt. Moon ledge

A note can be wrong from the start or drift as the environment changes, and a later session may trust it. Dreaming tests notes against the original transcripts.

The example: in Mt. Moon, a one-way ledge drops the player back onto the route they came from. Claude used the PokéCenter near the entrance as a landmark and wrote, wrongly, that it was on the east side. It announced "Mt Moon is behind me" and wrote "Mt Moon DONE". It then fell off the ledge, concluded "I overshot far west", and kept the wrong belief.

When Anthropic ran dreaming on that folder, Claude checked the note against the transcript, caught the error and rewrote it. With the corrected note it went back into the cave and reached Cerulean City. In the run with the uncorrected note, Claude dropped back onto the earlier route three times, wrote "I'm going to stop rather than keep looping", was told by the harness to continue, and walked all the way back to Pewter City. It never reached Cerulean. The no-memory run did not get past the mountain either.

The transcript works as ground truth. That is the practical core of dreaming: a cheap background check of notes against raw logs.

Dreaming builds wikis: 13% to 48% over 128 sessions

The third use is building memory representations. A wiki here is a set of pages written and maintained by Claude, each gathering what it knows about one subject and linking to others. The links give Claude a map.

Anthropic tested it on about 350,000 internal files, roughly 420M tokens, from Stainless, a software company Anthropic says it acquired in May. It built 25 questions and gave Claude a search tool. Opus 5 agents ran 128 dreaming sessions to explore files, write or correct linked pages, merge duplicates and check claims, coordinating through a shared log.

Using search and wiki also saved about 20,000 tokens per question, Anthropic says. In the figure's example, the wiki grew from 103 pages and 766 links after two sessions to 222 pages and 12,893 links after 128.

So a wiki alone did not beat search here. The combination did. If you run a retrieval system already, a wiki is an additional layer, not a replacement. Compare this with the UIUC memory-tax study, which found many memory systems lose to plain RAG, and with Databricks MemCurrent.

When the wiki did not help

Anthropic also used the Harvey LAB benchmark and a merger document set. On 24 merger questions, more than half needing several documents, Claude scored 87% with the wiki versus 73% with search alone on the items that needed cross-document judgment or math. On a LAB task where criteria sat in single documents, the wiki showed no clear gain. On another, the wiki grew larger than the source: Anthropic's figure shows a 10-document, 115 KB corpus turned into a 68-page, 203 KB wiki, 1.77 times the corpus. Anthropic compares this to Borges's map as large as the empire.

Instructions shape the wiki

In one acquisition task, several agents wrote to one shared table of contract terms and overwrote each other. Only 41 of 57 facts survived, or 72%. Anthropic then ran a loop in which Claude reflected on failures, proposed new instructions and rebuilt the wiki. The new instructions gave each contract its own page, written by one agent, quoting terms word for word. Then 57 of 57 facts survived, and the brief met 100% of criteria, up from 72%.

If you run parallel agents on shared state, this is the warning: one shared file is a conflict magnet. Give each writer its own page.

Promoting notes into every session

Dreaming can also move notes to the top layer, which the harness loads at the start of every session. Claude need not search for them or know they exist.

Anthropic is careful here. Injected memories cost tokens, and a wrong one is carried into every session. Loading a note does not guarantee action, and the Claude Code memory docs warn that longer instruction files reduce adherence. So the top layer must stay small, with detail pushed down and links left behind.

Claude Code's auto memory works this way. It loads only the first 200 lines or 25 KB of MEMORY.md, which acts as an index. This lines up with how we have described Claude Code memory and files.

Dreaming can also fill gaps across sessions. In one wiki, a second pass found nine links pointing to a page that did not exist and repointed them to the right one, and added three pages including an index. Because a session sees only its own context, only a cross-session pass can spot such patterns.

Open questions Anthropic lists

• When to write memory: in the moment, which costs attention, or in the background, which delays access.
• How to keep memory current: dreaming fixes errors but costs compute. Anthropic suggests focusing it on information likely to change, or tuning cadence by how often memories are read.
• Search versus representations: transcript search could be the base, and wikis need maintenance to avoid accumulating errors or hallucinations.

What to copy in your own agents

1. Say a memory folder exists. Skip rigid rules if you run a frontier model. Add explicit "read memory first, test your theories" prompts only for weaker models.
2. Store what the environment does not tell you. Plans, rules and verified facts, not state you can re-read.
3. Add a verification field. Notes that say how the rule was known, and whether it was confirmed, are what separated Opus 5 from earlier models.
4. Run a background correction pass against raw transcripts for notes that guide decisions.
5. Pair a wiki with search, not instead of it, and test whether the task needs cross-document answers first.
6. One writer per page when agents work in parallel.
7. Keep the injected layer small and use it as an index.

For teams building these systems, our overview of Claude Managed Agents and dreaming covers the product side, where dreaming first appeared.

Limits of this evidence

All results come from Anthropic's own post. Several are single runs, such as the Pokémon folders. The CL-Bench figures are read from chart text, and the wiki tests use Anthropic's internal Stainless corpus, which outside readers cannot inspect. We have not reproduced any of it. Treat the numbers as directional, and test on your own tasks.

Related reading

• Anthropic Claude Managed Agents: dreaming and multiagent orchestration
• Cognition Devin dreaming and Agent Memory Repo
• Google Research sleep framework for LLM memory
• Databricks MemCurrent
• Memory tax: agent memory vs plain RAG
• What is MEMORY.md
• Karpathy LLM wiki pattern

Details are accurate as of November 6, 2026, based on Anthropic's published post.