Anthropic's Agent Memory Architecture: The Memory Philosophy of Less Is More

When your coding agent forgets everything between sessions and keeps ignoring the rules you add to CLAUDE.md, the problem may not be too little memory — it may be the wrong way of remembering. In a post about agent memory published on November 6, Anthropic revealed a counterintuitive conclusion through a Pokemon Red experiment: a Claude that saved 413 memory files actually performed worse than a Claude that maintained only a short dashboard.

Behind this is the four-layer memory architecture proposed by Anthropic, along with an offline consolidation mechanism called "Dreams." For anyone using Claude Code or building long-running agents, understanding this design is more important than installing any memory plugin.

The Pokemon Red Experiment: It's Not How Much You Remember, It's How Well

Anthropic ran a roughly 10,000-step Pokemon Red experiment in which different models each maintained their own memory folder. Sonnet 3.7 assumed everything might matter and saved information almost indiscriminately — the player's money and map location were displayed directly on screen every turn, yet it still took very detailed notes, ultimately earning only one badge. Fable 5 took a completely different approach: it wrote only a short file list plus a file called global.md, which Anthropic described as a "dashboard." This dashboard contained the current goal, a pre-written gym plan, and the model's own rules. At the same point in the game, Fable 5 earned four badges.

The core insight of this pattern is simple: money and the map are freely visible every turn, while the gym plan must be derived through reasoning. Save what you had to compute, not what you can directly see. You may not have noticed, but Anthropic itself acknowledges that this was an internal test and has not yet been independently reproduced — though the pattern itself is easy to borrow.

Open-source plugins like claude-mem (over 100,000 stars on GitHub) advocate capturing everything an agent does, compressing it, and injecting it into subsequent sessions, and many popular videos recommend this approach. Forgetting does have a cost, but indiscriminate saving also has a cost — and it may be more insidious.

The Four-Layer Memory Architecture: From Raw Logs to Injected Context

Anthropic divides memory into four layers, which can be understood as a desk with drawers.

• At the bottom are transcripts: searchable logs of events that occurred in each session — the raw record of facts.
• Above that are memory notes: observations that Claude itself judges worth writing down.
• Above that are memory representations: larger, more organized structures, akin to encyclopedia entries.
• On the top of the desk is injected context: content loaded before any work begins. In Claude Code, this includes the CLAUDE.md you write and the auto-memory Claude writes itself.

Both are loaded at the start of every session. Auto-memory is truncated at a 200-line or size limit, while your CLAUDE.md is not cut off by this limit. The Claude Code documentation recommends keeping CLAUDE.md under 200 lines, because longer files consume more context and reduce adherence. The documentation does not explain why length harms adherence, but Anthropic's argument is straightforward: injected memory consumes tokens every time, wrong notes get carried into every session, and loading notes does not guarantee Claude will act on them. The Claude Code documentation explicitly states that Claude treats these files as context, not as enforced configuration.

auto-memory is a memory file autonomously maintained by Claude in Claude Code, sitting alongside the user-written CLAUDE.md and loaded automatically at the start of every session. It records observations, rules, or context summaries that Claude deemed worth saving during past interactions, but is subject to truncation at a 200-line or file-size limit. Unlike CLAUDE.md, auto-memory content is entirely model-generated and typically not directly edited by users, so it may contain outdated or unverified entries. Its original purpose is to let the agent accumulate experience without human intervention, but this also means that once a wrong note is written, it may be repeatedly injected. Anthropic recommends periodically reviewing the top-level content of auto-memory and combining it with the Dreams mechanism for offline correction to avoid the accumulation of "memory pollution."

The Cost of Wrong Notes: From Mt. Moon to Dream Correction

In the Pokemon Red experiment, Claude once confused which side of the Pokemon Center it was on, declared that the mountain was behind it, and wrote the note "Mt. Moon, completed." In reality, it was not completed. Worse, this wrong note was repeatedly loaded because there was no mechanism to verify it. David Hershey built the original Claude Plays Pokemon project in 2025 to study how Claude handles extremely long tasks, in which Sonnet 3.7 once fainted its entire team to escape Mt. Moon, then deleted all Mt. Moon notes after respawning — a crude way of correcting a wrong note.

Anthropic's new experiment offers a better correction method: during the "dream" phase between sessions, Claude checked its notes against the session transcript, found the error, and rewrote it. With the corrected notes, it re-entered Mt. Moon and reached Cerulean City. Runs using uncorrected notes or no memory at all failed to get past the mountain.

Mechanically, "dreaming" is extra model work that runs while the agent is idle. "Sleep" is just a name; the idea comes from Letta and UC Berkeley's Sleep Time Compute paper. Anthropic's version reads logs, corrects errors, then writes notes, builds the encyclopedia layer, and selects what to load for the next session. Most of the work is about keeping the desk tidy.

Sleep Time Compute is a concept proposed by Letta and UC Berkeley in a paper, referring to allocating extra computational resources during an agent's idle periods (during "sleep") to organize memory, reflect on experience, or optimize strategy. Its core assumption is that during online interaction the agent is busy handling immediate tasks and can hardly perform deep memory maintenance, whereas the offline phase can perform compression, deduplication, verification, and other operations at low cost. Anthropic's Dreams mechanism borrows this idea but focuses more on correcting wrong notes against session transcripts and reorganizing the memory store. Sleep compute is typically billed at standard token rates, so the frequency of consolidation must be weighed against cost. This paradigm is analogous to memory consolidation during human sleep and emphasizes the key role of "offline consolidation" for long-term agent performance.

