Picture an agent you gave a memory folder a few weeks ago. The notes pile up, and one day it acts confidently on a note that was wrong from the moment it was written. Nothing in the session tells it so. That situation runs through The components of agent memory, an engineering post Anthropic published on November 6, 2026, written by Lance Martin. My read after going through it: getting an agent to write memory is easy. Getting it to write the right things, and to have a way of catching the wrong ones, is the actual work. Each number below belongs to the specific evaluation it came from, and I'll try to keep that scope visible.
Anthropic draws the boundary narrowly. Agent memory here means knowledge Claude gains from experience and keeps between sessions as context it can read later. Weight updates, in-context learning within one conversation, and compaction, where summaries replace older turns, are all out of scope. Inside that boundary the post covers several parts: notes taken during a session, an offline pass over logs to reorganize them, wikis of linked pages that organize knowledge, and a small set of notes injected at the start of every session. Anthropic calls the offline pass dreaming, by analogy with how sleep consolidates human memory, and connects it to sleep-time compute, the idea from researchers at Letta and UC Berkeley of using idle time between interactions to reorganize context.
In Pokémon, the run that saved less and saved better went further
The first comparison comes from Pokémon Red, with one run per model. Anthropic looked at the memory folders of Claude Sonnet 3.7 and Claude Fable 5 when each was about 10,000 steps into the game. Sonnet 3.7 wrote almost everything down, often giving each battle, item and character its own file; by Anthropic's count it wrote 413 memory files across 225 folders and earned one badge. Fable 5 wrote nine files in two folders plus a single top-level global.md, and earned four badges.
Anthropic's explanation is that Pokémon's state keeps changing, so Sonnet 3.7's detailed records kept going stale and it spent more and more time combing through them. Around step 10,000 it started its fourth folder of "master" memory files, then spent the next 17 steps creating six files and deleting nine without taking a single action in the game. Fable 5 used memory for what the game didn't tell it. Money and map position can be read off the screen every turn, so storing them is redundant; strategy, plans and tested rules exist only if the model works them out and disappear unless it writes them down. In a separate run, Claude Opus 5.5 kept a similarly small folder tracking its current goal and next steps, rewrote it as it played, and beat the game.
Two runs don't make a law, but they suggest a trade-off you can test on your own agents. Copying state the environment already exposes into memory just creates another copy to keep current. The conclusions the agent paid to reach are the better candidates for saving.
On this Q&A task, Opus 4.7 and Opus 5 needed only the purpose, and a fixed rule hurt
The second set of experiments used a database question task from Continual Learning Bench 1.0. Every question started in a fresh session, and the only thing that carried over was a memory directory. After each answer Claude was told the correct solution and could write notes for later. The ideal use is a learning loop: record the miss, propose why, test the theory, and turn the result into a rule.
The models got to different points on that loop. Sonnet 4.6 stopped at generating theories and left a scatter of files full of untested guesses. Opus 4.7 merged its notes into one reference document and started marking which facts it had checked. Sonnet 5 marked answers as confirmed once graded and wrote corrections when it was wrong. Anthropic says Opus 5 was the first of these models to close the loop: most entries held a rule, how it knew the rule was true, and warnings about traps. Opus 5.5 and Sonnet 5.5 closed it too and scored about the same as Opus 5 with memory, though their baselines without memory were slightly higher.
The steering results cut against intuition, and they also come from this one task. Simply telling Opus 4.7 and Opus 5 that a memory folder existed was enough, and both got a noticeable boost from it. Anthropic tested specific rules about what to save, one per test, and the one it reports is "record only failures": with it, Opus 5 and Opus 4.7 lost much of the boost memory had given them. Sonnet 4.6 went the other way. Prompting it to read its memory before answering and to test its theories nearly doubled its score. On this task Sonnet 5 read its memory before answering 9 times out of 10 unprompted, while Sonnet 4.6 did so less than half the time.
These results describe a handful of Claude models on one database Q&A task, and Anthropic's own summary goes only as far as saying that for stronger models, letting them judge what's worth saving worked better than fixed rules set in advance. Other models and other tasks may behave differently. The practical advice I'd take from it is narrower: don't assume one set of memory instructions suits every model, and when you switch models, test both a purpose-only prompt and an explicit "read before you answer, verify before you write" prompt.
The wrong note in Pokémon was fixed by checking it against the session transcript
However good the judgment, a note is a guess about what the future will need. It can be wrong from the start or drift as the world changes, and the next session will trust it anyway. Anthropic's example comes from a Pokémon run on Managed Agents with a mounted memory directory, at Mt. Moon: a cave with its entrance on the west and its exit on the east, and a one-way ledge near the entrance that drops you back onto the route you came from. Claude used the PokéCenter by the entrance as a landmark but wrote down that it was on the east side. Walking out, it announced "Mt Moon is behind me" and updated its notes to "Mt Moon DONE." A few actions later it went over the ledge, its navigation tool didn't show the drop, and it decided it had simply "overshot far west."
In the run with the uncorrected note, Claude fell back onto the old route three times. After the third, it wrote that it would stop rather than keep looping; the setup's automatic reply told it to continue, and it retreated all the way to Pewter City without ever reaching Cerulean City. Anthropic then ran dreaming on the memory folder with the bad note. Claude compared the note with the session transcript, caught the error and rewrote it. With the corrected note it went straight back into Mt. Moon and eventually reached Cerulean City. In this case, the transcript gave the note something factual to be checked against.
The feature is already in Anthropic's product docs, as a research preview. According to the Managed Agents dreams documentation, a dream reads an existing memory store plus 1 to 100 past sessions and writes a new store, leaving the input untouched so you can review the output and discard it. It is billed at standard token rates for the chosen model. The memory store documentation flags a different way memory goes bad: stores attach read-write by default, so if an agent handles untrusted input, a prompt injection can be written into memory and read by later sessions as trusted. The docs recommend read-only access for reference material and any store the agent doesn't need to modify.
Project EVE, which Anthropic published the same day, is a separate study by its Frontier Red Team on trading and multi-agent teamwork in the EVE games, not a memory study. One failure it documents is still worth keeping in view. When Claude teams in EVE Frontier skipped a check, they made some of their costliest mistakes, such as believing a scarce resource had already been secured or acting on intel that was out of date. That parallel is my reading, not Anthropic's claim, and the two studies use different setups and measures, so their numbers don't support each other.
Wikis helped on questions that span documents and showed no clear gain on a single-document task
A wiki here is a set of linked pages that Claude writes and maintains itself. Anthropic first tested wikis on internal documents from Stainless, a software company it acquired in May: about 350,000 files and roughly 420 million tokens, with 25 evaluation questions and a search tool. Over 128 sessions, Opus 5 agents explored the files, wrote and corrected linked pages, merged duplicates and checked claims against the source files. As dreaming scaled from two sessions to 128, scores on those 25 questions rose from 13% to 48% of graded criteria; separately, the post says Claude's highest score using only the wiki was 48%. With search and the wiki together, the score rose from 54% to 61% as the wiki grew, against 53% for search alone. The post also says search plus the wiki saved about 20,000 tokens per question, without spelling out the comparison.
To see which tasks benefit, Anthropic used two more sets of material: a collection of merger documents with a set of questions, and Harvey's LAB benchmark, which has Claude write legal briefs from a set of documents and grades them against a checklist. The merger test had 24 questions, more than half needing information from several documents and many also needing judgment or math. The 87% versus 73% figure applies only to those items, marked by the red and orange lines in Anthropic's chart: 87% with the wiki, 73% with search alone. It is not a score for all 24 questions. LAB is a different story. On one LAB task where most criteria could be met from a single document, the wiki showed no clear gain over search. On another, the wiki grew larger than the documents it was built from and abstracted nothing.
How the wiki is written also decides what it loses. One LAB task simulates a company acquisition, supplies a set of contracts, and grades the brief on whether it describes the contract terms correctly. At first several agents wrote into one shared table of contract terms at once, overwrote each other and summarized poorly, and the brief generated from that wiki included 41 of 57 graded facts, or 72%. Anthropic ran a loop in which Claude reflected on the failures, revised the wiki-building instructions and rebuilt the wiki, ending with one agent per contract writing its own page and quoting terms word for word. With the brief generated from that improved wiki, 100% of the criteria could be met; the chart caption puts it as all 57 facts surviving.
These results cover only the documents and tasks Anthropic chose. What carries over is a way to decide. If your questions often require stitching facts from several documents, a wiki is worth trying alongside search. If answers usually sit in one document, good search may already be enough. And if several agents write to the same page, decide up front how they avoid overwriting each other.
The layer loaded into every session should stay small
The last part is promotion: moving a few notes to the top of the hierarchy so the harness loads them at the start of every session, and Claude never has to search for them. Anthropic is cautious here. Injected notes cost tokens, a wrong note rides along into every session, and loading a note doesn't mean Claude will act on it; Claude Code's own documentation warns that longer instruction files reduce adherence. So the top layer has to stay relatively small, and much of dreaming's job there is pushing detail down and leaving links behind.
Claude Code's auto memory works this way. At the start of each session it loads only the first 200 lines or first 25 KB of MEMORY.md, whichever comes first. That file is an index with one line per memory, and the details live in topic files Claude reads when needed. If a write pushes the file past the limit, the write still succeeds, but Claude Code returns an error telling Claude to rewrite the index, since anything past the limit won't load next time.
Every number above comes from Anthropic's own evaluations, which differ in task, model and scoring; the Pokémon comparison rests on one run per model, and none of it has been independently replicated. The post gives no compute cost for dreaming. Anthropic itself lists when to write memory, how often to dream, and whether transcript search should be the foundation as open questions. Treat the percentages as design directions worth testing, not as gains to expect in your own system.
If you are building memory for an agent, I'd start with four things. Give each kind of memory something it can be checked against: keep raw session transcripts for notes drawn from sessions, and go back to the source documents for wikis built from documents. Keep the always-loaded layer an index, using Claude Code's 200-line or 25 KB cap on MEMORY.md as a reference point for size. Schedule periodic checks; Anthropic suggests focusing on information likely to change, or tuning the cadence by how often memories are accessed. And for sessions that handle untrusted input, ask whether they really need to write memory, and attach it read-only if not. Memory systems more often go wrong not by remembering too little, but by keeping wrong notes that nobody goes back to check.