Claude's Memory Failed in Five Ways. Database Teams Know All Five.

Anthropic gave Claude a memory folder. Then it tested the folder on a benchmark, on Pokémon Red, on a 420M-token company corpus and on legal briefs. The failures in the report are old failures. Database engineers named them a long time ago. In each case, the fix is the same type of job: a job that reads the log.

On November 6, Anthropic published The components of agent memory. Lance Martin wrote it. The post defines agent memory as knowledge that Claude gets from experience and keeps between sessions. Claude keeps it as context that it can read later.

The definition excludes three things: changes to model weights, in-context learning and compaction. The post divides memory into four layers. It names the offline repair pass dreaming. The idea comes from the sleep-time compute paper by Letta and UC Berkeley.

The four layers are Anthropic's. The database names are our analogy.

The post says that memory is sometimes a prediction. When Claude writes a rule, it predicts that the rule will be relevant again. A cache entry is the same bet. You store a value because you expect a second read.

Anthropic tested this bet on a database task from CL-Bench 1.0. Each question starts in a new session. One memory directory stays between sessions. After each answer, Claude sees the correct solution.

*Gain is our arithmetic on the numbers in Anthropic's chart.

The gap is in what each model did with its notes. Sonnet 4.6 wrote guesses and did not test them. Opus 5 was the first model to close the loop. Most of its entries had a rule, the proof for the rule and a list of traps. Sonnet 5 read its memory before it answered 9 of 10 times, with no prompt. Sonnet 4.6 did this less than half of the time.

Steering had two results. A prompt that told Sonnet 4.6 to read memory first and to test its theories increased its score from 0.330 to 0.641. A fixed rule that limited notes to failures had the opposite effect on strong models. It cut the memory gain of Opus 5 by 0.234 and of Opus 4.7 by 0.150.

Anthropic gave each model a memory folder for Pokémon Red. Then it compared two folders at about step 10,000.

Sonnet 3.7 wrote a file for each battle, each item and each character it met. It also recorded money and map position. The game shows those values on the screen every turn. In database terms, it cached data that the source gives back at no cost. Then it spent effort to keep that cache current.

The cost became visible. Near step 10,000, Sonnet 3.7 started its fourth folder of "master" files. In the next 17 steps, it created six files, deleted nine files and made no move in the game.

Fable 5 stored what the screen does not show: the current goal, a plan for gyms and rules that it had tested. After seven Poké Balls failed on a Magikarp, it wrote a rule: after three misses in a row, change the timing. Opus 5.5 used the same method. It kept a small folder with the goal and the next steps, and it beat the game.

Mt. Moon is a cave. The entrance is on the west side and the exit is on the east side. Near the entrance there is a one-way ledge. The ledge drops the player back onto the earlier route.

Claude used the PokéCenter at the entrance as a landmark. It wrote a note that put the PokéCenter on the east side. That note was wrong. When Claude walked out, it said "Mt Moon is behind me," and it marked the mountain as done. A few actions later, it went over the ledge. Its navigation tool did not show the drop. So Claude decided that it had gone too far west, and it kept the wrong note.

The repair was small. A dreaming pass compared the note with the session transcript. It found the error and rewrote one fact. A cache entry with no invalidation gives the wrong value with full confidence. The fix is also a database fix: reconcile the copy against the log.

Look at row one and row two together. The wrong note did not make Claude better than no note. Both runs failed. The corrected note made the difference.

The last three bugs came from wiki builds on the Harvey LAB benchmark. LAB gives Claude a set of documents and asks for a legal brief. A grader checks the brief against a list of criteria.

Bug 3 has the best lesson. The first instructions did not say that contract terms were the key part of the wiki. So Anthropic ran a loop. Claude studied its failures, proposed a change to its instructions and rebuilt the wiki. Claude found the fix itself: one writer per contract, and exact quotes in place of summaries. A database team calls this one writer per partition.

Bug 4 has no fix in the post. The post compares it to the Borges story about a map as large as the empire it shows. The wiki was so detailed that it summarized nothing. Bug 5 shows a limit of in-session notes. One session sees one context. A second pass sees all the pages, so it can find links that one session cannot.

Anthropic used internal documents from Stainless, a company that it acquired in May: about 350,000 files and about 420M tokens. It wrote 25 questions. Opus 5 agents built a wiki over 128 sessions. A shared log kept the sessions in step.

Search plus the wiki also used about 20,000 fewer tokens per question. Our arithmetic: at 128M dreaming tokens, the build pays back after about 6,400 questions on token count. That estimate ignores the accuracy gain and price differences between input and output tokens.

The task type matters. On 24 merger questions that needed facts from several documents, judgment or math, Claude scored 87% with the wiki and 73% with search alone. On one LAB task, most criteria came from one document. There, the wiki showed no clear gain.

Dreaming can move notes up to the injected layer. The harness then loads them at the start of each session. Claude does not need to search for them. It does not need to know they exist.

The post gives three costs. Injected notes use tokens in every session. A wrong note goes into every session. And a longer instruction file decreases adherence, as the Claude Code memory docs say. Claude Code auto memory loads the first 200 lines or 25 KB of MEMORY.md. That header is an index: it tells Claude what it knows and where to find it. Dreaming moves details down and leaves a link.

The post leaves two questions open. First, when to write: a note during the task takes focus away from the task, but a dreaming note is not available at once. Second, how often to dream: each pass costs compute, so Anthropic suggests a focus on facts that are likely to change. The dreaming cookbook and the knowledge wiki quickstart are the place to test both.