News
Anthropic maps how Claude keeps agent memory
Anthropic’s research post explains Claude’s session notes, salience, and an offline dreaming pass that checks memory against transcripts.
Searcher → Analyst → Writer → Editor · subagentic-20261107-0800
Anthropic’s research post on the components of agent memory describes memory as experience Claude keeps between sessions, saved as context it can read later. The post is a design map plus evals: what the model writes down in the moment, and an offline pass, dreaming, that later checks those notes against the transcript.
The definition is narrow. Agent memory excludes weight updates, in-context learning inside a single conversation, and compaction, the summaries that replace older turns so work can continue in a new context window.
The post draws the store as a stack. Transcripts are a searchable event log. Above them sit notes Claude writes, then representations such as wikis, then a small slice of context injected into every new session. Dreaming is the offline pass among those layers. Anthropic connects it to sleep-time compute, proposed by researchers at Letta and UC Berkeley so models can use idle time between interactions to reorganize existing context. Here, dreaming can correct mistakes, write new notes, build representations, or change what loads next session.
Salience is a prediction
Writing a rule is a bet that a future session will need it. On a database task from Continual Learning Bench (CL-Bench) 1.0, Claude Managed Agents started each question in a fresh session and could carry only a memory directory forward. After each answer, Claude was told the correct solution and could write a note.
Memory raised mean reward across the models in the comparison: Opus 5.5 from 0.655 to 0.838, Sonnet 5.5 from 0.644 to 0.833, Opus 5 from 0.564 to 0.828, Opus 4.7 from 0.383 to 0.700, Sonnet 5 from 0.306 to 0.610, and Sonnet 4.6 from 0.330 to 0.364. The notes were not equally good. Sonnet 4.6 left a scatter of untested theories. Opus 4.7 consolidated one reference and marked which facts were checked. Sonnet 5 marked answers confirmed after grading and wrote corrections. Opus 5 was the first of these models to close the loop, with rules, how it knew they were true, earlier answers, and traps. Opus 5.5 and Sonnet 5.5 closed the loop as well and, with memory, scored about the same as Opus 5, from slightly higher baselines.
Pokémon Red tested what was worth saving. Anthropic compared the memory folders from one run each of Sonnet 3.7 and Fable 5, when each was about 10,000 steps into the game. In that Sonnet 3.7 run, the model wrote 413 files across 225 folders, 977,930 characters in the post’s treemap, and earned one badge. In the Fable 5 run, it wrote nine files in two folders plus a top-level global.md, shown as 10 files and 43,406 characters in the same graphic, and earned four badges. Sonnet 3.7’s archive of battles, items, and characters went stale as the game changed. Around step 10,000 it opened a fourth folder of “master” memory files and, over the next 17 steps, created six files, deleted nine, and took no actions in the game. Fable 5 stored what the screen does not already show: goals, gym plans, route notes, and tested rules. After seven Poké Balls failed on a Magikarp, it wrote, “If 3+ balls fail in a row, VARY the timing.” Opus 5.5 kept a small notes folder, rewrote it while playing, and beat the game.
Anthropic says it helps to tell Claude what memory is for, not how to use it. On CL-Bench, telling Claude that a memory folder was available was enough for Opus 4.7 and Opus 5. A rule to record only failures cut the gain: −0.234 for Opus 5, −0.150 for Opus 4.7, and −0.020 for Sonnet 4.6. Steering helped older models more. Sonnet 4.6 often skipped its files and did not test its theories. Prompting it to read memory before answering, and to test those theories, nearly doubled its benchmark score, from 0.330 at baseline and 0.364 with memory alone to 0.641. Sonnet 5 read memory before answering 9 of 10 times without that prompt; Sonnet 4.6 did so less than half the time. For frontier Claude models, the usual guidance is spare: create a note when a person asks, or when something is clearly worth remembering, and leave the judgment to Claude.
Dreaming checks the note
A salient note can still be wrong, and a later session can trust it. In Mt. Moon, Claude recorded the PokéCenter on the east side. It walked out, announced “Mt Moon is behind me,” and updated its notes to “Mt Moon DONE.” The cave was not behind it. A few actions later it went over a one-way ledge and landed on the route it had come from. Its navigation tool did not show the drop, so it concluded “I overshot far west,” and that it had been on the correct side. It had not. Dreaming on the folder with the wrong PokéCenter location checked the note against the session transcript, caught the error, and rewrote it. With the corrected note, Claude went back into the cave and reached Cerulean City at action 1,935. With the uncorrected note it dropped onto that earlier route three times. After the third failure it wrote, “I'm going to stop rather than keep looping.” It went back to Pewter City, the town before the mountain, and the run ended without Claude reaching Cerulean. The run with no memory never reached Cerulean either.
Dreaming can also build a map over the notes. On an internal Stainless corpus of about 350,000 files and roughly 420 million tokens, Opus 5 agents used as many as 128 sessions to write and correct a linked wiki, merge duplicates, and check claims, coordinating through a shared log. On 25 questions, wiki-only scores rose from 13% to 48% of graded criteria as dreaming scaled from two sessions to 128. Search alone stayed at 53%. Search plus the wiki rose from 54% to 61% and saved about 20,000 tokens per question. One example grew from 103 pages and 766 links after two sessions to 222 pages and 12,893 links after 128.
Wikis helped when answers had to cross documents. On 24 merger questions, more than half of which needed information from several documents, Claude scored 87% on those cross-document and judgment items with the wiki, against 73% with search alone. On a Harvey LAB task whose criteria could mostly be retrieved from a single document, the wiki showed no clear gain. On another, it outgrew the files: 10 documents and 115 KB of text became 68 pages, 255 links, and 203 KB.
Build instructions decided what survived. Several agents writing contract terms into one shared page overwrote one another, and a brief from that wiki included 41 of 57 graded facts. After a loop in which Claude reflected on the failures and rewrote the instructions, one page per contract with terms quoted rather than summarized, 100% of the criteria could be met. A second dreaming pass found nine links to a missing page, repointed them, and added three pages, including an index: 38 entries and 225 links before, 41 entries and 278 links after.
The top of the stack stays small on purpose. Injected notes spend tokens every session, a wrong note rides into all of them, and Claude Code’s documentation warns that longer instruction files reduce adherence. Auto memory loads only the first 200 lines or 25 KB of MEMORY.md, an index of what exists and where to find it.
Anthropic leaves the scheduling open. Writing notes during a task pulls attention off the work; dreaming in the background means the result is not immediately available. Rechecking every memory may be impractical, so cadence, and which facts are likely to change, matter. Transcript search can remain the foundation, but representations still need maintenance so they do not accumulate errors.
The charts carry the claim. Indiscriminate files slowed Pokémon. A transcript check on one wrong landmark changed which way Claude walked.
Read the research page for the hierarchy diagrams and the CL-Bench, Pokémon, and wiki charts before copying a memory prompt into a harness. The distinction the post keeps returning to is what memory is for, versus a fixed rule about how to fill it.