Anthropic's Agent Memory Architecture: Four Layers, Dreaming and a 413-File Failure (Nov 2026)

What did Anthropic publish?

On November 6, 2026, Anthropic published The components of agent memory, a research post by Lance Martin about how Claude carries knowledge from one session into the next. It is not a product announcement. It describes a memory stack already running inside Claude Code, and it spends about as much space on what goes wrong as on the design.

The post sets a boundary first. Three things get called memory and are not: the weights a model was trained on, the in-context learning that happens inside one conversation, and compaction, the summarizer that keeps a long session inside its context window. Agent memory, as Anthropic defines it, is knowledge the agent decides to write down during real work and reads back later, in a different session, on its own.

A note is a bet that something will matter again, placed before you know what comes next.

Why did writing everything down make Claude worse at Pokemon?

Anthropic compared two runs of Pokemon Red at about 10,000 steps.

Sonnet 3.7 logged nearly everything. One file per wild battle, one per item picked up, one per conversation with a non-player character. By step 10,000 it had 413 memory files spread across 225 folders, and one gym badge.

Fable 5 did the opposite. Nine files in two folders, plus a single top-level file called global.md. Four badges. Opus 5.5 later kept a small folder tracking its goal and next steps, rewrote notes in place, and finished the game.

The 413-file run did not run out of room. Around step 10,000 it opened a fourth top-level memory folder and, over the next 17 steps, created six files, deleted nine others, and took no action in the game at all. The agent was reorganizing notes about a world that had already moved on.

Notes about a live environment decay while you write them, and every stale note competes for attention with what is on the screen now. Memory is not a free asset.

How did one wrong note break three runs in a row?

Waste is the mild failure. The serious one is a note that is simply wrong, because it outlives the session that wrote it.

In Pokemon Red, Mt. Moon has one-way ledges. Claude recorded that the Pokemon Center sat east of the cave. After walking out, it treated the note as settled, decided the cave was finished, marked it done, and stepped off a ledge that drops you back at the entrance.

Its navigation tool could not see the height difference, so it concluded it had overshot far to the west and wrote that conclusion down with more confidence than before. New sessions inherited both errors. Anthropic reports three separate runs going over the same ledge. One ended with Claude writing that it would stop rather than keep looping, walking on to Pewter City, and never reaching Cerulean City. The run whose memory had been corrected went straight back into the cave and got there.

A single bad line, and every later session starts from it without checking.

What separates a fact worth keeping from noise?

Anthropic splits the world into things that change and things that hold, which is a more useful test than "is this important".

Ephemeral facts change constantly: which tile an NPC stands on, how many potions are left, what the page looked like a moment ago. Re-reading them is cheap, storing them is cheap too, and the stored copy is wrong the moment it is written. Pulling a stale coordinate out of a memory store is worse than looking at the screen again.

Latent rules do not show up in a single frame. Never jump the ledge on the right after leaving this cave. Take the lock before a concurrent API call. This class of error means an environment variable is missing. Those come out of repeated attempts across sessions, including the attempts that failed.

Only the second category belongs in long-term memory. The first category is worth re-observing.

Should you write rules that limit what the model may record?

Plenty of teams try. A prompt saying "never record coordinates" or "only record failures" feels like quality control, and CL-Bench, Anthropic's benchmark for long-horizon memory, says it backfires on strong models.

Under the instruction to record only failures, both Opus 5 and Opus 4.7 lost much of the boost that memory had been giving them. The models followed the rule and stopped writing down what they would have needed.

The other direction is more interesting. Telling Sonnet 4.6 to read its memory first and then test the theories it found nearly doubled its benchmark score. Sonnet 5 read memory before answering 9 times out of 10 with no instruction at all. Simply telling Claude that a memory folder existed lifted Opus 4.7 and Opus 5.

Stronger models judge salience better than a hand-written list of allowed topics. What the architecture owes them is a safe place to write, a way to correct it later, and a clear statement of what memory is for.

What are the four layers?

The stack runs from a full log at the bottom to a thin index at the top. It is not one vector database with a prompt bolted on.

Transcripts. The complete record: conversation turns, tool calls with their arguments, results, feedback from the environment. Lossless, searchable by keyword and by full text, never summarized away. When everything built on top of it turns out to be wrong, this is the file you return to.

