The four-layer memory stack, and the dreaming loop beside it: reading Anthropic's memory research
Anthropic splits agent memory into transcripts, notes, representations and injected context, and lets "dreaming" review the record offline — correcting notes, building wikis, lifting the few that belong in every session. A layer-by-layer read, with the experiment numbers, an engineering checklist, and four verified talks in English and Chinese.
In one line: memory is not a transcript you keep, it is cargo moved between four layers — the low ones are true and hard to use, the top one is easy and easy to get wrong. Dreaming is the worker that moves it while nobody is watching.
Note on figures: the diagrams here are redrawn from the article’s own data and structure; its fifteen-odd figures and screenshots are at the source linked at the end.
1. The problem: it can only see this one conversation#

Two failures of long-horizon memory arrive together. Forgetting: each session starts at zero, so last week’s decisions, traps and verified rules are gone. Swelling: to avoid that, you stuff history into the context window, which dilutes attention, raises cost, and lets stale facts argue with new ones.
Anthropic opens with Kierkegaard — life can only be understood backward, but must be lived forward — because memory design hits the same bind: the moment you write a memory you cannot know whether it will matter. The hard part is judging what is worth writing, and being able to fix it later.
The article’s definition is deliberately narrow: knowledge Claude gains from experience (interactions, assigned tasks) that it retains between sessions and can read back as context. It explicitly excludes three other things — weight changes, in-context learning within a single conversation, and compaction (summaries that replace older turns so work can continue in a new window).
2. The four-layer stack#

Stacked up, the article’s practices look like this (my synthesis — the original is organised by theme, not drawn as a stack):
| Layer | What it is | Who writes it | The constraint that matters |
|---|---|---|---|
| 1 Transcripts | session records, logs | the system, automatically | the only ground truth; dreaming checks every layer above against it |
| 2 Notes | rules, verified facts, traps found | the model, judging as it works | judgement beats fixed rules (see §4) |
| 3 Representations | wikis: pages plus links, i.e. a map | dreaming, offline | they grow, sometimes past the source itself |
| 4 Injected context | loaded at the start of every session | the harness, plus dreaming promotions | must stay small: Claude Code injects only the first 200 lines / 25 KB of MEMORY.md |
That fourth constraint is the most practical engineering result in the piece. Claude Code’s auto memory does not load everything into every session; it loads the head of MEMORY.md as an index — what Claude knows, and where to find it. The article also repeats a warning from their own docs: longer instruction files reduce adherence. The top layer has to stay small, and much of dreaming’s work there is keeping it that way — pushing detail down and leaving links behind.
3. Dreaming: five jobs, done offline#

The human version is sleep: the hippocampus replays recent experience offline and gradually distils it into the neocortex. The machine version borrows Letta and UC Berkeley’s sleep-time compute (arXiv 2504.13171): in the gaps between interactions, spend compute reviewing logs, correcting mistakes, and producing new notes and representations.
- Correction. The Pokémon run is the clearest case. Claude recorded the PokéCenter as being on the east side (wrong), walked out announcing “Mt Moon DONE”, and a few actions later went over a one-way ledge back onto the route it came from. Dreaming checked that note against the session transcript, caught the error and rewrote it; with the corrected note it walked straight back in and reached Cerulean City. In the uncorrected run it dropped off the ledge three times, wrote “I’m going to stop rather than keep looping”, and ended in the previous town.
- Representation. On a Stainless corpus of ~350,000 files and roughly 420M tokens, 128 sessions of dreaming wrote a wiki: graded criteria rose from 13% to 48% as sessions scaled. Wiki plus search took the aggregate from 54% to 61% (53% with search alone) and saved about 20,000 tokens per question.
- Promotion. Lift the few notes that belong in every session, so Claude need not search for them, or even know there is something to search for. The cost is equally clear: injection spends tokens, and one wrong note rides into every session.
- Focus. The same corpus, different instructions, a different wiki. In the contract-review task, a shared table of terms was overwritten by several agents at once and lost key clauses; the brief generated from that wiki covered 41 of 57 facts (72%). After Claude reflected on the failure and rewrote the instructions for how to build the wiki — one contract per page, one agent per page, terms quoted verbatim — coverage reached 100%.
- Gap filling. A session can link to pages it never created; a second dreaming pass repointed nine dangling links to an existing page and added three new pages, including an index.
Dreaming turns “a wrong memory” from unfixable into something compute can fix — billed per round, and only offline, so its output is not available to the session that is running now.
4. Five experiments, and the numbers#


