What happened
Anthropic’s November 6, 2026 engineering post defines agent memory as knowledge Claude gains from user interactions and assigned tasks, then retains between sessions in context it can read later. The company distinguishes this from model-weight changes, in-context learning within one conversation, and compaction, where summaries replace older turns so work can continue in a new context window. In Anthropic’s framing, an agent can tag salient events in session logs or write them to a memory store such as a folder of notes.
The post treats memory as a prediction about what a future session will need. In a Continual Learning Bench 1.0 database task, Claude answered questions, received the correct solutions, and could write memories to help with later questions. Anthropic says the models showed different capacities to close that feedback loop: some generated untested theories, while later models recorded confirmed facts, corrected errors, and assembled validated rules with indications of how they knew those rules were true. The experiments used Claude Managed Agents, with each question starting in a fresh session and a persistent memory directory available across sessions.
Anthropic also compared memory behavior during Pokémon Red runs. At around 10,000 steps, Sonnet 3.7 had produced 413 files across 225 folders and earned one badge. Fable 5 had written nine files in two folders plus a top-level global.md file and earned four badges. Anthropic’s interpretation is that the larger archive included volatile state that the game already displayed, while the smaller set emphasized plans, strategies, and tested rules. The post says that Opus 5.5 used a similarly compact set of notes and beat the game.
The company tested how prompts affect memory use. On the benchmark, telling models to “record only failures” reduced much of the performance gain memory had provided for Opus 4.7 and Opus 5. Anthropic says general guidance to use an available memory folder worked better for stronger models than fixed advance rules. For Sonnet 4.6, explicitly prompting it to read memory and test its theories nearly doubled its benchmark score; Sonnet 5 read its memory before answering nine times out of ten without that prompt.
Anthropic’s “dreaming” process checks notes against original transcripts to find and repair mistakes or stale information. In the Pokémon example, Claude incorrectly placed a landmark, misread its progress through Mt. Moon, and then fell back onto a route it had already traversed. The post describes a corrected memory note changing the subsequent outcome. Anthropic presents this process as a way to organize memory between interactions, not simply to retrieve a larger archive.
What the archive adds
New Runtime’s earlier coverage has treated agent memory both as a context-control layer and as a system with measurable costs. An earlier note on a study found that many dedicated memory systems underperformed naive retrieval over raw history (Memory Tax paper finds many dedicated agent memory systems underperform naive RAG over raw history, October 27, 2026). This is a new company account of memory mechanisms and evaluations, not a restatement of that study.
Trend signal
This supports Company memory needs write and correction loops: Anthropic’s dreaming concept checks saved notes against experience and revises them. The examples make correction part of memory management rather than an exceptional recovery step, although they do not establish a production-ready governance model.
Why now
Anthropic’s post connects growing agent capability with a practical memory problem: persistent notes can help across long tasks, but errors and changing environments can make those notes harmful. Its examples position memory organization and review as parts of current Claude agent design.
Why it matters
For teams building agents, the post argues against treating memory as an ever-growing transcript dump. A compact store of plans, verified rules, and unresolved uncertainties may be more useful than repeatedly saving facts already visible in the environment. The benchmark discussion also suggests that memory policy should not be hard-coded too aggressively: a rule such as “record only failures” can suppress useful information, while stronger models may be able to judge salience themselves.
The more operationally important idea is that a memory write is not necessarily trustworthy forever. Notes can begin wrong or become stale, so a system that persists them should have a way to compare them with the underlying interaction history and correct them. Anthropic’s account is an evaluation report, not a general guarantee, but it gives builders a concrete design question: what evidence supports a stored rule, and how will a later session detect that it no longer applies?
Limits and uncertainty
Anthropic presents selected benchmark and game evaluations rather than an independently replicated deployment study. The Pokémon comparison describes one run each for Sonnet 3.7 and Fable 5 at the stated point, so it should not be read as a controlled estimate of general model performance. The reported examples also leave open how much compute, latency, and operational work dreaming requires at production scale, and how often a memory-review loop catches errors rather than creating new ones.
Skill to build now
Audit one agent’s persistent memory this week. Separate facts visible from the current environment from durable rules, plans, and learned strategies; mark which entries were verified and against what evidence. Then test whether the agent can revisit a mistaken note against its source log and correct it without preserving stale conclusions.
Reader takeaway
The useful memory is not the largest memory. Anthropic’s examples point toward selective, validated notes and a review loop that can correct them; builders should measure whether those mechanisms help in their own tasks before assuming the pattern transfers.