Anthropic maps the agent memory stack: dreaming lifts wiki recall from 13% to 48%

On November 6, Anthropic published “The components of agent memory”, an engineering post by Lance Martin that does something vendor memory docs rarely do: it puts numbers on which parts of an agent’s memory actually help, which parts hurt, and how much model quality matters. The headline finding is that an offline pass Anthropic calls “dreaming”, where Claude rereads its own logs while idle and rewrites its notes, can turn a raw document corpus into a wiki that answers questions far better than the wiki could at the start. It also shows memory going wrong: bloated notes, stale facts, and parallel agents overwriting each other.

Anthropic shipped dreaming as a research preview in Claude Managed Agents in May. This post is the first detailed look at how the company thinks the pieces fit together, with experiments behind each claim.

Four layers, and what does not count as memory

The post borrows from neuroscience: the hippocampus records experience quickly, then replays it during rest so some of it consolidates into long-term knowledge. Anthropic’s agent version has four layers:

1. Transcripts: a searchable log of everything that happened in a session.
2. Memory notes: observations Claude decides are worth keeping, written as tags in the log or as files in a memory store.
3. Memory representations: structured forms built from notes, mainly wikis of linked pages about a subject.
4. Injected context: the small set of material loaded into every new session.

Dreaming works across all four: it checks notes against transcripts, builds wikis, and promotes the most useful material to the top layer. Anthropic explicitly excludes weight updates, in-context learning and compaction from its definition, which keeps the discussion about files an agent reads and writes rather than about training.

The top layer is kept deliberately small because longer instruction files reduce adherence. Claude Code, for example, loads only the first 200 lines or 25 KB of MEMORY.md as an index and leaves the rest to be read on demand.

Memory only pays off if the model knows what to keep

The cleanest experiment uses CL-Bench 1.0, a database question task where Claude answers in fresh sessions with a persistent memory directory. Mean reward, without and with memory:

Model	Baseline	With memory
Opus 5.5	0.655	0.838
Sonnet 5.5	0.644	0.833
Opus 5	0.564	0.828
Opus 4.7	0.383	0.700
Sonnet 5	0.306	0.610
Sonnet 4.6	0.330	0.364

The gap between Sonnet 4.6 and newer models is the interesting part. Anthropic says Opus 5 was the first model to fully “close the loop”, recording rules, where it verified them and warnings for its future self. Sonnet 4.6 wrote down untested guesses. Sonnet 5 read its memory before answering 9 out of 10 times without being told to; Sonnet 4.6 did so less than half the time. Prompting Sonnet 4.6 to read memory and test its theories raised it from 0.330 to 0.641, so older models can benefit, but only with scaffolding.

Instruction style matters too. Telling frontier models what memory is for worked better than prescribing how to use it. A rigid “record only failures” rule cut the memory gain by 0.234 for Opus 5 and 0.150 for Opus 4.7.

Pokémon Red makes the salience point vividly. Sonnet 3.7 wrote 413 memory files across 225 folders, about 978,000 characters, mostly logging encounters and items, and spent steps reorganizing its notes instead of playing. It earned one badge. Fable 5 wrote nine files in two folders plus a global.md dashboard, about 43,000 characters focused on goals and gym strategy, and earned four. Opus 5.5 kept a small folder of goal notes and finished the game.

Dreaming: fixing wrong notes and building wikis

Two experiments show what the idle-time pass buys.

Correcting errors. A planted note put the Pokémon Center on the wrong side of Mt. Moon, which led Claude off a one-way ledge. Dreaming checked the note against the transcript and fixed it; the corrected run went back into the cave and reached Cerulean City at action 1,935. The uncorrected run dropped back onto the earlier route three times and retreated to Pewter City. A run with no memory never reached Cerulean.

Building a wiki from a large corpus. Anthropic pointed dreaming at roughly 350,000 files, about 420M tokens, from Stainless, a company Anthropic acquired in May, and tested on 25 questions. Over 128 sessions:

• Wiki-only accuracy rose from 13% to 48% as the wiki grew from 103 pages and 766 links to 222 pages and 12,893 links.
• Wiki plus search reached 61%, against 53% for search alone, and saved about 20,000 tokens per question.

On Harvey’s LAB legal benchmark, using merger documents, wiki plus search scored 87% on multi-document questions versus 73% for search alone. When the answer sat in a single document, the wiki gave no clear gain. That is the practical takeaway for builders: a maintained wiki is a cross-document synthesis tool, not a better retriever.

Where memory goes wrong

The post is unusually candid about failure modes:

• Concurrent writes. Several agents writing contract terms to one shared table kept only 41 of 57 facts (72%). Giving each contract its own page with terms quoted verbatim kept all 57. Structure, not just content, decides what survives.
• Over-building. One LAB wiki grew to 1.77 times the size of its source (115 KB to 203 KB), with some pages linked from nowhere. A wiki bigger than its corpus is not abstracting anything.
• Staleness and hallucination. Wrong notes get trusted in later sessions, and checking every memory continuously is impractical, so the cadence and focus of dreaming has to be tuned. A second dreaming pass in one test repaired nine links to a missing page and added three pages, which shows both that it can clean up and that the first pass left a mess.
• Cost and timing. Writing notes mid-task steals attention from the task. Dreaming moves that cost to the background, but its output may not be ready for the next session, and maintaining wikis consumes compute.

Anthropic is also clear about scope: the results come from specific benchmarks and one game.

What to watch

The post ships with cookbooks for “getting started with dreaming” and “knowledge wikis”, and mentions goal-focused dreaming tuned for assistants like Claude Duet. For anyone building their own system (our guide to adding memory to agents covers the basics), three design rules fall out of the data: keep the always-loaded layer tiny, give each entity its own page rather than a shared table, and budget a verification pass that checks notes against the raw transcript. The open question is cost: Anthropic does not say how much compute 128 dreaming sessions over a 420M-token corpus took, which is the number that decides whether wikis beat plain search in production.