Agent Memory Isn't Better When There's More of It: Anthropic on Notes, Salience, and Dreaming

On November 6, 2026, Anthropic published a research post on its official blog, "The components of agent memory," about a problem every vibe-coding developer runs into sooner or later: when you give an agent memory, what should it remember, when should it write things down, and what do you do when it remembers something wrong? The post announces no new product and open-sources no new tool. What makes it worth reading is the experiments and the numbers — Anthropic let Claude write its own memories during long-horizon tasks, judge for itself what was worth keeping, and then "dream" offline, replaying logs to fix mistakes, and published the score for every step of the process.

The conclusion, in one sentence: more agent memory is not better memory. A model that wrote 413 memory files earned one badge; a model that wrote nine earned four. Giving a strong model rigid rules made it worse. And the step that actually made memory better was the offline reorganization — the step Anthropic calls "dreaming." This article breaks down all three findings.

1. First, the boundary: this is not another October memory article

This site already published four memory-themed pieces in October, so it is worth stating up front how this one differs, to avoid repeating ourselves.

On October 3, the agent memory debate covered a blog post by Kevin Liao arguing that memory plugins are essentially a "RAG slice lottery," which drew more than 300 comments on Hacker News — that was an argument about opinions. Later that month, Devin learned to "dream" described Cognition's open standard for agent memory, turning memory into files and conventions inside a repo — an engineering standard. Tencent's Hunyuan Hy Memory 2.0 was a product story: an open-source 30B model built to decide "what an AI should remember," plus a memory hub connecting ten tools. And our guide Agent Memory System Design laid out a three-layer architecture and how to clean up memory pollution — a design manual.

Anthropic's post, published November 6, is a new research article with fresh experiments and data disclosed for the first time. It does not argue about plugins, ship a product, or hand out an architecture diagram. It answers a more basic question: what are the components of memory itself, and how much does each one actually contribute? The debate was about whether to remember; this post is about how remembering works. The two complement each other. If you only want the practical takeaways for your own agent, skip to section eight; if you want to know where they come from, keep reading.

2. What "agent memory" means: three things it is not

Anthropic starts by defining "agent memory" narrowly: knowledge Claude gains from experience — including interactions with users and tasks it has been assigned — that it retains between sessions, saved as context it can read later. The definition deliberately excludes three other things, and the experiments only make sense once those are clear.

First, it is not weight updates. Adjusting a model's internal parameters during training is learning, not memory. Second, it is not in-context learning within a single conversation. What a model picks up on the fly in one session and loses when the window closes does not count. Third, it is not compaction summaries — the summaries Claude writes to replace its older turns so it can keep working in a new context window. That is context management, not memory across sessions.

What remains is the memory this post is about: experience-based knowledge that persists between sessions. Anthropic borrows the division of labor from the human brain: the hippocampus captures experiences quickly as they happen, and only some of them get consolidated into long-term knowledge while we sleep. Agents work the same way — writing "memory notes" to mark salient events during a session, then "dreaming" offline, replaying logs to fix mistakes and build new representations. The whole post follows those two moves: when to write notes, what to write, and how much work the offline step can actually do.

3. Memory is a prediction: the CL-Bench closed loop

One idea in the post deserves to be pulled out first: memory is, occasionally, a prediction. When an agent writes down a rule, it predicts that the pattern it describes will matter again. When it writes down a verified fact, it predicts that a future session will want to rely on that fact without double-checking it. When the prediction is right, memory is an asset; when it is wrong, memory is garbage. That test runs through every experiment that follows.

The first experiment used Continual Learning Bench (CL-Bench) 1.0, a benchmark for an agent's ability to use memory on long-horizon tasks. One task asks Claude to answer a series of questions by looking up information in a database. After each answer it is told the correct solution, and it can write a memory to help with future questions. The ideal learning loop goes like this: get a question wrong, record the failure, come up with theories about what went wrong, test those theories, and turn what holds up into a rule.

Different models got to very different points in that loop. Claude Sonnet 4.6 only reached the "generate theories" stage: its memory directory held a scattering of files, each listing several untested guesses. Claude Opus 4.7 went further, consolidating its notes into a single reference document and starting to mark which facts it had checked and which were still unconfirmed. Claude Sonnet 5 went further still, marking each answer as confirmed after the grader had checked it, and writing a correction when it had answered wrong.

