Anthropic just published a research post that answers a question every agent builder eventually hits: what should an agent actually remember between sessions — and how do you stop those memories from going stale or wrong?
The post, "The components of agent memory", breaks agent memory into three parts: memory notes, salience judgment, and "dreaming" — offline reflection that organizes and corrects what was written down. The numbers behind each part are surprisingly concrete, and several of them cut against intuition.
What "agent memory" means here
Anthropic defines agent memory narrowly: knowledge Claude gains from experience — user interactions, assigned tasks — that it retains between sessions as context it can read later.
It explicitly excludes three other things: changes to model weights, in-context learning within a single conversation, and compaction (summaries Claude writes to replace older turns). Memory, in this framing, is a folder of notes that persists across sessions — not training, not the current chat.
The design is borrowed from neuroscience. Humans consolidate experiences into long-term knowledge largely while the brain is offline — during sleep and quiet rest, the hippocampus replays recent experiences. Anthropic applies the same division of labor: the agent works and logs everything during a session, then reorganizes that record between sessions. Researchers at Letta and UC Berkeley call the general idea "sleep-time compute."
Memory is a prediction about the future
Writing a memory is a bet. A rule in a note is a prediction that the pattern it describes will matter again; a verified fact is a prediction that a future session will want to rely on it without re-checking.
Anthropic tested this with a task from Continual Learning Bench (CL-Bench) 1.0, where Claude answers database questions, is told the correct answer, and can write a memory to help with later questions. Each question starts in a fresh session — the only thing that persists is a memory directory.
The models differed sharply in how well they built a learning loop from that setup:
- Claude Sonnet 4.6 got as far as generating theories about why an answer was wrong. Its memory directory was a scattering of files, each listing untested guesses.
- Claude Opus 4.7 consolidated notes into a single reference document and began marking which facts were checked and which were unconfirmed.
- Claude Sonnet 5 marked each answer as confirmed after the grader checked it, and wrote a correction when it was wrong.
- Claude Opus 5 was the first to fully close the loop: most entries included a rule, how it knew the rule was true, answers to earlier questions, and warnings about traps discovered along the way.
- Claude Opus 5.5 and Claude Sonnet 5.5 also closed the loop. With memory, both scored about the same as Opus 5 — though their baselines without memory were slightly higher.
The salience problem: what is worth writing down?
The harder problem isn't storing memories — it's deciding what deserves to be stored before you know what comes next. Anthropic tested this by having Claude play Pokémon Red, a long-horizon task, with a memory folder it could read and write while playing.
At around 10,000 steps into the game, the two models' memory folders looked nothing alike:
- Claude Sonnet 3.7 assumed everything might matter and wrote indiscriminately: 413 memory files across 225 folders, often one file per battle, item, or NPC. It had earned one badge.
-
Claude Fable 5 wrote nine files in two folders, plus a single top-level
global.md. It had earned four badges.
Sonnet 3.7's detailed record kept going out of date because the game state changes constantly. Around step 10,000, it started a fourth folder of "master" memory files — and over the next 17 steps, it created six files, deleted nine others, and took no actions in the game at all.
Fable 5 used memory only for things the game didn't already tell it. How much money the player has, or where the player is on the map, can be read off the screen every turn — storing that is redundant. Strategy, plans, and tested rules exist only if Claude works them out, and disappear unless written down. Its global.md acted as a dashboard: current goal, a prewritten plan for tackling gyms, and its own rules for using memory. Opus 5.5 took a similar approach — a small folder tracking its current goal and next steps, rewritten as it played — and beat the game.
The lesson generalizes: a memory system that records everything becomes a maintenance burden that crowds out the actual work.
Steering: tell it what memory is for, not how to use it
Anthropic also tested whether giving Claude explicit rules about what to write helps. The answer depends on the model:
- Telling Claude what memory is for but not how to use it was enough for Opus 4.7 and Opus 5 to use it effectively on CL-Bench.
- A rule like "record only failures" cost both Opus 5 and Opus 4.7 much of the performance boost memory gave them. For stronger models, freedom to judge salience beat fixed rules — and the rules could actually weaken performance.
- Steering helped older models the most. Sonnet 4.6 often didn't read its memory files or test its theories about wrong answers. Prompting it to read memory before answering and explicitly test its theories nearly doubled its benchmark score. Sonnet 5 does this on its own: without being prompted, it read its memory before answering 9 out of 10 times, versus less than half the time for Sonnet 4.6.
Dreaming can correct a wrong memory
Because Claude writes memories based on what it judges salient in-session, a note can be wrong from the start — or drift as the environment changes — and then be trusted by a later session. Dreaming gives Claude a way to check notes against the original transcripts.
The post's clearest example comes from Pokémon. Claude had to cross Mt. Moon, a cave with its entrance on the west side and exit on the east. It used the PokéCenter, a building at the mountain's entrance, as a landmark. At one point it incorrectly recorded that the PokéCenter was on the east side, walked out, announced "Mt Moon is behind me," and updated its notes: "Mt Moon DONE."
A few actions later it walked off a one-way ledge and landed back on the route it came from. Its navigation tool didn't show the drop, so it concluded it had overshot west — and kept believing it was on the correct side.
Running dreaming on that memory folder let Claude check the note against the session transcript, catch the error, and rewrite it. With the corrected note, it went straight back into Mt. Moon and reached Cerulean City. In the run with the uncorrected note, Claude dropped back onto the earlier route three times, seemed to give up ("I'm going to stop rather than keep looping"), and ended the run back in Pewter City, never reaching Cerulean City.
The transcript is the ground truth. Dreaming is the mechanism that checks notes against it.
Dreaming can build new representations: the wiki
Dreaming can also build representations that help Claude navigate a growing knowledge base. One is a wiki: a set of pages Claude writes and maintains, gathering what it knows about a subject and linking to other notes — effectively a map of its memory.
Anthropic tested this on a corpus of internal documents from Stainless, a software company it acquired in May: about 350,000 files, roughly 420M tokens. Over 128 sessions, Opus 5 agents explored the files, wrote and corrected linked wiki pages, merged duplicates, and checked claims against sources.
- As dreaming scaled from 2 sessions to 128, performance on a 25-question evaluation set grew from 13% to 48% of graded criteria.
- With both search and the wiki, the aggregate score rose from 54% to 61% as the wiki grew, versus 53% with search alone. The wiki alone scored 48% at best.
- Using search and the wiki together also saved about 20,000 tokens per question.
The wiki isn't universally better. On a Harvey LAB benchmark task asking 24 questions about a merger, Claude scored 87% consulting the wiki versus 73% with search alone. But on another LAB task, brief criteria could be retrieved with a text search from a single document, and the wiki showed no clear gain. On yet another, the wiki grew larger than the documents themselves — Anthropic invokes Borges's mapmakers, who drew a map as large as the empire it represented. A representation that abstracts nothing is not a representation.
The memory hierarchy and context injection
Dreaming can also promote notes up the memory hierarchy, so the agent harness preloads them into Claude's context at the start of every session — no search needed, no need to even know something is there to search for.
That promotion has to be handled carefully. Injected memories consume tokens, and a wrong note gets carried into every session. Loading a note also doesn't guarantee Claude acts on it: Anthropic's Claude Code documentation warns that longer instruction files reduce adherence. So the top layer of the hierarchy has to stay small, and much of dreaming's work is keeping it that way — pushing details down and leaving links behind.
Claude Code's auto memory does exactly this: it loads only the first 200 lines or 25 KB of MEMORY.md into each session. That header is an index — it tells Claude what it knows and where to find it.
Dreaming can focus memory on a specific goal
Dreaming can also be tuned so memory grows in service of a particular goal. In one LAB task simulating a company acquisition, the brief was graded on whether it correctly described contract terms. The initial wiki-building instructions were generic, and several agents wrote to a shared table of contract terms simultaneously — overwriting each other. The resulting brief included only 41 of 57 facts (72%).
Anthropic then ran a loop where Claude reflected on its failures, proposed instruction changes, and rebuilt the wiki. The improved instructions gave each contract its own page, written by a single agent, quoting terms verbatim instead of summarizing them into a shared table. The brief generated from the improved wiki met 100% of the criteria, up from 72%.
Dreaming can also fill gaps a single session leaves behind. In one task, it found nine links pointing to a missing wiki page and repointed them to an existing page for the same document, and added three new pages, including an index.
What builders should take from this
Three practical takeaways stand out:
Record less, but record what only you can know. Fable 5's nine files beat Sonnet 3.7's 413. Memory should hold strategy, plans, and tested rules — things that disappear if not written down — not facts that are cheap to re-derive.
Let strong models judge salience; steer weak ones. Fixed write-rules hurt frontier models and helped older ones. If your agent is capable, give it the purpose of memory and let it decide. If it isn't reading memory or testing its own theories, explicit prompting can nearly double its score.
Treat memory as something that needs maintenance, not just storage. Notes go stale, get written wrong, and drift. Dreaming — offline passes that check notes against transcripts, build indexes like wikis, and promote only the essentials into context — is the maintenance layer. Without it, a wrong note doesn't just sit there; it gets trusted by every future session.
Anthropic is candid that open questions remain: when exactly to create a memory (writing in the moment steals attention from the task; dreaming defers it), how to keep memory reliably up to date without checking everything constantly, and whether transcript search should be the foundation with representations layered on top. But the shape of the answer is now clearer: memory is a small, curated, actively maintained layer — and the curation is where the work is.
Source: Anthropic, "The components of agent memory" (published November 6, 2026).
Top comments (1)
The “global.md as dashboard” pattern is the practical insight here. It suggests a strong salience test: retain a fact only if it changes a future decision and cannot be cheaply re-observed. I’d want consolidation to preserve provenance and confidence too; otherwise dreaming can turn a corrected but local observation into an overconfident global rule.