Claude Opus 4.7 scored 0.383 on a database benchmark without memory. With a memory store, the same model scored 0.700. Anthropic published that result on November 6 in a research post titled The components of agent memory.
The post tests how Claude agents keep knowledge between sessions. Its most useful findings are practical. Small, curated memory beat large piles of notes. A background review step, which Anthropic calls “dreaming,” fixed wrong notes and built searchable wikis. Developers can already try dreaming, but only through a research preview.
What Anthropic means by agent memory
Anthropic defines agent memory as knowledge Claude gains from experience and keeps between sessions. The definition leaves out changes to model weights, in-context learning and compaction.
The post splits memory into four layers, from bottom to top:
- Transcripts: a searchable log of what happened in each session.
- Memory notes: notes Claude writes itself, such as tagged events in a log or files in a memory folder.
- Memory representations: structures such as wikis, with linked pages that Claude maintains.
- Injected context: text loaded into every new session at startup.
The idea borrows from how human memory is thought to work. People capture experiences quickly, then replay and consolidate them during sleep and rest. Researchers at Letta and UC Berkeley proposed a related idea called sleep-time compute. Anthropic’s version is dreaming: offline reflection on logs to correct mistakes and write new notes. Dreaming can work on all four layers.
The post also frames memory as a bet on the future. In its words, “Memory is, occasionally, a prediction.” Writing down a tested rule implies the agent expects to need it again.
How much memory helped on CL-Bench
Anthropic ran a database task from Continual Learning Bench (CL-Bench) 1.0. It compared a stateless baseline with the same model using a memory store. The table shows mean reward.
| Model | No memory | With memory store |
|---|---|---|
| Claude Opus 5.5 | 0.655 | 0.838 |
| Claude Sonnet 5.5 | 0.644 | 0.833 |
| Claude Opus 5 | 0.564 | 0.828 |
| Claude Opus 4.7 | 0.383 | 0.700 |
| Claude Sonnet 5 | 0.306 | 0.610 |
| Claude Sonnet 4.6 | 0.330 | 0.364 |
The older Sonnet 4.6 barely gained. It came up with theories but did not reliably test them. It also read its memory before answering less than half the time. With prompts to read memory first and test its theories, it reached 0.641. Sonnet 5, by contrast, read its memory 9 out of 10 times without prompting.
Anthropic says Opus 5 was the first model to “close the loop.” It recorded validated rules, answers and warnings. Opus 5.5 and Sonnet 5.5 matched that level with memory, from slightly higher baselines.
Why fewer notes won in Pokemon Red
Anthropic also compared how models used memory while playing Pokemon Red. Sonnet 3.7 wrote 413 memory files across 225 folders. It often logged every battle, item and character. Around step 10,000, it spent 17 steps creating six files and deleting nine, with no game moves. It earned one badge.
Claude Fable 5 kept nine files in two folders, plus a top-level global.md file. That file worked as a dashboard with goals, gym plans and memory rules. Fable 5 earned four badges. Opus 5.5 kept a small folder with its current goal and next steps, and it beat the game.
The post gives a simple reason. Facts on screen, such as money or position, go stale fast. Strategy and tested rules exist only if Claude writes them down.
What dreaming fixed
A wrong note in Mt. Moon
In one run, Claude wrote down the wrong location for a PokeCenter. It then walked off a one-way ledge three times and finally backtracked to Pewter City. After dreaming checked the note against the original transcript and fixed it, Claude went back into the cave. It reached Cerulean City at action 1,935. The run with uncorrected memory never got there, and neither did the run with no memory.
Wikis built from company files
Anthropic tested wiki building on an internal corpus from Stainless, a software company it acquired in May. The corpus held about 350,000 files, or roughly 420 million tokens. The test used 25 questions.
As dreaming grew from 2 to 128 sessions, the wiki-only score rose from 13% to 48% of graded criteria. The wiki grew from 103 pages and 766 links to 222 pages and 12,893 links. Search alone scored 53%. Wiki plus search rose from 54% to 61% and saved about 20,000 tokens per question.
Results on the Harvey LAB legal benchmark were mixed. On a 24-question merger set, multi-document items scored 87% with the wiki and 73% with search alone. On another task, the wiki showed no clear gain because most answers sat in one document. In one case, the wiki grew to 1.77 times the size of its 115 KB source corpus.
Instructions mattered too. In a contract-terms task, several agents wrote to one shared table and overwrote each other. Only 41 of 57 facts, or 72%, survived. After each contract got its own page with terms quoted word for word, all 57 facts survived. A second dreaming pass also repaired nine links that pointed to a missing page and added three new pages.
What changes for developers
Who can use dreaming now
Dreaming is a research preview in Claude Managed Agents, according to Anthropic’s documentation. Access requires a request form. The feature is on the Claude API only, and it is not eligible for zero data retention or HIPAA.
A dream takes one existing memory store and 1 to 100 past sessions. It writes the result to a new memory store and never changes the inputs. Developers can add optional instructions to steer what it keeps. A dream typically runs from minutes to a few hours. It bills at standard token rates for the chosen model, and cost scales roughly with the number and length of sessions. Anthropic suggests starting with a small batch.
Lessons from the tests
- Explain the purpose, not the method. Telling strong models what memory is for worked best.
- Avoid rigid rules. A fixed “record only failures” rule cut memory gains by 0.234 for Opus 5 and 0.150 for Opus 4.7.
- Keep startup memory short. Preloaded context costs tokens and carries errors into every session. Long instruction files can also lower adherence.
- Use an index. Claude Code’s auto memory loads only the first 200 lines or 25 KB of MEMORY.md, which works as an index.
- Combine wikis with search. In the Stainless test, the mix beat either one alone.
For teams building agents, this suggests memory design is now a tuning task, much like prompt design. The data shows that more notes do not mean better results.
How this fits Anthropic’s earlier moves
Anthropic first announced dreaming on May 6, 2026, at its Code with Claude developer conference, as SiliconANGLE reported. At the time, it said users could schedule dreaming and choose whether memory updates apply automatically or after review. The November post adds the test data behind the feature, plus public knowledge wiki quickstarts for developers.
What remains unclear
Anthropic lists several open problems. Writing memory during a task pulls attention from the task. Dreaming moves that work to the background, but the results may not be available right away. Notes can be wrong from the start or drift as things change, and fixing them costs compute. Very detailed wikis can grow as large as their sources and summarize nothing.
The documentation leaves practical gaps as well. It does not clearly list which models support dreaming, and it gives no date for wider availability. Anthropic says it still has “a lot to learn” about memory system design.