Claude Opus 5 was the first to close the loop. Most of its entries included a rule, how it knew the rule was true, answers to earlier questions, and clear warnings about traps it had discovered along the way. Claude Opus 5.5 and Claude Sonnet 5.5 closed the loop too, using memory to capture validated rules about how to answer future questions; with memory, both scored about the same as Opus 5, though their baselines without memory were slightly higher.

Two lessons come out of this. First, writing memory is not the hard part — verification is. The gap between a guess and a rule is one round of hands-on testing. Second, the stronger the model, the more likely it is to run the loop on its own; weaker models do not fail to write memories, they fail to verify them and to look back at them. For developers, that means the first quality bar for a memory system is not how much it stores, but whether every entry records how it was verified.

4. How much to remember: 413 files vs. 9 files in Pokémon Red

The second experiment is the most vivid, and the most striking. Anthropic had Claude play Pokémon Red to test its judgment about what to save to memory. Each model started with a folder of memory files it could read from and write to while it played. At about 10,000 steps into the game, the researchers compared the folders from one run each of Claude Sonnet 3.7 and Claude Fable 5.

Sonnet 3.7 assumed everything might matter and wrote to memory indiscriminately. Its folder was an archive of encounters: a separate file for each battle it fought, each item it found, and each non-player character it met. In the end it wrote 413 memory files across 225 folders and earned one badge — badges mark progress through the game.

Fable 5 wrote nine files in two folders, plus a single top-level file called global.md, and earned four badges.

The problem was not just the file count. The game state changes constantly, so Sonnet 3.7's detailed record was continuously going out of date. As it played on, it spent more and more time combing through its memories rather than playing the game. Around step 10,000, it started its fourth folder of "master" memory files; over the next 17 steps, it created six files, deleted nine others, and took no actions in the game itself. Memory had turned from a helper into a burden.

Fable 5 split things differently: it did not store anything it could read off the screen every turn — how much money the player has, where the player is on the map — because storing that is redundant. It stored only what would disappear unless written down: strategy, plans, and tested rules. Its global.md acted as a dashboard, holding the current goal, a prewritten plan for tackling gyms, and the model's own rules for using memory. A locations folder held plans for navigating particular routes, and a gameplay folder held strategies based on what it had learned about how the game works. After seven Poké Balls in a row failed to catch a Magikarp — one of the easiest Pokémon to catch — it wrote: "If 3+ balls fail in a row, VARY the timing (insert extra 'wait' presses between menu steps) — the catch landed right after doing this."

Opus 5.5 took a similar approach: it kept a small folder of memory notes tracking its current goal and next steps, rewrote them as it played, and beat the game.

This is a practical screening rule for developers: the first test for a memory is not "is it important?" but "will it be lost if I don't write it down?" State you can re-read from the environment any time does not belong in memory; only strategies, plans, and verified rules the model worked out itself are worth a file. 413 files is not diligence — it is a failure to choose.

5. Don't give strong models rigid rules: what the steering experiments showed

Once you know what to remember, the next question is whether to tell the model how to remember it. Anthropic's answer splits in two — it is completely different for strong and weak models.

On CL-Bench, they started by simply telling Claude that a memory folder was available, with no specific rules. That general guidance was enough for Opus 4.7 and Opus 5 to use memory effectively, and it gave both a noticeable performance boost. Then they tested adding specific rules, one per test, and compared how much each model gained from memory with each rule against how much it gained without one.

The result: setting a rule to "record only failures" cost both Opus 5 and Opus 4.7 much of the performance boost that memory had given them. For stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance — and those rules could end up weakening performance. Anthropic's standard practice reflects this: with frontier Claude models, they give simple guidance to create memory notes when a person asks for them or when something is clearly worth remembering, and leave that judgment up to Claude.

But steering helped older models the most. Sonnet 4.6 often didn't read files from its memory directory and failed to test its theories about why an answer was wrong. Prompting it to read its memory files before answering — and then to explicitly test its theories — nearly doubled its benchmark score. Sonnet 5 does this on its own: without being prompted, it read its memory before answering 9 out of 10 times. Sonnet 4.6 did this less than half of the time.

That is a directly usable dividing line for real development: the stronger the model, the looser the guidance should be — say what memory is for, not how to use it. The weaker the model, the more explicit the operating steps need to be: read first, then verify. Using the same prompt for every model wastes the difference.

6. What dreaming is for: correcting mistakes, building wikis, layering memory