CL-Bench 1.0: can it close the loop. The task is a sequence of database lookups; after each answer Claude is told the correct one and may write memory. The generational difference shows up in the shape of the memory: Sonnet 4.6 wrote a scattering of untested guesses; Opus 4.7 consolidated into one reference document and began marking which facts it had checked; Sonnet 5 marked answers confirmed only after the grader verified them, and wrote corrections when wrong; Opus 5 was the first to close the loop — most entries carried a rule, how it knew the rule held, earlier answers, and warnings about traps. Opus 5.5 and Sonnet 5.5 closed it too.
Pokémon Red: what is worth writing. From the same start, Sonnet 3.7 produced 413 memory files across 225 folders and earned one badge; Fable 5 produced nine files in two folders plus a global.md and earned four. The difference is judgement: state you can read off the screen every turn (money, position) is redundant and goes stale fast; strategy, plans and tested rules exist only if written down. Around step 10,000, Sonnet 3.7 began a fourth set of “master” files, and over the next 17 steps created six files, deleted nine, and took no action in the game.
Fixed rules weaken strong models. They tested telling the model exactly what to record. With “record only failures”, both Opus 5 and Opus 4.7 lost much of the boost memory gave them. The conclusion is counter-intuitive: for stronger models, freedom to judge beats fixed rules. Steering helped older models most — Sonnet 4.6 often did not read its memory directory at all, and prompting it to read memory and test its theories nearly doubled its score, while Sonnet 5 reads memory before answering nine times out of ten without being asked.
Representations do not always pay. On one Harvey LAB merger task, more than half of 24 questions needed cross-document search, judgement or arithmetic: 87% with the wiki, 73% with search alone. On another, criteria were retrievable from a single document and the wiki showed no gain; on a third, the wiki grew larger than the documents themselves — Borges’ map, finally in context.
5. Practical guidance, and the traps#
- Separate the four layers before writing code. Keep the immutable record and the rebuildable projections apart. When you cannot, add a storage layer before adding a model.
- Keep the injected layer small enough to be an index. The 200-line / 25 KB figure is a reasonable order of magnitude: what I know, where to look, and links downwards.
- Say what memory is for; do not dictate how to write it. On CL-Bench, “a memory folder is available” was enough for strong models; hard rules like “record only failures” removed the gain.
- Give memory something to be checked against. Dreaming can correct errors only because the transcript still exists and cannot be edited. Without it, correction becomes two summaries agreeing with each other.
- Treat promotion as a release process. A note in the injected layer enters every session; validate before it goes up, because one bad note is paid for everywhere.
- Budget the wiki. Representations inflate; cap pages and size, or let access frequency decide how much upkeep they get.
- Do the compute arithmetic. Dreaming is billed per round. Their advice: focus it on information likely to change, or tune the cadence to how often memories are read.
- Prevent write conflicts between agents. The contract failure was concrete: multiple agents editing one shared table overwrote each other. One contract per page, one writer per page, quotes verbatim — and the coverage went from 72% to 100%.
6. Four talks, verified#
The four embeds below were link-checked. If a player fails to load on your network, the titles open on YouTube.
[English | Anthropic, official · ~50 min] “Agents that remember” — an Anthropic engineer demoing a grep-able memory store for an agent, and dreaming as a background task that tidies memory between sessions. Three things to watch for: the memory store is a filesystem read and written through bash/grep; dreaming batch-processes recent transcripts between sessions; the demo lands on “your second brain is the long-term memory you share with the agent”.
[English | architecture · AI Native DevCon] “Learning while you sleep: Beyond memory to dreaming” — Lamis Mukta (Anthropic) on how context engineering grows into autonomous memory: from CLAUDE.md and progressive disclosure with Skills, to production multi-agent memory and out-of-band dreaming.
Watch for: permissions and portability are the real production problems; organisation-wide context should probably be read-only while an agent’s own scratchpad is writable; dreaming’s value is batch work away from the task, not a cleverer prompt.
[Chinese | production architecture · 14 min] 「构建生产级 Agent Memory 的系统架构」— a Chinese-language walkthrough of memory as an operational component: how writes are organised, how retrieval is served, how it is decoupled from the main loop.
[Chinese | Claude Code internals] 「自动记忆来了 - Claude Code 记忆系统详解」— a Chinese explainer of Claude Code’s layered memory: the instructions you write (CLAUDE.md) versus the notes it writes for itself (auto memory), how each is loaded, and when to use which.
7. What this changes#
The useful part of this research is not “memory = a vector database”. It is a pattern with two halves:
- Layering resolves capacity against cost: true-but-hard-to-use at the bottom, easy-but-fragile at the top, the top acting only as an index.
- Offline audit resolves correctness: since the model can only judge salience in the moment, let it reconcile against the transcript outside the moment.
- Judgement over rules: the stronger the model, the more “what to remember” belongs to it; rules are a crutch for older models.
For anyone building long-horizon agents — the “AI employee” argument — the three things worth copying are the immutable transcript layer, the small and stable injected layer, and dreaming scheduled by access frequency. The article leaves three questions open: whether memory should be written in-session (costs attention) or offline (costs availability), how to keep memory from drifting (checking everything is impractical, so focus on the volatile), and whether transcript search alone should be the foundation.
On “the model will learn to remember by itself”, the article stays sober: salience judgement has improved a lot, but no model can know what the next turn will bring.
References#
- Anthropic, The components of agent memory: https://www.anthropic.com/research/components-of-agent-memory
- Letta & UC Berkeley, sleep-time compute: https://arxiv.org/abs/2504.13171
- CL-Bench 1.0: https://continual-learning-bench.com/news/cl-bench-1-0/
- Claude Code memory docs: https://code.claude.com/docs/en/memory
- Cookbook, dreaming: https://platform.claude.com/cookbook/managed-agents-cma-dreaming-with-a-dynamic-workflow
- Knowledge wiki example: https://github.com/anthropics/claude-quickstarts/tree/main/managed-agents/knowledge-wiki