Memory notes. What the agent writes during a run when something looks salient. Short Markdown notes about one task's lessons, often with a tag and a date.

Memory representations. Wikis and similar structures. Rather than letting notes accumulate, an offline pass merges duplicates, abstracts whatever keeps repeating, and cross-links pages into a map an agent can navigate.

Injected context. A few lines loaded at session start. It says which areas the agent has knowledge about and where the detail lives, and it carries almost no detail itself.

Anthropic measured what the third layer is worth on Stainless, a real codebase of about 350,000 files, roughly 420M tokens, evaluated on 25 questions. Dreaming built the wiki across 128 sessions. Scaling that from two sessions to 128 moved the share of graded criteria met from 13% to 48%. Search alone scored 53%. Search plus wiki rose from 54% to 61% as the wiki grew, and saved about 20,000 tokens per question.

The wiki did not win on its own. It helped when paired with search, and on a task where each answer lived in a single document, the post says the wiki showed no clear gain. On another task the wiki grew larger than the source documents it was meant to compress.

What is dreaming?

Dreaming is compute spent while nothing is asking the agent anything. The name comes from sleep research: the hippocampus replays the day's experience during slow-wave and REM sleep, trims noise, and writes what survives into longer-term storage.

In an agent, the offline pass reads logs and notes together and looks for disagreement. It can rewrite a note against the transcript, promote something that keeps mattering, merge two pages describing the same thing, or find links pointing at pages nobody ever created.

The Mt. Moon correction is the clean example. Dreaming compared the note with the movement log, saw that the recorded path went east and fell, and replaced the note with an instruction to go back into the cave and head north. The corrected run reached Cerulean City and the uncorrected ones did not.

It also does structural repair. In Anthropic's contract analysis test, the first pass produced a brief covering 41 of the 57 facts that mattered, 72%. Several agents had overwritten a shared table and paraphrased the terms loosely. The fix was procedural: one page per contract, one agent per contract, terms quoted word for word. That brief met 100% of the criteria. A later dreaming pass found nine links pointing at a missing page, repointed them, and added three new pages including an index.

Dreaming output is not available to the session that is running now, and the compute is not free.

How does Claude Code keep the injected layer small?

Claude Code loads only the first 200 lines or 25 KB of MEMORY.md when a session starts. The rest of the memory directory waits on disk.

That header is an index. It tells the model which areas it holds knowledge about and where the files sit. When a task needs a specific rule, the agent searches the lower layer or reads it then.

Anthropic gives two reasons. Injected memory is billed as context on every turn, and a longer instruction file measurably reduces how well the model follows it. A long memory block that happens to contain the answer can be worth less than a short index that reliably points at it.

Where does this get hard in production?

Three tradeoffs, all of them about compute.

When to write. Capturing a notable event on the spot keeps the detail, but the act of writing competes with the task for context. Writing offline keeps the session clean and delivers nothing until later.

How to stay fresh. Memory drifts, because notes outlive the conditions that made them true. Dreaming can correct them, but checking constantly costs as much as it saves, so you need a cadence and a target list: memories likely to change, and memories that have already been read once and contradicted.

How much representation to build. Transcript search is a solid floor and needs no maintenance. Wikis help when combined with search, but they need compute to stay accurate, and an unmaintained wiki becomes one more layer of confident errors.

What can you take from this?

Anthropic's numbers come from Anthropic's tasks. A few design choices transfer anyway, and we would file these as design advice rather than measured results:

• Keep the raw log verbatim. Every summary above it is a cache, and it should point back at the original rather than replace it.
• Store logs, notes and synthesized pages as separate things. They have different lifetimes and they fail in different ways.
• Inject a small index and let the model fetch detail itself. Do not load the whole memory directory into the prompt and hope.
• Schedule the correction pass and give it real compute. An agent that never revisits its notes keeps its first mistake forever.
• Track staleness the way you track cost: last verified date, times read, times contradicted. The number of notes is not a health metric.

If your sessions last five turns and start from nothing, none of this pays for itself. The design assumes a task that runs for thousands of steps against a world that changes underneath it.