Anthropic Details Agent Memory and Offline Dreaming | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
Anthropic Details Agent Memory and Offline Dreaming
Anthropic’s implementation guide shows how persistent notes, searchable sources and offline review can help agents learn across sessions, and where those systems go wrong.
Anthropic recently released an architectural guide for persistent agent memory, detailing how to retain knowledge across sessions using four layers: transcripts, memory notes, structured wikis, and injected context. Rather than relying on model retraining, this approach uses an offline process called dreaming to validate, reorganize, and correct stored information. Evaluations indicate that simply saving data is insufficient; performance gains depend on the model’s ability to distinguish between durable, verified rules and stale event logs. Builders should prioritize concise, evidence-backed notes and combine searchable archives with synthetic wikis to optimize both token usage and task accuracy.
Anthropic published “The components of agent memory” on November 6, 2026, describing a practical architecture for retaining knowledge across agent sessions. It combines transcripts, memory notes, structured representations such as wikis, and a small amount of context loaded into future sessions. An offline process called “dreaming” checks and reorganizes those layers.
This is implementation guidance backed by evaluations, not a new Claude model or consumer feature. The useful finding is that memory quality depends on what an agent preserves, how it validates that information, and when it retrieves it. Saving more material can leave an agent with stale facts, repeated mistakes and less room to work.
Four Memory Layers With Different Jobs
Anthropic defines agent memory as knowledge gained from experience and retained between sessions as readable context. That excludes changes to model weights, learning within a single conversation, and context compaction, which summarizes older turns so an ongoing task can continue.
The architecture separates the record of what happened from the information worth carrying forward:
Layer
What it contains
Practical role
Transcripts
Session activity and interaction history
Preserve searchable evidence of what happened
Memory notes
Selected facts, corrections and rules
Carry useful lessons between sessions
Representations
Organized material such as linked wikis
Connect information across notes and documents
Injected context
A small selection loaded into new sessions
Make essential guidance immediately available
Anthropic’s guide describes dreaming as an offline process that can correct mistakes, create notes, build representations or change what gets loaded next time.
The distinction matters. A transcript provides evidence, but it can be expensive to search repeatedly. A note makes a conclusion easy to reuse, but it can preserve a mistaken interpretation. A wiki connects related material, while injected context makes selected information unavoidable in every session.
My reading is that these layers should have different admission standards. Keeping an event in a searchable archive is a modest commitment. Putting its conclusion into every future session gives that conclusion much more influence, so it deserves stronger validation.
Persistent Memory Helps When Models Validate Their Rules
Anthropic tested a database task from Continual Learning Bench, or CL-Bench, 1.0 using Claude Managed Agents. Each question began in a fresh session. A persistent memory directory was the exception: agents could retrieve files saved during previous questions.
After answering, the model received the correct solution and could write a memory for later use. That creates an opportunity to turn feedback into reusable rules.
These are Anthropic-run evaluations, with no independent reproduction in the supplied sources. Their results depend on the model, task, memory instructions, search tools and offline-compute budget.
Opus 5.5 gained 0.183 in mean reward. Sonnet 4.6 gained only 0.034 from having a memory directory available. The differences in their notes help explain why a storage mechanism alone is insufficient.
According to Anthropic, Sonnet 4.6 recorded scattered, untested theories. Opus 4.7 distinguished checked facts from unconfirmed ones. Opus 5 recorded rules, evidence supporting those rules, previous answers and warnings about discovered traps. Opus 5.5 and Sonnet 5.5 also completed that feedback loop.
The lesson for builders is specific: evaluate whether a model turns corrections into validated guidance. File-writing ability is a weak proxy for that skill.
Instructions also changed the outcome. Restricting memory to failures reduced gains for several models. More explicit instructions helped Sonnet 4.6: prompting it to read its memories and test its theories raised its score to 0.641, according to the detailed results. Stronger models needed less steering. I’d treat memory prompts as something to evaluate per model, especially after a model upgrade.
A Large Memory Can Become Another Task to Manage
Anthropic’s Pokémon Red experiments provide a concrete counterexample to the idea that more saved information means better memory.
At roughly 10,000 game steps, one Sonnet 3.7 run had created 413 files across 225 folders and earned one badge. A Fable 5 run used 10 files and earned four badges. These were individual runs, so the comparison illustrates memory behavior without isolating memory size as the cause of game performance.
Sonnet 3.7 saved extensive information about battles, items and characters. Much of it became stale as the game changed. At one point, it spent 17 steps creating and deleting memory files without taking an action in the game.
Fable 5 concentrated on information the current screen could not supply: goals, route notes, gym plans and tested rules. The account of Anthropic’s comparison makes the tradeoff clear: maintaining an archive can consume the effort that should advance the task.
For builders, the useful distinction is between durable knowledge and recoverable state. If a tool can cheaply show the current inventory or location, repeatedly preserving that state may add little. A verified rule about an unfamiliar environment is harder to recover and more valuable to retain.
Dreaming Can Repair a Confidently Wrong Note
Offline consolidation addresses a different problem: an agent can select an important fact and still record it incorrectly.
In Anthropic’s Pokémon example, Claude saved an incorrect PokéCenter location around Mt. Moon and concluded it had already crossed the cave. Later navigation reinforced that mistaken interpretation. The agent repeatedly dropped onto an earlier route while trusting its notes.
A dreaming pass checked the memory against the session transcript and corrected the location. With the corrected note, Claude reached Cerulean City at action 1,935. The uncorrected run repeated the navigation failure and eventually stopped, according to the published account.
The important mechanism is evidence checking. Shortening the original note would have retained the same error. Reviewing what actually happened gave the offline process a chance to challenge it.
That is a strong reason to retain searchable transcripts even when the working memory is compact. A source reference attached to a durable rule gives a later consolidation pass something concrete to inspect. The benefit is grounded in this example; the broader recommendation is an architectural inference from it.
Search and Wikis Worked Better Together
Anthropic also tested a generated wiki over an internal corpus of about 350,000 files, containing roughly 420 million tokens. Opus 5 agents used between two and 128 sessions to create and improve linked pages, merge duplicates and check claims.
On 25 evaluation questions:
Wiki alone rose from 13% to 48% of graded criteria as the offline work increased.
Search alone scored 53%.
Search plus wiki rose from 54% to 61%.
Anthropic also reported savings of about 20,000 tokens per question when using the combined approach. These figures and the experimental setup are described in Subagentic’s detailed account.
The consequential comparison is 48% versus 53%: even the largest tested wiki remained below search alone. Combining the two reached 61%, eight percentage points above the search baseline.
That supports using a wiki as a navigational and synthesis layer while keeping original material searchable. The wiki can connect concepts and reduce repeated exploration; source retrieval can supply details it omitted.
The token savings concern question answering. They do not by themselves show lower total cost, because generating the wiki required offline sessions. A frequently queried, relatively stable corpus has more opportunity to amortize that work than a rarely accessed collection that changes constantly. That is an economic implication of the setup, not a measured break-even point.
What Builders Can Apply
Anthropic warns that memory representations can accumulate errors, become larger than the underlying corpus or consume too much injected context. A compact store still needs maintenance.
For an initial implementation, I’d use the evidence to set five priorities:
Preserve concise, validated rules. Record the lesson and its supporting evidence. Keep untested explanations visibly separate from confirmed findings.
Let capable models judge salience. Test what the model chooses to save before imposing rigid templates. Older models may need explicit instructions to retrieve notes and test hypotheses.
Use offline passes for verification. Have consolidation compare important notes with transcripts, resolve contradictions and remove obsolete material. Summarization alone is insufficient.
Keep source search alongside the wiki. The corpus experiment supports using both. Generated pages should help locate and connect evidence without becoming the only available record.
Limit always-injected context. Reserve startup material for essential guidance and navigation. Retrieve detailed memories when the task calls for them.
Anthropic’s cookbook index lists a “Dreaming with a dynamic workflow” implementation. It reads completed sessions, distills them into a wiki-style memory store and mounts that store read-only in future sessions. The workflow can run nightly from cron.
That separation is useful: normal task sessions consume a consolidated store, while a separate process maintains it. Builders still need evaluations for factual retention, stale information and downstream task performance. A smaller memory is worthwhile when it preserves the right knowledge, not simply because it occupies fewer tokens.
Frequently Asked Questions
3 questions
1
Is This a New Claude Model Release?
No. Anthropic published implementation guidance, evaluations and supporting cookbooks for agent memory. The post describes architecture and tradeoffs.
2
Does Dreaming Change Model Weights?
No. In this guide, dreaming reviews and reorganizes external memory, such as notes and wikis. It does not retrain the model.
3
Must Dreaming Run Every Night?
The cookbook supports a nightly cron schedule. That is an implementation option, not evidence that nightly consolidation is optimal for every workload.
