Anthropic's 'Dreaming' Corrects Agent Memory Errors: A Case Study

Introduction: The Pokémon Red Case

Anthropic's latest Agent Memory research demonstrates a failure mode in long-term memory systems. While playing Pokémon Red , Claude attempted to traverse Mt. Moon to reach Cerulean City. Upon exiting the Pokémon Center near the western entrance, it incorrectly noted "Mt Moon is behind me" and recorded "Mt Moon DONE". The cave's entrance is on the west side, the exit on the east; the Center is near the entrance. A one-way ledge nearby drops the player back to the start, but the navigation tool did not show this drop. When Claude fell back, it interpreted the return as "I overshot far west" — believing it had gone too far west rather than realizing it never entered the cave. The false landmark note persisted because new observations were explained through the wrong premise.

After three such loops, the run ended without reaching Cerulean City. Anthropic then had Claude review the raw session against its memory index. It identified the landmark error and corrected the note. This offline review-and-repair process is called Dreaming . With the corrected note, a subsequent run saw Claude return to the cave entrance, enter, and reach the target city. A no-memory control also failed. This single-case comparison shows a concrete behavioral shift: from "walk to next city" to "go back to find cave entrance".

Why Wrong Premises Persist

The core problem: new observations are interpreted through existing (wrong) premises, reinforcing them . The agent's explanation for falling back ("overshot") was consistent with the false note, so the note survived. This mirrors a development scenario where an over-generalized note like "tests require setting TIDEWICK_DATA_DIR" persists because a workaround succeeded, even though the same session contains a counterexample (running unittest directly from root works without the variable).

Raw Records Must Be Queryable

To enable later correction, the system must store user constraints, tool inputs, tool results, and agent interpretations separately , indexed by session and call site. Summaries alone lose the evidence needed to trace how an experience was derived. In the tidewick example (from Anthropic's Cookbook), session 02 shows:

User constraint: "do not modify repo files".

Tool input: make test fails missing stations.json.

Root cause: Makefile cd tests changes cwd; config falls back to Path.cwd()/data → tests/data/stations.json (missing).

Workaround: TIDEWICK_DATA_DIR=$(pwd)/data make test passes.

Counterexample in same session: python -m unittest discover -s tests -t . from root also passes without the variable.

If this is compressed to "tests require TIDEWICK_DATA_DIR", the condition ("when using Makefile entry point") and the counterexample are lost. Session 06 later fixes the code so make test works without the variable (default path becomes _REPO_ROOT/data). Session 07 records the fix in release notes. Only by keeping raw tool commands, outputs, and user constraints can a later review distinguish a temporary workaround from a permanent requirement.

Dreaming: Offline Memory Rewrite

The Cookbook's Dreaming workflow runs an analysis agent per session (parallel, read-only access to raw transcripts). Each analysis agent checks relevant memory notes and emits updates. A consolidation agent then merges duplicates, resolves conflicts, and updates the shared _index.md. The analysis prompt classifies findings into three categories:

Session provides no evidence : Retain; other sessions may support it.

Record explicitly contradicts note : Correct or flag contradiction.

Note stated confidently but source vague/uncertain : Lower certainty, mark for verification.

Crucially, "this session doesn't mention it" does not mean "no session ever supported it". Conflict resolution only replaces old values when a later correction is confirmed; otherwise both versions with dates and sources are kept.

Structured Note Format: Current, Conditions, History, Sources

A well-formed note for the tidewick case:

Current : 0.4.0 includes default data path fix; normal make test needs no extra data dir. Conditions : Code retains the fix, data dir matches example repo layout. Explicit TIDEWICK_DATA_DIR still overrides default. History : Pre-fix make test entered tests/ , breaking default path. Setting variable was a temporary workaround; running unittest from root was an alternative entry point. Sources : Session 02 failure and two pass methods; session 06 config change and test output; session 07 release notes.

This structure keeps actionable guidance (Current), applicability bounds (Conditions), rationale for past behavior (History), and traceability (Sources). When rewriting, the system must re-read the note, edit locally, then re-read to catch concurrent overwrites (though this is not a transactional guarantee).

Verification: Does the New Note Change Behavior?

After rewriting, the next task run validates the correction. The article proposes a controlled experiment: fix code, model, tools, and task; vary only the provided memory.

Over-generalized old note : Does agent assume env var is necessary without checking?

Corrected note : Can it locate current path implementation, verify test without var, explain override rule?

No note : Can it discover on its own? Does corrected memory reduce re-investigation?

Critical pitfall : following the old note (setting the variable) may still make tests pass. A green test does not prove the agent abandoned the expired premise. One must inspect what it read, how it reasoned, and what it executed.

If the corrected note doesn't improve behavior, inject the correct note directly into context and re-run. If direct provision works better, the issue is retrieval (indexing/search). If it still fails, the issue is condition understanding or action selection. This isolates "can't find" from "found but misused".

Replay on pre-fix code verifies the new note still recognizes the historical path problem (the workaround remains valid under old conditions). Record task outcomes, key actions, latency, and token usage to judge whether memory helps and whether Dreaming's cost is justified.

Implementation Notes

Two deployment patterns exist:

Cookbook nightly script: in-place update of shared library.

Dreams API (research preview): produces a separate output library; input library unchanged. Developers inspect before adopting. This enables verify-then-switch but does not automate task replay.

The author suggests starting with one frequently cited note: keep old version, locate sources, add conditions, re-run its original task. Success is only confirmed when the next action shows the agent abandoned the old judgment — as Claude did by returning to the cave entrance.

References

[1] Anthropic: The components of agent memory , Lance Martin, 2026-11-06 (https://www.anthropic.com/research/components-of-agent-memory)

[2] Anthropic X post (https://x.com/AnthropicAI/status/2118814753154064501)

[3] Claude Platform Docs: Dreams (research preview) (https://platform.claude.com/docs/en/managed-agents/dreams)

[4] Claude Cookbook: Dreaming with a dynamic workflow (https://platform.claude.com/cookbook/managed-agents-cma-dreaming-with-a-dynamic-workflow)

[5] Dreaming tutorial analysis/consolidation prompts (GitHub: anthropics/claude-cookbooks@d4bd2fb) (https://github.com/anthropics/claude-cookbooks/tree/d4bd2fb364a7daa77fa90390800ba3aafffd2d1f/managed_agents/example_data/memory_distill/prompts)

[6] Dreaming tutorial fictional project sessions 02, 06, 07 (same repo) (https://github.com/anthropics/claude-cookbooks/tree/d4bd2fb364a7daa77fa90390800ba3aafffd2d1f/managed_agents/example_data/memory_distill/transcripts)