Agent memory can carry a mistake into every fresh session. Anthropic's November 6 article, The components of agent memory, follows one wrong Pokémon landmark through repeated failures, then shows a transcript-backed repair. Its most useful engineering lesson comes from a separate contract task: several agents can lose important facts while editing the same memory table.

TL;DR

  • Anthropic uses “dreaming” for extra sessions that inspect transcripts and reorganize persistent context. Its definition of agent memory excludes model-weight changes.
  • Correcting a wrong landmark helped the reported Pokémon branch reach Cerulean City. We inspected the source and did no independent gameplay replication.
  • A linked wiki helped some document questions, while other tasks showed no clear gain and one wiki grew larger than its source documents.
  • Contract-specific pages, a single writer per page and verbatim terms recovered all 57 graded facts in one task. Those changes were tested together.

How agent memory preserves an old mistake

Anthropic defines agent memory as knowledge retained between sessions in context the agent can read later. A folder of files is one possible memory store. The surrounding software decides which notes are mounted or injected into a later session, and the model then uses those notes alongside its current context.

That arrangement gives a saved claim a long life. A correct rule can prevent repeated investigation. An incorrect rule can become a reliable way to repeat an error. The persistence mechanism has no inherent knowledge of whether a sentence in a file is true.

The article makes that failure unusually concrete through Pokémon Red. Claude used a Pokémon Center near the entrance to Mount Moon as a landmark. At one point, it incorrectly recorded that the building was on the mountain's east side. The actual entrance was on the west side. Claude left the building believing it had already crossed the cave and should head toward the next city.

It then walked over a one-way ledge and returned to the route it had come from. Its navigation tool failed to show the drop. Claude interpreted the situation as overshooting, which let the original location mistake survive. Another attempt could begin with the same saved assumption.

After the third fall, the model wrote, “I'm going to stop rather than keep looping.” The experimental setup automatically instructed it to continue. That uncorrected branch eventually headed toward an earlier town and ended without reaching Cerulean City. This account comes from Anthropic's published evaluation; the video uses source inspection and conceptual motion rather than fabricated game footage.

What Claude dreaming actually changes

The researchers ran dreaming on the folder containing the incorrect note. Claude checked the note against the original session transcript, caught the error and rewrote the memory. The corrected branch re-entered Mount Moon and eventually reached Cerulean City.

The repair changes a piece of persistent context. The article explicitly excludes changes to model weights from its definition of agent memory. A successful note correction also establishes a much narrower outcome than beating the entire game or proving a general increase in intelligence. The corrected trajectory reaches the next city in this example.

Current Managed Agents Dreams documentation describes an asynchronous job that reads an existing memory store and selected past session transcripts. It produces a separate output store and preserves the input. A developer can inspect the new store and decide whether to attach it to future sessions.

That separation is a useful review point. I would compare the changed notes before replacing a memory store, particularly when a note will be injected automatically. The documented Dreams API is in research preview. Today's research article does not activate a feature for every Claude user.

A dynamic-workflow cookbook offers more control over the run, the transcripts, the instructions and the models. It can update a chosen store in place. The separate-output guarantee of the Dreams API should therefore stay attached to that API, rather than being assumed for every custom workflow.

Fewer files and better memory are different questions

The source compares one gameplay run each from Sonnet 3.7 and Fable 5, at about ten thousand steps. Sonnet wrote 413 memory files across 225 folders and earned one badge. Fable kept nine files in two folders, plus a top-level global.md, and earned four badges.

That is a behavioral comparison between different models. It doesn't isolate the filing system's causal contribution. The observation is still instructive: Sonnet saved detailed game state that could go stale, while Fable's notes focused more on strategy, plans and tested rules.

Some state was visible on the game screen on each turn. Saving another copy created something else to maintain. The article describes Sonnet reorganizing its files over several steps while taking no action in the game. Memory upkeep had become a competing task.

For a developer, I'd separate current observable state from knowledge that needs to survive. A task-specific coordinate may expire quickly. A checked rule about how a tool behaves may be useful later, provided the tool version and source still match. Those are engineering recommendations drawn from the failure mechanism, with no new measured performance claim.

Linked wikis, source search and maintenance costs

Anthropic built a wiki over Stainless's internal document corpus, roughly 350,000 files and 420 million tokens. Over successive dreaming sessions, agents added, linked, corrected and pruned pages. The evaluation used 25 questions about that corpus.