How Dreams Works and Commercial Validation

Anthropic's Dreams documentation overturns a common assumption: it is not a cleanup job that edits memory in place. A single dream reads the existing memory store plus 1 to 100 past transcripts, then writes a separate, reorganized new store that merges duplicates, replaces outdated entries, and surfaces new insights. The original store is never modified, so you can review the new store or simply discard it. The documentation explains why Dreams exists: in-session memory is local and incremental, and over many sessions the store accumulates duplicates, contradictions, and outdated entries. A single dream takes minutes to hours and is billed at standard token rates — an agent's dreams really do have a bill.

Beyond gaming, Anthropic's Managed Agents announcement describes the case of legal AI company Harvey. Harvey's agent uses the Dreams mechanism to remember specific workflows and tool patterns across sessions, and in Harvey's own testing the completion rate improved by about 6x, though no setup details or baselines were published. More interesting is what gets remembered: workarounds — the things that had to be derived through reasoning.

Managed Agents is a service offered by Anthropic that allows enterprises to host long-running agents on Anthropic's infrastructure, with built-in memory management (including Dreams). Unlike a self-built Claude Code setup, Managed Agents abstracts away underlying details such as session management, memory storage, and offline consolidation, letting enterprises focus on business logic. Harvey, as a legal AI company, uses this service to let its agent remember specific tool patterns and workarounds across sessions in legal workflows, thereby improving task completion rates. The Dreams mechanism in Managed Agents is billed by token, so enterprises must pay for their agent's "dreaming" process. The service targets production environments that require persistent memory and complex workflows, rather than single-conversation scenarios.

What's Worth Writing Down: The Closed-Loop Principle and CLAUDE.md in Practice

The CLBench benchmark provides the clearest answer to "what's worth writing down." In the database tasks, each question starts from a fresh session, and only the memory folder persists across sessions. When Claude answers incorrectly, it can record the failure, propose a theory, test the theory, and turn the parts that hold up into rules. Anthropic calls this a "closed loop." Opus 5 was the first model to complete the loop, saving a rule along with how it knew the rule was true. Sonnet 4.6 stored untested guesses, while Opus and Sonnet 5.5 also completed the loop, reaching a level comparable to Opus 5 thanks to memory. Write down what you derived, and how you know it's true. Saving a guess as a fact is just another "Mt. Moon completed" waiting to be loaded.

Anthropic also found a counterintuitive phenomenon: on CLBench, simply telling Claude that a memory folder was available gave Opus 4.7 and Opus 5 a significant boost. Yet a fixed rule — record only failures — cost both models most of that gain. Tell the agent what memory is for, and leave how to do it to the agent itself.

Based on these findings, the practical recommendations today are clear. Keep your CLAUDE.md under 200 lines and cut anything the agent can look up directly in the repository. The agent re-reads that file every turn, so short is cheap and long is expensive. Users also find that their own rules contradict each other, making it impossible to tell which one is in effect. Let the agent write its own notes — auto-memory in Claude Code, the Dreams mechanism in Managed Agents — and occasionally review the top-level content yourself. The documentation says that the more specific and concise the instructions, the more consistently Claude follows them.

For projects with mountains of memory files, look back at the comparison between the two Claudes: the Claude with 413 files had memory to spare yet still fell behind, while the Claude maintaining a short dashboard knew its goals, plan, and rules. Good agent memory is small, curated, and rewritten between sessions. If you're using a verbose CLAUDE.md on Claude Code, trim it before installing any plugin.

CLBench is a benchmark for evaluating an agent's long-term memory capabilities, whose database tasks are designed so that each question starts from a fresh session and only the memory folder persists across sessions. This setup forces the agent to rely on memory to accumulate knowledge rather than on in-session context. In the test, after answering incorrectly the agent can record the failure, propose a theory, test the theory, and write verified rules into memory, forming a "closed loop." The key metric of CLBench is whether the agent can distinguish verified rules from untested guesses and save only the former. Through this benchmark, Anthropic found that merely informing the agent that a memory folder exists significantly improves performance, while enforcing fixed rules is actually harmful. CLBench provides reproducible quantitative evidence for designing memory strategies.

One-line Summary

Anthropic's experiment reveals that agent memory should be small and refined, with the four-layer architecture and Dreams offline correction mechanism being key.

Paragraph Summary

Anthropic's Pokemon Red experiment found that a Claude saving 413 memory files earned only 1 badge, while a Claude maintaining a short dashboard earned 4, proving that it's not how much you remember but how well. The article proposes a four-layer memory architecture (transcripts, memory notes, memory representations, injected context) and emphasizes that top-level injected content consumes tokens every session and errors get repeatedly loaded. Dreams, an offline correction mechanism between sessions, checks and rewrites wrong notes against transcripts, writing to a separate new store rather than modifying in place, and is billed by token. The closed-loop principle requires saving derived rules and how they were verified, not untested guesses. Practical recommendations include keeping CLAUDE.md under 200 lines, cutting lookup-able material, and telling the agent what memory is for rather than fixing record rules.