Anthropic on Agent Memory: Notes, Wikis, and Dreaming

Last week, you and Claude Code agreed: the new service uses PostgreSQL, not MongoDB, because the team already has a backup process for it. Today you open a fresh session, ask the agent to write a migration, and it calmly creates a MongoDB collection. You remind it, it fixes it. Next week, it forgets again.

That is the biggest pain of coding-agent users today: every session starts from zero, and the agent either carries no memory or carries wrong memory. On 6 November 2026, Anthropic published “The components of agent memory” by Lance Martin — the first time a major lab has systematized how agents remember across sessions, with concrete evaluation numbers. This article explains that architecture and turns it into rules you can apply right away.

What agent “memory” means

Anthropic defines it narrowly and clearly: agent memory is knowledge Claude gains from experience — interactions with users, tasks it is assigned — and retains between sessions as context it can read later.

The definition excludes three things often mistaken for memory: weight updates during training, in-context learning within a session, and compaction — the summaries Claude writes to replace older turns when the context window fills up. Memory, in this paper’s sense, is what survives between sessions, as files and text the next session can read.

The framing borrows a line from Kierkegaard: life can only be understood backward, but it must be lived forward. An agent faces the same bind — it must decide what is worth saving before it knows what the future will need. Humans handle this partly through sleep: the hippocampus replays recent experience while the brain is offline, gradually distilling it into long-term knowledge. Anthropic proposes agents do the same, building on the sleep-time compute idea from Letta and UC Berkeley. That process is called dreaming.

A four-layer memory architecture

The paper describes agent memory as four stacked layers, from raw to refined:

1. Transcripts — the event log. Everything the agent does is recorded in a searchable log. The most complete layer, and also the noisiest.
2. Memory notes. Claude writes notes about things that may matter later: decisions that were settled, rules that were verified, traps it hit. A note is a prediction — writing a rule down predicts the pattern will recur.
3. Representations — typically a wiki. A wiki is a set of pages written and maintained by Claude, each gathering what it knows about one subject and linking to other notes. The links form a map the agent can follow when it needs a memory.
4. Injected context. A small slice of memory is loaded at the start of every later session, so the agent does not need to search — or even know there is something to search for.

Dreaming is the offline pass that connects the layers: rereading transcripts to fix wrong notes, building and pruning the wiki, and deciding which facts deserve promotion to the preloaded layer.

flowchart TD
    A[Working session<br/>Transcript: event log] --> B[Memory notes<br/>Notes: decisions, rules, traps]
    B --> C[Wiki<br/>Representation: linked pages by topic]
    C --> D[Injected context<br/>Preloaded into every later session]
    D -.-> A
    E[Dreaming<br/>offline pass] -. fix wrong notes .-> B
    E -. build & prune wiki .-> C
    E -. promote facts .-> D
    A -. check against transcript .-> E

Dreaming is not a fifth layer. It is a process that runs between the layers, while the agent is not busy serving a user.

Dreaming vs. RAG vs. compaction

These three are often lumped together, but they solve different problems:

RAG answers “where to find it”, compaction “how to make room”, dreaming “what from the past is worth trusting and keeping”. Dreaming needs the transcript as ground truth: it compares notes against the raw log instead of trusting notes blindly.

Three experiments, three lessons

1. CL-Bench: notes help agents learn from mistakes

The first experiment uses a task from Continual Learning Bench (CL-Bench) 1.0: Claude answers a series of questions by looking up information in a database. After each answer it learns the correct solution and may write a memory to help answer future questions. Each question starts in a fresh session, except for a memory directory that persists across sessions. The run used Claude Managed Agents.

Results, as mean reward (without memory → with memory):

What matters is how the models used memory. Sonnet 4.6 only got as far as generating theories about why an answer was wrong, scattered across files of untested guesses. Opus 5 was the first to close the loop: each entry carried a rule, how it knew the rule was true, answers to earlier questions, and warnings about traps it had found. Opus 5.5 and Sonnet 5.5 closed the loop too.

Stronger models turn memory into a verified learning loop, not a storage bin. Weaker models gain most from explicit guidance: when prompted to read its memory before answering and then test its theories, Sonnet 4.6 rose from 0.330 to 0.641 — nearly double. Sonnet 5 did this on its own 9 times out of 10; Sonnet 4.6 did it less than half the time.

Rigid rules about what to record backfired on strong models. When Anthropic tried the rule “record only failures”, Opus 5 lost 0.234 of its gain, Opus 4.7 lost 0.150. Telling the model what memory is for helps; dictating what it must write makes it worse.

2. Pokémon Red: the more it recorded, the worse it remembered

The second experiment tested judgment about what deserves saving. Anthropic had Claude play Pokémon Red, each model with a memory folder to read and write while playing, and compared the folders of Sonnet 3.7 and Fable 5 at about 10,000 steps in.

Sonnet 3.7 recorded everything that might matter: 413 files across 225 folders — a separate file for each battle, item, and character — and earned one badge. Game state changes constantly, so the detailed record went stale fast; around step 10,000, over 17 steps it created six files, deleted nine, and took no game actions at all.

Fable 5 wrote nine files in two folders, plus a top-level global.md, and earned four badges. It skipped what the screen already showed — money, map position — because storing that is redundant, and kept only what it had to work out: strategy, plans, tested rules. Its global.md acted as a dashboard: the current goal, a plan for tackling gyms, and its own rules for using memory. Opus 5.5 took a similar approach and beat the game.

The practical lesson: memory is a filter, not a warehouse. Store what the environment does not already tell you. What can be reread from the screen, the log, or system state — do not store it.

3. A 128-session wiki: from new hire to veteran

The third experiment tested the wiki as a memory representation. Anthropic used an internal document corpus from Stainless, a company it acquired in May: about 350,000 files, roughly 420M tokens. It wrote 25 questions about the corpus, gave Claude a search tool, and asked Claude to build a wiki through dreaming. Over 128 sessions, Opus 5 agents explored files, wrote or corrected linked wiki pages, merged duplicates, and checked claims against sources.

Results, as share of graded criteria met:

A wiki alone did not beat search. But wiki plus search won, and saved about 20,000 tokens per question. The wiki grew from 103 pages and 766 links after two sessions to 222 pages and 12,893 links after 128 — like a new employee gradually becoming a veteran.

But a wiki does not always help. On 24 questions about a merger, most requiring synthesis across several documents, the wiki scored 87% against 73% for search alone. On tasks where the answer came from a single document with text search, the wiki showed no clear gain. And one wiki grew larger than its source: 10 documents of 115 KB became a 68-page, 203 KB wiki, 1.77x the corpus.

One detail matters for anyone running agents in parallel: several agents wrote to one shared table of contract terms and overwrote each other’s work, leaving only 41 of 57 facts (72%). Anthropic had Claude reflect on the failure, propose new instructions, and rebuild the wiki: each contract got its own page, written by a single agent, quoting terms word for word. This time 57 of 57 facts survived and the brief met 100% of criteria. Dreaming also patched cross-session gaps: a second pass found nine links pointing to a wiki page that did not exist, repointed them to the right page, and added three new pages, including an index.

How dreaming corrects mistakes

The most convincing part of the paper is the Mt. Moon story from Pokémon Red. The player must cross Mt. Moon, entering from the west and exiting east. Near the entrance is a trap: a one-way ledge that drops the player back onto the route they came from. Claude used the PokéCenter near the entrance as a landmark — and wrongly recorded that it was on the east side.

Every inference after that was skewed: walking out of the PokéCenter, Claude announced “Mt Moon is behind me” and updated its notes to “Mt Moon DONE”. A few actions later it fell off the ledge, back onto the old route; its navigation tool did not show the drop, so it concluded “I overshot far west” — still believing it was right. In the run with the uncorrected note, it fell back onto the earlier route three times, then gave up and walked back to Pewter City, never reaching Cerulean City.

Anthropic ran dreaming on the folder containing the wrong note: Claude checked the note against the session transcript, caught its error, and rewrote it. With the corrected note it went straight back into the cave and reached Cerulean City. The transcript is ground truth — the practical core of dreaming: a cheap background check of notes against raw logs.

Six practical rules from the numbers

These rules apply right away, even if you run no automated dreaming system:

Rule 6 has a direct consequence for Claude Code users: the injected layer must stay small, because longer instruction files reduce adherence, according to Claude Code’s own documentation cited by Anthropic. Claude Code loads only the first 200 lines or 25 KB of MEMORY.md — that part works as an index, telling Claude what it knows and where to find it, instead of stuffing all memory into every session.

Where the tools you already know fit

The four-layer architecture puts the tools this blog has covered into their right places:

