Anthropic finds restrictive memory rules cost Claude agents much of their performance gain

Anthropic's engineering team has published research showing that giving Claude a persistent folder for notes between sessions sharply improves its scores on a database question-answering task — and that instructing the model to save only certain kinds of information can wipe out much of that benefit. The findings appear in a November 6, 2026 engineering post titled "The components of agent memory," summarized in a dev.to write-up by Gabriel Anhaia. Anthropic frames the work as research rather than a launch: no new model or API feature ships with it, though it links two recipes, a dreaming cookbook and a knowledge-wiki quickstart, and builds on the Dreams endpoint, which is in research preview for Claude Managed Agents.

What Anthropic measured

The benchmark is the database task from CL-Bench 1.0. Claude answers a series of questions by looking up information in a database, with each question arriving in a fresh session; the only thing carried over is a memory directory that persists between sessions. The gains were substantial across generations. Opus 4.7 went from a mean reward of 0.383 without memory to 0.700 with it; Opus 5 from 0.564 to 0.828; Opus 5.5 from 0.655 to 0.838; Sonnet 5.5 from 0.644 to 0.833; and Sonnet 5 from 0.306 to 0.610. Sonnet 4.6 was the outlier, barely moving from 0.330 to 0.364. According to Anthropic, that model often never opened the files in its memory directory and failed to test its theories; prompting it to read its notes and verify its assumptions before answering nearly doubled its score to 0.641.

The lesson: a memory directory the model never reads is just disk usage. Before concluding that an older model cannot benefit from memory, check that it actually consults its notes.

A four-layer hierarchy

Anthropic describes agent memory as four layers: transcripts, a log of past sessions that can be searched; memory notes, observations the model writes down; representations, structures such as wikis that the model builds and maintains; and injected context, material loaded into every session. Costs concentrate at the top. Injected memories consume tokens on every call, an incorrect note propagates into every session, and loading a note does not guarantee the model acts on it. Anthropic's conclusion is that the injected layer must stay small. Claude Code already reflects this: per its documentation, only the first 200 lines of MEMORY.md — or its first 25KB, whichever limit is reached first — load at the start of each conversation, with detail pushed into separate topic files the model reads on demand.

Rules on what to save backfired

The most counterintuitive result concerns steering. A rule like recording only failures looks like sensible engineering hygiene. In Anthropic's runs it backfired: Opus 5 and Opus 4.7, when told to record only their failures, lost much of the performance boost memory had given them. Anthropic's guidance is to explain what memory is for and let stronger models judge what is worth saving, since that proved more effective than fixed rules set in advance. A Pokémon Red comparison illustrates the shift across generations: Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge, while Fable 5 wrote nine files in two folders plus a global file and earned four. The caveat is that the right level of steering depends on the model — Sonnet 4.6 needed explicit instructions just to read its memory.

Dreaming: offline repair for wrong notes

Models write wrong notes — incorrect predictions, rules that were mistaken from the start. Anthropic's answer is dreaming, an offline reflection pass that checks notes against original transcripts and rewrites the bad ones. In the Pokémon run, dreaming corrected a mistaken location note and the agent reached Cerulean City at action 1,935; runs with uncorrected memory and with no memory never got there. In a wiki experiment over a Stainless corpus of roughly 350,000 files and about 420 million tokens, the wiki's standalone score rose from 13% to 48% as dreaming sessions increased from 2 to 128. Combined with search, the aggregate score rose from 54% to 61%, versus 53% for search alone, while saving about 20,000 tokens per question. The costs are real: on a separate legal-brief task the wiki grew larger than the documents themselves, and dreaming requires compute. According to the Dreams documentation cited in the write-up, a Dream is an asynchronous API job that reads a memory store plus one to one hundred past sessions and writes a new, reorganized store without modifying the original; jobs take minutes to hours and bill at standard token rates.

Why it matters

Anyone running long-lived agents — or simply letting Claude Code maintain a MEMORY.md file — is already making the choices this research tests. The practical takeaways: keep always-loaded context short, describe the purpose of memory rather than dictating what to save, verify the model actually reads its notes, audit and correct wrong entries manually, and if you use dreaming, point it at information likely to change and tune how often it runs. The broader signal is that memory management is becoming a core engineering discipline for agent design, and that over-constraining capable models can cost more than it saves.