Anthropic's 'dreaming' sessions repair wrong notes in Claude's agent memory

A saved mistake that kept steering Claude wrong

Anthropic published "The components of agent memory" on November 6, and a dev.to analysis of the piece surfaces a failure mode anyone building persistent agents should internalize: a memory store has no built-in sense of whether a saved sentence is true.

According to the dev.to write-up, Anthropic defines agent memory as knowledge held between sessions, in context the agent can read later — a folder of files being one possible store. The surrounding software decides which notes get mounted or injected into a later session, and model weights are explicitly excluded from the definition. A correct note saves future work; an incorrect one keeps steering every new session toward the same mistake.

The dev.to article makes this concrete with a Pokémon Red run. Claude used a Pokémon Center near the Mount Moon entrance as a landmark and at one point saved a note placing the building on the mountain's east side, when the entrance actually sits on the west. Acting on that note, Claude left the building believing it had already crossed the cave. It then stepped over a one-way ledge back onto the route it came from — a drop its navigation tool failed to show — and read the situation as overshooting, which let the original error survive. After a third fall the model said it would stop rather than keep looping, but the experimental harness instructed it to continue, and the uncorrected branch ended without reaching Cerulean City. The dev.to author notes this account comes from Anthropic's published evaluation, with no independent gameplay replication.

What dreaming changes, and what it does not

Dreaming, in Anthropic's framing, is an extra session that reviews past transcripts and reorganizes persistent context. Run over the folder holding the wrong note, Claude compared the note against the original transcript, caught the contradiction and rewrote the memory; the corrected branch re-entered Mount Moon and reached Cerulean City.

The dev.to analysis stresses how narrow that outcome is: the repair changes a piece of persistent context, not model weights, and the demonstrated result is reaching the next city in one run rather than a general capability gain.

Per the write-up, the Managed Agents Dreams documentation describes an asynchronous job that pulls in an existing memory store along with chosen past session transcripts, writes its results to a separate output store, and leaves the input untouched, so a developer can review the new store before attaching it to future sessions. The API is in research preview, and the article activates nothing for ordinary Claude users. A separate dynamic-workflow cookbook allows more control, including updating a store in place, so the write-up cautions that the separate-output guarantee belongs to the Dreams API and should not be assumed for custom workflows.

Fewer files is not better memory

The write-up relays a comparison of single gameplay runs of roughly 10,000 steps: Sonnet 3.7 produced 413 memory files across 225 folders and earned one badge, while Fable 5 kept nine files in two folders plus a top-level global.md and earned four badges. The dev.to author flags this as a comparison between two different models, not a controlled test of the filing scheme. The pattern is still instructive: Sonnet recorded detailed game state that could go stale — much of it visible on screen every turn — and spent steps reorganizing files rather than playing, while Fable's notes leaned toward strategy, plans and tested rules.

Wikis helped sometimes, at an unclear price

Anthropic also built a wiki over an internal Stainless corpus of roughly 350,000 files, about 420 million tokens, and graded it with 25 questions. Search alone answered 53% of graded criteria; search plus the growing wiki reached 54% to 61%; the wiki alone peaked at 48%. The combined setup reportedly saved about 20,000 tokens per question, but the write-up notes there is no total build-cost figure, that Dreams jobs bill at standard token rates, and that jobs can run from minutes to hours. Contrary outcomes are included: on one Harvey LAB task the wiki showed no clear gain over source search, and on another task the wiki outgrew the documents it was meant to compress.

Shared writers quietly lost contract facts

The sharpest engineering lesson comes from a simulated-acquisition task in which several agents wrote contract terms into one shared table. The resulting brief contained only 41 of 57 graded facts, and Anthropic traced the loss to weak summaries and agents overwriting each other's entries. A reflection loop in which Claude reviewed the failures and rewrote the wiki instructions led to one page per contract, each page owned by a single writer, and terms carried over word for word; that revised setup captured all 57 facts, though the changes were tested together rather than isolated.

Why it matters

Persistent memory is spreading through agent products, and Anthropic's write-up pairs the core failure mode with a reviewable fix: a background pass that checks saved claims against the transcripts that produced them and writes corrections to a separate store a human can vet before it goes live. Equally valuable is the negative result — concurrent writers to shared memory silently destroy facts before any downstream prompt can help. The transferable pattern is transcript-backed correction, single-writer ownership of each memory item, and a deliberate split between volatile state and durable rules, with total offline cost measured before adoption.