Notes written in-session have a built-in flaw: at the moment of writing, the model only sees the current session. It does not know what comes next, or whether what it just wrote is wrong. A note that is wrong from the start can be read and trusted by a later session. Dreaming plugs that hole: replay the original transcripts offline and check the notes against them.

The most vivid example is back in Pokémon Red. To get through Mt. Moon, a cave system with its entrance on the west side of the map and its exit on the east, the player must avoid a trap near the entrance: a one-way ledge that drops the player onto the route they came from, with no clear way to climb back up. Claude was using the PokéCenter, a building at the mountain's entrance, as a landmark, so whether it walked off the ledge depended on which side of the mountain it thought the PokéCenter was on. At one point it wrote down, incorrectly, that the PokéCenter was on the east side. Walking out of the PokéCenter, it announced, "Mt Moon is behind me," and updated its notes: "Mt Moon DONE." But Mt. Moon was not behind it. A few actions later it went over the ledge and landed back on the route it had come from. Its navigation tool didn't show the drop, so it concluded, "I overshot far west," and that it had been on the correct side all along. It hadn't.

The researchers then ran dreaming on the memory folder containing the wrong PokéCenter location: Claude checked the note against the session transcript, caught its error, and rewrote it. With the corrected memory note, it went straight back into Mt. Moon and eventually reached Cerulean City. In the run with the uncorrected note, Claude dropped back onto that earlier route three times. After the third failure it wrote, "I'm going to stop rather than keep looping." The setup's automatic reply instructed it to continue, so it did — all the way back to Pewter City, the town before the mountain, where it hoped to heal and restock. The run ended without Claude ever reaching Cerulean City. The difference between one wrong note and one corrected note was the difference between finishing and going in circles.

Dreaming's second skill is building new representations. Anthropic uses "wikis": collections of pages written and maintained by Claude that gather what it knows about one subject and link it to other notes — effectively a map for sifting through memory. They tested wikis on a corpus of internal documents from Stainless, a software company Anthropic acquired in May: about 350,000 files, roughly 420M tokens. They wrote 25 questions about the corpus, gave Claude a search tool, and instructed it to build a wiki using dreaming. Over 128 sessions, Opus 5 agents explored the files, wrote or corrected linked wiki pages, merged duplicates, and checked claims against the sources. Scaling dreaming from two sessions to 128, performance on the 25 questions grew from 13% to 48% of graded criteria.

Wikis helped most when combined with search. Answering from the wiki alone, Claude's best score was 48%; with the search tool alone, 53%. Using both, the aggregate score rose from 54% to 61% as the wiki grew, and it saved about 20,000 tokens per question. On a separate set of 24 questions about a merger — more than half needing information across several documents, plus judgment or math — Claude scored 87% consulting the wiki, compared with 73% using search alone. A wiki is not a replacement for search; it is a map for search.

Dreaming can also float notes up the memory hierarchy. Promoted memories are preemptively loaded into Claude's context at the start of every session, so Claude doesn't need to search for them, or even know there is something to search for. But injection must be done carefully: injected memories use up valuable tokens, an incorrect note gets carried into every session, and loading a note doesn't guarantee Claude acts on it — Claude Code's documentation warns that longer instruction files reduce adherence. So the top layer of the hierarchy has to stay relatively small, and much of dreaming's work is keeping it that way, moving details down and leaving links behind. Claude Code's auto memory works the same way: it doesn't load all of its auto memory into every session, only the first 200 lines or 25 KB of MEMORY.md. That header serves as an index, showing Claude what it knows and where to find it.

Dreaming can also shape memory around a specific goal. In another test using the Harvey LAB benchmark plus a set of merger documents, Claude had to generate a legal brief. The first wiki-building instructions didn't say how the wiki would be used, and several agents wrote contract terms into a shared table at the same time, overwriting one another's work. The resulting wiki was missing key facts: a brief generated from it included only 41 of 57 facts (72%). The researchers ran a loop in which Claude reflected on its failures, proposed a change to the instructions, and rebuilt the wiki: each contract got its own page, written by a single agent, quoting the terms word for word rather than summarizing them into a shared table. The brief generated from the improved wiki met 100% of the criteria, up from 72%. Dreaming doesn't just organize memory — it can discover that the instructions themselves were wrong.