Answering setup Reported result
Search alone 53% of graded criteria
Search plus a growing wiki 54% to 61% as the wiki grew
Wiki alone Best reported score of 48%

These are criteria scores for those questions. The larger wiki made related information easier to navigate, and search remained available to find or check the original material. The report also says wiki-plus-search saved about twenty thousand tokens per question. It doesn't provide a total build-cost figure for all the offline sessions.

That missing cost matters when deciding whether to adopt the approach. Dreams is billed at the selected model's standard API token rates, and the documentation says jobs may take minutes to hours. The article also acknowledges that continuously checking every memory may be impractical.

The source includes useful contrary outcomes. On one Harvey LAB task, a wiki showed no clear gain over source search. Many criteria could be answered by retrieving a passage from a single document. On another task, the wiki became larger than the documents it was supposed to summarize. A representation that duplicates the source may add another maintenance burden without improving retrieval.

I would evaluate a wiki against the questions I actually need answered. The result to watch is whether it helps find reliable evidence and produce better answers at an acceptable total cost. A larger directory or more interconnected pages would be an incomplete success criterion on its own.

Shared writers lost contract facts

The article's simulated-acquisition task asked Claude to build a wiki from contracts and generate a brief. Several agents wrote contract terms into one shared table. The resulting brief included only 41 of the 57 graded facts.

Anthropic traced the failure to poor summaries and agents overwriting one another's work. Important terms had been lost before the answering session could rely on them. More elaborate answer generation would have been working from an already damaged representation.

The researchers used a loop in which Claude reflected on failures, proposed changed wiki instructions and rebuilt the wiki. The revised scheme gave each contract its own page, with one agent writing that page. It quoted contract terms word for word.

The improved wiki supported all 57 graded facts. Both the ownership scheme and quotation rule changed together, so the result gives neither change sole causal credit. A score covering every criterion in this task also remains distinct from a guarantee of accurate legal advice on future contracts. Harvey LAB's own README describes tasks, documents and grading rubrics, and warns that scores across releases may be incomparable.

The practical pattern is worth trying in shared-agent systems. Assign a clear writer to a source-specific page, retain the relevant original terms and let an answering agent follow the source link. I would separately test which parts of that scheme help a particular workload.

A small index still needs trustworthy sources

Claude Code memory documentation limits automatic loading to the first 200 lines of MEMORY.md or the first 25KB, whichever comes first. Detailed topic notes can live elsewhere. This makes the opening file an index rather than an entire archive injected into every session.

A compact index can still contain an incorrect instruction. If the harness injects it into every session, the mistake gets repeated exposure. The custom-workflow cookbook warns that memory is only as good as the transcripts. An analyzer cannot know what changed after the latest transcript it received.

I'd preserve the original source, keep the time boundary visible and review changes to heavily reused notes. When a fact is likely to change, the next session may need to check it again. Transcript review supplies evidence about recorded events; it cannot establish a later external state by itself.

Verdict: NEEDS REVIEW

I stamped this research NEEDS REVIEW. Transcript-backed repair is useful, and the shared-contract example gives a concrete writing pattern to test. Anthropic's own no-gain and oversized-wiki examples also make the limits clear. I would inspect changed memory and measure whether the representation improves the actual task before letting upkeep become another permanent project.

FAQ

Does Claude dreaming retrain the model? Anthropic's article describes retained context and file-memory work, and excludes changes to model weights from this definition.

Does the Pokémon result show dreaming beat the game? The corrected branch eventually reached Cerulean City. The article's separate full-game gameplay account is a different result.

Did one writer per page independently cause the perfect contract score? Ownership and verbatim quotation changed together. The reported task cannot isolate either change's contribution.

Is every transcript a trustworthy ground truth? The cookbook warns that memory inherits transcript limitations and staleness. Important changing facts still require verification.

Sources

Media credits: Dario Amodei portrait by TechCrunch, CC BY 2.0, cropped/background removed/resized; Anthropic identity only, with no authorship, current reaction or endorsement implied. Two Buttons by Jake Clark, Imgflip template, origin attribution via Supermeme; labels added. Groundhog Day GIF, @groundhogday, Bill Murray/Stephen Tobolowsky as Phil/Ned; silent/resized/captioned. Both commentary assets imply no present-day reaction by anyone shown. Hosting is not a licence, and no legal-clearance or blanket-reuse claim is made.

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources