Anthropic's Dreaming Turns Agent Memory Into a Self-Correcting System

Why an AI agent's notes get worse on their own, and the small cleanup routine that fixes them

Give an AI agent a notebook and it will fill it. That part works. The trouble shows up a few days later, when the notebook is full of half-right facts the agent trusts completely.

Anthropic's engineering team ran this experiment on a game. Sonnet 3.7, an older Claude model, played Pokemon Red with a memory folder and wrote 413 memory files across 225 folders. It earned one gym badge. Fable 5, a newer model, kept nine files plus a single global.md and earned four. Two runs at about 10,000 steps each can't prove that fewer notes caused the difference (Fable 5 is also a far stronger model), but the picture is hard to ignore: more notes did not buy more progress.

That result sits at the center of "The components of agent memory," a post Anthropic published on November 6. Its argument fits in one line: memory is not something you store, it is something you maintain. Anthropic calls its maintenance pass "dreaming," and it is now a feature you can call.

If you run agents that remember anything between sessions (Claude Code's auto memory, a notes folder in your own agent setup, a vector store bolted onto a support bot), this changes what you should build next. Here is what Anthropic found, in plain terms, and how to copy the useful parts this week.

Four layers, one sticky note

The post describes agent memory as a stack of four layers. A filing analogy helps.

At the bottom sit the transcripts: the raw record of every session, like security camera footage. Nothing gets lost there, but nobody wants to rewatch it.

Above that are memory notes, the files the agent writes for itself ("the build needs Node 20", "this client prefers short replies").

Then come representations, such as a wiki the agent assembles from many notes and documents.

At the top is injected context: whatever gets loaded into every new session automatically. Think of it as the sticky note on the monitor. It is the only layer the agent reads without being asked.

Anthropic's key warning is about that top layer. In the post's words, "the top layer of the memory hierarchy has to stay relatively small." Two reasons. Everything there costs tokens in every session. And a wrong fact there gets carried into every session too.

Claude Code already enforces this. Its memory docs say the first 200 lines of MEMORY.md, or the first 25 KB, whichever comes first, load at the start of each conversation. Whatever sits beyond the limit that hits first is not loaded at session start. The rest of the memory lives in topic files that Claude opens only when it needs them.

How a wrong note wins

The post's best example is a small disaster.

In Pokemon Red there is a cave called Mt. Moon with a one-way ledge near the entrance. Claude used a nearby PokeCenter as a landmark and wrote down the wrong side for it. It then recorded "Mt Moon DONE," fell off the ledge three times, and ended the run stuck in the previous town. The bad note stayed in memory, so the next run would start from the same mistake.

Dreaming fixed it. The offline pass compared the note against the transcript, saw that the landmark was wrong, and rewrote the note. The corrected run went back into the cave and reached Cerulean City at action 1,935, according to the post's chart. The uncorrected run never got there. Neither did the run with no memory at all.

That is the whole case for maintenance in one story. A note is a claim about the world. Claims go stale, and some were wrong to begin with. Without a check, the agent treats its own old mistakes as ground truth.

What dreaming actually does

Dreaming is a separate job that runs after the work, not during it. It reads the existing notes alongside past transcripts, then writes a new, reorganized set of notes: duplicates merged, stale entries replaced, wrong ones corrected, new insights added.

Anthropic's Dreams documentation adds the practical details. It is a research-preview feature of Claude Managed Agents, Anthropic's hosted agent platform. A dream takes one memory store plus between 1 and 100 past sessions as input. The original store is never modified; the output is a brand-new store you can attach to future sessions or throw away. A run takes "minutes to a few hours," and it is billed at standard token rates for the model you pick.

That "never modified" detail matters more than it sounds. You can compare the old store and the new one before trusting either. Memory maintenance becomes a reviewable change, like a pull request, instead of a silent rewrite.

The post also lists jobs dreaming can do beyond correction: promoting a note that keeps coming up into the always-loaded layer, building a wiki from scattered notes, and filling gaps a session left behind.

Three findings that change how you write memory

Most memory advice is about retrieval. The post's most useful findings are about writing.

Over-instructing hurts. Anthropic tested a rule that sounds sensible: "record only failures." It made things worse. On a database task from CL-Bench, an Anthropic benchmark for agents that learn across sessions, the rule cut Opus 5's memory gain by 0.234, Opus 4.7's by 0.150 and Sonnet 4.6's by 0.020 (the post reports these as drops in the improvement memory gave each model). For current frontier models, the post recommends simple guidance: say what the memory folder is for, then let the model judge what is worth keeping.

Older models need the opposite. Sonnet 4.6 read its memory before answering less than half the time. Prompting it to read memory first and test its theories nearly doubled its score. So the right instruction depends on the model. If your agent runs an older or smaller model, tell it to check memory. If it runs a frontier model, stop micromanaging what it writes.

Wikis help, with a catch. On a code corpus from Stainless (about 350,000 files), scaling dreaming from 2 sessions to 128 raised the score of wiki-only answers from 13% to 48% of graded criteria. A wiki plus search reached 61%, against 53% for search alone. So the wiki works best as a layer on top of search, not a replacement. The catch: on one legal task the wiki grew to 203 KB from a 115 KB source, bigger than the documents it summarized, and on a single-document task it gave no gain.

One smaller result is worth stealing outright. Asked to track contract terms, a single shared table kept 41 of 57 facts. One page per contract kept all 57. Structure beats volume.

Put this into practice

You do not need Managed Agents to use these ideas. Here are three levels, from five minutes to an afternoon.

1. Audit your always-loaded layer (5 minutes). In Claude Code, run /memory to open the memory files for the current project. They live under ~/.claude/projects/<project>/memory/. Check MEMORY.md against the 200-line, 25 KB limit. Keep it as an index, one line per memory pointing to a topic file, and move details into the topic files. Delete anything that describes state the agent can see for itself (the post's example: in-game money and map position, which went stale fast). If you would rather turn auto memory off for a project, the docs list "autoMemoryEnabled": false in project settings, or the environment variable CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

2. Run a manual dream once a week (30 minutes). Start a fresh Claude Code session in the project and give it a job that mirrors dreaming:

Read MEMORY.md and every topic file in the memory folder. Then read
the transcripts of this week's sessions. For each memory note, mark it
confirmed, wrong, or stale based on what actually happened. Propose a
rewritten MEMORY.md under 150 lines and list every change with the
transcript evidence. Do not edit any file until I approve.

That last line keeps the "never modify the original" property from the real feature. You review a diff, then apply it.

One timing detail matters here. Claude Code deletes old session transcripts after cleanupPeriodDays (30 days by default), while the memory docs note that this cleanup does not touch memory files. Your notes outlive the evidence behind them. Run the check inside that window, or the only record of why a note exists will be gone.

3. Call the Dreams API (an afternoon). If you already run Claude Managed Agents, the docs show the Python SDK call client.beta.dreams.create(...) with two inputs: your memory store ({"type": "memory_store", "memory_store_id": ...}) and a list of session ids ({"type": "sessions", "session_ids": [...]}), plus a model and optional instructions. The dream starts as pending; poll it until it is completed, then attach the output store to a test session and compare answers before switching production over. The SDK sends the required beta headers. Anthropic's knowledge-wiki quickstart shows the wiki side end to end; its recorded run on eight SEC filings took 23 minutes and cost about $16.

Honest limitations

Every number in this piece comes from Anthropic measuring its own models on its own tasks. CL-Bench, the Pokemon runs and the Stainless corpus are useful illustrations, not independent evidence. Your agent, your data and your model will produce different numbers.

Dreaming costs money. Each run reads transcripts and notes with a large model, and the post itself says that having Claude constantly check all its memories "might not be practical." Weekly is a reasonable starting cadence; daily is probably waste for most teams.

The managed feature has real constraints. It is a research preview, only select models are supported (the docs list Haiku 5.5 among the unsupported ones), and it is not eligible for zero data retention (Anthropic's arrangement where API data is not stored) or HIPAA, the US health-privacy rule. If your transcripts hold regulated data, the manual weekly pass is easier to keep inside the setup and data terms you already approved for Claude Code.

And a dream can be wrong too. A model rewriting notes from transcripts can misread the transcript. The new store being separate is the protection: diff it, spot-check it, then switch.

The shift

The useful question about agent memory used to be "how do I store more?" Anthropic's post makes a good case that the better question is "who checks it?" The agents that improve over weeks will be the ones whose notes get reviewed against what actually happened, with a small sticky note on top and the evidence kept long enough to check.

Start with the five-minute audit. Open MEMORY.md and count the lines. Then decide whether your agent's memory is a record of what it learned, or a pile of things it once believed.

Sources: Anthropic, "The components of agent memory" (November 6, 2026); Claude Managed Agents Dreams docs; Claude Code memory docs; knowledge-wiki quickstart README. All read November 7, 2026.