Finally, dreaming can fill in gaps a session leaves behind. When building wikis, Claude sometimes links to pages that haven't been created yet; a second dreaming pass closes many of these gaps. On one task, dreaming found nine links to a missing page and repointed them to an existing page for the same document, and added three new pages, including an index.

7. Wikis can spiral out of control: the map as big as the empire

But the post doesn't only report good news. Wikis can spiral out of control, and the way they fail is worth remembering.

On one LAB task, the wiki grew larger than the documents themselves. Anthropic cites Borges's one-paragraph story "On Exactitude in Science," in which mapmakers draft a map so detailed it is as large as the empire it represents. Claude had made an extremely detailed wiki that effectively abstracted nothing. A map the size of the territory is no use as a map.

On another LAB task, the brief criteria could mostly be retrieved with a text search from a single document, and the wiki showed no clear gain over search. Wikis are not a cure-all: when the information is already concentrated and one search can hit it, building a wiki is wasted compute. The map only pays off when information is scattered across many places and has to be pieced together. Dreaming costs compute, and what is worth dreaming about — and how often — has to be tuned to how often memories are accessed and how likely they are to change. Anthropic admits in the closing section that this is something they are still working out.

8. Three takeaways for vibe-coding developers

The post sits close to engineering, and three conclusions can be carried straight into practice.

First, remember less, and remember rules. The first screening test for a memory folder is "will this be lost if I don't write it down?" Don't store state you can re-read from the environment at any time. Store only strategies, plans, and verified rules the model worked out itself — and, like Opus 5, write them as rule plus how it was verified plus warnings about traps, not as a pile of untested guesses like Sonnet 4.6. Fewer files is not laziness; it is choosing.

Second, tailor the guidance to the model. Give strong models the goal, not rigid rules — a hard rule like "record only failures" eats their memory gains. Give weaker models explicit operating steps: "read memory first, then test your theory" nearly doubled Sonnet 4.6's score. Prompts are not better the more detailed they are; it depends on whether the model reads and verifies on its own.

Third, organize memory offline, and keep the top layer small. Notes written in-session will be wrong and will go stale, so there has to be an offline channel for correction: replay against the original records and rewrite the wrong notes. What survives that process gets layered — the verified, frequently used items promoted to the top and injected up front, but the top must stay small. Claude Code loading only the first 200 lines of MEMORY.md is a ready-made reference. The rest goes below, with links, to be fetched when needed.

There is also an implicit reminder: tune the memory system to the task. The contract-brief example shows that how a wiki is organized has to follow the task — when contract terms are the core, each contract gets its own page with verbatim quotes. Change the task, and the organization has to change too. No single memory structure fits everything.

9. The questions Anthropic hasn't answered yet

The post ends with a list of open questions, honestly stated and worth pulling out on their own.

When should Claude create memory? Writing in-session captures salience at the source and makes details immediately available, but it draws attention away from the main task. Pushing memory creation to dreaming saves that attention, but its outputs may not be immediately accessible. How do you keep memory reliably up to date? Models write rules that are wrong from the start, and memory drifts as the environment changes. Dreaming can fix mistakes, but continuously checking all memories may not be practical — it may matter more to focus dreaming on information likely to change, or to tune its cadence based on how often memories are accessed. And there is a more basic idea: maybe transcript search is the foundation of memory, with representations like wikis built on top of it — but representations cost compute to maintain and can accumulate errors or hallucinations.

None of these questions has an answer yet. Anthropic's own words are that they "still have a lot to learn about designing Claude's memory systems." But that is exactly where the value of this post lies: it breaks memory into components that can be tested and scored one by one — notes, salience judgment, dreaming, representations, layering — instead of treating it as one mysterious whole. Developers building agent memory now have a checklist to tune against: what to remember, how to remember it, what to do when it's wrong, and when to reorganize, each backed by experimental numbers.

For vibe-coding, this post matters more than another round of debate. A debate tells you where other people went wrong; this post tells you what to do yourself: remember less, remember rules, organize offline. An agent doesn't forget because it has a bad memory — it forgets because nobody taught it what is worth remembering. Now Anthropic has published the syllabus and the exam results together.

Primary source: Anthropic's official research blog, "The components of agent memory," published November 6, 2026 (the page's Additional Details section lists Published: 2026-11-06T00:00:00.000Z, Updated: 2026-11-06T21:15:32.000Z). All experiment figures and quotations in this article come from that post; for how it relates to this site's October memory articles, see section one.