• Claude-mem is a practical memory plugin for Claude Code, covering the notes layer and the preloaded layer: decisions, bugfixes, and project conventions kept across sessions.
• Auto Ontology builds a certified semantic layer between database and agent — close to the representation (wiki) layer, but for structured data.
• Headroom compresses logs and tool output on the machine before they reach the LLM, tackling the bloated-transcript problem at the base layer.
• Graphify turns a codebase into a queryable knowledge graph — another form of the wiki layer, built from code instead of transcripts.

In my view, what sets the Anthropic paper apart is that it sells no tool. It describes the mechanism that every tool above touches in part: notes, representations, preloading, and the background review pass connecting them. Once you understand the mechanism, you pick tools by the layer you are missing, instead of adding another plugin where you already have enough.

When the agent remembers wrong: fix and rollback

A wrong note is the biggest risk in agent memory: a later session trusts it and acts on it. The fix follows the dreaming mechanism:

1. Detect: when the agent repeats an old mistake or contradicts a settled decision, do not fix the behavior — check the notes. The fault usually sits in the memory-notes layer, not the model.
2. Check the transcript: open the log of the session where the decision was made. The transcript is ground truth; the note is only an interpretation.
3. Fix in place, cite the source: rewrite the note with how you know it is true and its confirmation status — the pattern Opus 5 used in CL-Bench.
4. Rollback: if you are unsure which note is right, remove the suspect note from the preloaded layer and let the agent reread the transcript when needed. No memory beats wrong memory: a wrong note loaded into every session multiplies the error.
5. Prevent: focus review passes on information that changes often, and tune the review cadence by how often notes are read — the two open suggestions Anthropic leaves at the end of the paper.

Lessons learned

1. Memory is a prediction, not storage. A good note carries evidence and confirmation status, as Opus 5 did when closing the learning loop in CL-Bench.
2. Less but right beats more but wrong. Fable 5 with 9 files and one global.md went further than Sonnet 3.7 with 413 files in 225 folders.
3. Do not hand rigid rules to strong models. Saying “a memory folder exists” is enough for Opus 4.7 and above; the “record only failures” rule cost Opus 5 0.234 of its gain. Explicit guidance really helps weak models — Sonnet 4.6 nearly doubled when prompted to read memory and test its theories.
4. A wrong note is a system bug, not a model bug. One wrong PokéCenter location sent a whole run into a three-time loop and then abandonment. The fix is checking against the transcript, not telling the agent to “remember harder”.
5. A wiki only pays off with search and on synthesis tasks. A wiki alone after 128 sessions reached 48%, below search alone (53%); together they reached 61% and saved about 20,000 tokens per question.
6. The preloaded layer must stay small and act as an index. Claude Code loads only the first 200 lines or 25 KB of MEMORY.md. Stuffing more in does not make the agent remember better — it makes it comply worse.
7. Parallel work needs one writer per page. Agents writing to one shared table overwrote each other and lost 16 of 57 facts; splitting each contract into its own page, one agent writing, quoting verbatim, reached 100%.

Verification scope

Checked on 7 November 2026 against Anthropic’s original post, “The components of agent memory”, by Lance Martin, published 6 November 2026. The CL-Bench numbers are read from the figure caption in the original post (Opus 5.5 0.655 → 0.838; Sonnet 5.5 0.644 → 0.833; Opus 5 0.564 → 0.828; Opus 4.7 0.383 → 0.700; Sonnet 5 0.306 → 0.610; Sonnet 4.6 0.330 → 0.364), cross-checked against ExplainX’s summary. The Pokémon, wiki, and dreaming details come directly from the original post.

The original post is design research, not a product announcement: Anthropic does not claim Claude Code uses dreaming, and neither does this article. The experiments ran on Claude Managed Agents; Claude Code’s auto memory (loading the first 200 lines or 25 KB of MEMORY.md) is cited in the original post as an example of the injected-context layer, not as evidence that dreaming ships in the product. The cadence and cost of dreaming remain open questions, per Anthropic itself. All numbers are Anthropic’s internal evaluations with no independent measurement; the Pokémon experiment compares one run per model. Figures like 0.655 or 20,000 tokens are measurements under Anthropic’s experimental conditions, not benchmarks or configuration values. This article reran no experiment, did not test Claude Code with dreaming, and measured no performance in the author’s own environment.