Entrusting an AI agent with long-running tasks that span multiple sessions raises a challenge: how to remember and maintain what it has already done. Fine-tuning a model every time it acquires new knowledge is computationally expensive and also risks "catastrophic forgetting," in which existing knowledge is lost. Stuffing past conversations and work logs directly into the prompt has its own limits: the capacity of the context window, and the difficulty of accurately retrieving the necessary information from a very long context.
In a research report titled "The components of agent memory" published on November 6, 2026, Anthropic presents one solution to this problem: "Dreaming," a mechanism that runs reasoning outside of sessions to organize and correct memory from past logs. The design is modeled on the way the human brain organizes experiences during sleep and consolidates them into long-term memory. But how does it differ from conventional approaches that simply store conversation history? And is it effective enough to adopt in real operations? Drawing on the experimental results Anthropic released, this article examines the key insights for designing long-term memory for AI agents, along with the challenges that remain before practical use.
How "Offline Reasoning" Organizes Session Records
To think about agent memory, we first need to be clear about what counts as "memory." Anthropic defines agent memory as knowledge gained through user interactions and task execution that is stored in a form that can be referenced in future sessions. This definition excludes updates to model parameters through training. It is also distinct from in-context learning, in which a model understands new information within a single conversation, and from "compaction," which summarizes past exchanges to free up context window capacity.
In the architecture Anthropic presents, memory management is divided into "in-session recording," which stores information while a task is running, and "Dreaming," which organizes past records after a session ends. The former preserves important information on the spot; the latter reviews information accumulated over multiple sessions and arranges it into a form that will be easy to use later. Dreaming has five main uses: correcting erroneous notes, building knowledge structures such as wikis, moving important information into higher-level context, organizing memory for a specific purpose, and repairing missing cross-references that arose between sessions.
The design draws on the way memory is organized and consolidated during human sleep. That does not mean Claude has acquired the same memory mechanisms as humans. In practice, it is a process that reads past session logs (transcripts) and updates notes, such as Markdown files, using a reasoning model and file-manipulation tools. What matters is not reproducing human sleep but the fact that memory quality can be improved by using computing resources and time separate from those used during task execution.
The idea of using computation outside of sessions to organize memory was not first proposed by Anthropic. In the paper "Sleep-time Compute: Beyond Inference Scaling at Test-time", published on April 17, 2025, researchers from Letta and the University of California, Berkeley tested a method that uses idle time before the next question arrives to carry out reasoning in advance. That study also confirmed that the more predictable future questions are, the greater the benefit of precomputation. Anthropic's new research can be seen as applying this offline-reasoning idea to the management of memory files that agents use over long periods.
Models That Take Too Many Notes, and Models That Keep Only What Matters
The ability to judge what to remember while carrying out a task varies greatly by model generation. Anthropic used the database-search tasks from the continual-learning benchmark "Continual Learning Bench (CL-Bench) 1.0," released in May 2026, to examine whether Claude could learn from past failures and apply that learning in later sessions. In this experiment, a new session was started for each question, but files saved in a memory directory were carried over to the next session. After each answer, a grader supplied the correct answer, so the agent could analyze the cause of its mistakes and leave notes for next time.
The experiment showed memory use evolving step by step across models. Claude Sonnet 4.6 could form hypotheses about the causes of wrong answers, but stopped at writing unverified guesses across multiple files. Claude Opus 4.7 consolidated its notes into a single reference document and distinguished verified facts from unconfirmed speculation. Claude Sonnet 5 recorded information confirmed against the grader's correct answers and corrected its notes when it answered wrongly.
Claude Opus 5 went a step further. It did not simply save correct answers; it recorded the behavioral rules derived from them, the grounds for judging those rules correct, and warnings about pitfalls it had encountered, completing a learning cycle in which failures improve its next actions. The successor models Claude Opus 5.5 and Claude Sonnet 5.5 reproduced the same learning cycle, but their evaluation scores when using memory were roughly on par with Opus 5. Their baseline performance without memory had improved, which suggests that gains in a model's raw capability and gains in its ability to use memory do not necessarily advance at the same pace.
A clearer difference appeared in an experiment in which Claude played the Game Boy title Pokémon Red. Anthropic compared the memory folders of Claude Sonnet 3.7 and Claude Fable 5 at the point where each single playthrough reached about 10,000 steps. Both models were given memory folders they could read and write during the game, but their judgments about what to record differed greatly.
- 記憶ファイル総数
- 獲得バッジ数
データを表で見る
| 記憶ファイル総数 (件 / 個) | 獲得バッジ数 (件 / 個) | |
|---|---|---|
| Sonnet 3.7 | 413 | 1 |
| Fable 5 | 10 | 4 |
Claude Sonnet 3.7 tried to save the events it encountered in fine detail, including battles, item acquisitions, and conversations with characters. As a result, it created 413 memory files across 225 folders, yet earned only one badge. Because circumstances change as the game progresses, even carefully recorded information quickly became outdated, and managing the notes became a burden in itself. In fact, by around 10,000 steps, it had created six files and deleted nine within just 17 steps without performing a single in-game action.
Claude Fable 5, by contrast, created just nine files in two folders, plus a single global.md for tracking overall progress, and earned four badges. It did not record information that could be checked on the game screen, such as money or current location, and instead prioritized saving strategies and behavioral rules it had discovered itself. For example, after failing seven times in a row to capture a monster with a Poké Ball, it succeeded by changing the timing of its input, and from that experience it wrote a rule: if the same failure occurs three or more times in a row, change the input interval. According to Anthropic, Claude Opus 5.5 likewise kept a small number of notes and rewrote them as needed, and ultimately completed the game.
This comparison suggests that what matters more than increasing memory capacity is judging which information will remain useful and discarding what is no longer needed. Rather than exhaustively preserving past events, saving the insights gained from them as concise rules can work more efficiently in long-running tasks. However, the Pokémon experiment is a single observation per model, so it cannot be concluded that the way memory was organized alone produced the difference in results. Whether similar effects hold in business tasks outside games will need separate verification.
Given Anthropic's experiments, it makes sense to choose a memory-management approach according to the nature of the task. For one-off inquiries, searching existing documents is often enough; for work that involves learning decision rules from past experience, in-session notes are useful. When knowledge must be organized from multiple documents or sessions, building a wiki through Dreaming becomes an option.
| アーキテクチャ | 適したワークロード | Anthropicの検証結果 | 主なコスト・リスク | 導入方法と管理上の要点 |
|---|---|---|---|---|
| トランスクリプト検索 | 単一文書の参照、定型・単発の問い合わせ | 単一文書で完結する課題ではWikiによる明確な改善が見られなかった | 検索ごとの計算コストと応答時間 | 既存のRAG基盤を活用できる |
| セッション中のノート作成 | 直近の決定事項、作業進捗、経験から得た規則の引き継ぎ | Fable 5やOpus 5では、重要な情報を選んで保存する能力が向上 | メモ作成による作業中断、過剰な記録、情報の陳腐化 | セッション間で共有する記憶ディレクトリを利用 |
| ドリーミング＋知識Wiki | 複数文書を横断する調査、計算や判断を伴う反復作業 | 複合調査課題で採点基準の達成率が検索単体の73%から87%へ向上 | オフライン推論の追加費用、誤情報の固定化、Wikiの肥大化 | Managed Agentsの研究プレビューなどを利用し、生成結果を検証して反映 |
Can a Knowledge Wiki Replace Cross-Document Search?
Anthropic presents two concrete uses of Dreaming: automatically building a knowledge wiki from past records, and correcting erroneous memories. Notes created during a session are not always accurate. Information an agent saved after misunderstanding a situation, or information that became outdated as the environment changed, may be referenced repeatedly in later sessions. Dreaming aims to cross-check such records against the original session logs and find and fix errors and contradictions.
One example given is a failure in Mt. Moon, a dungeon in Pokémon Red. Claude had recorded the location of the Pokémon Center near the cave entrance incorrectly and believed it had already passed through the cave. As a result, it repeatedly jumped down a one-way ledge and was sent back to a path it had already traveled. Partly because its movement tools did not adequately convey the presence of the ledge, it could not correct the faulty memory and ended without reaching the next town.
Anthropic then ran Dreaming on the memory folder containing the incorrect location information. Claude cross-checked past session logs against its notes, found that the description of the Pokémon Center's location was wrong, and corrected it. In the subsequent run, it consulted the corrected memory, returned to the cave, and reached the next town, Cerulean City. However, this is a case in which one specific error was fixed; it does not prove that Dreaming can detect every misperception or instance of outdated information. If the original logs themselves contain a misinterpretation, there remains a possibility that the information would be remembered again as fact.
For a test closer to real work, Anthropic used internal documents from Stainless, whose acquisition it announced on May 18, 2026. The corpus comprises about 350,000 documents totaling roughly 420 million tokens. The research team created a 25-question evaluation set about this corpus, gave a Claude Opus 5 agent a search tool, and instructed it to build a wiki through Dreaming. Over multiple sessions, the agent investigated the documents, repeatedly adding related pages, merging duplicates, correcting erroneous statements, and cross-checking against source materials.
データを表で見る
| 採点基準の達成率 (%) | |
|---|---|
| 2セッション | 13 |
| 128セッション | 48 |
When the number of sessions used to build the wiki was increased from 2 to 128, the rubric achievement rate when consulting the wiki alone rose from 13% to 48%. In a configuration combining the search tool and the wiki, the rate improved from 54% to 61% as the wiki grew richer, exceeding the 53% achieved with the search tool alone. This result suggests that the wiki does not completely replace search but is effective when combined with it.
It was also reported that combining the wiki with search reduced token consumption by about 20,000 tokens per question compared with search alone. However, this figure compares token use at the time of answering questions and does not include the offline reasoning cost of the 128 sessions run to build the wiki. Even if efficiency at answer time improves, the overall computing cost of the system has not necessarily fallen. Judging long-term cost-effectiveness requires evaluation that includes the cost of building and updating the wiki.
The wiki's effect was especially pronounced in complex research tasks that require gathering information from multiple sources and adding calculation or judgment. Anthropic examined the usefulness of the wiki in detail using a 24-question research task based on documents about a corporate merger, as well as the legal benchmark "Harvey LAB."
データを表で見る
| 採点基準の達成率 (%) | |
|---|---|
| 検索ツール単体 | 73 |
| 検索＋Wiki併用 | 87 |
On the 24-question merger research task, the rubric achievement rate rose from 73% with search alone to 87% when search and the wiki were combined. More than half of the questions required gathering information from multiple documents, and some involved calculation or judgment. By contrast, in another Harvey LAB task, most of the necessary information could be retrieved from a single document, so using the wiki produced no clear improvement over search alone. In other words, the value of a wiki appears to depend less on the sheer volume of documents than on whether information must be organized by its relationships and multiple sources must be linked together.
Building a wiki does not guarantee greater efficiency, either. In another Harvey LAB task, the source documents totaled 115KB, while the wiki Claude generated swelled to 68 pages and 203KB, about 1.77 times the size of the original materials. The wiki, which was supposed to organize information, ended up larger than the source text. Anthropic likens this state to a map as large as the empire itself, as in the short story "On Exactitude in Science" by Argentine writer Jorge Luis Borges. If the original materials can barely be compressed, there is little point in creating a wiki.
A different problem emerged when multiple agents edited a wiki together. In a task organizing the contents of contracts, the default setup had multiple agents writing to the same shared table, so their changes overwrote one another, and only 41 of the 57 required facts (72%) made it into the final document. Anthropic then had Claude analyze the cause of the failure and repeatedly try to improve the wiki-building procedure. It arrived at a method of creating a separate page for each contract and recording key clauses verbatim rather than summarizing them. With this change, all 57 facts were reflected, and the rubric achievement rate reached 100%.
This result shows that how memory is structured, and how editing work is divided among agents, bears directly on the quality of the final answers. For information where exact preservation of the original text matters, such as contract clauses, a design that maintains references to the source material was more effective than casual summarization. When relationships among multiple documents need to be grasped, on the other hand, a wiki linked together is useful. Rather than trying to handle every task with a single memory-management method, storage formats and editing methods need to be chosen to suit the nature of the information.
Taken together, these experiments suggest that for work involving repeated investigation of frequently consulted document sets across multiple sessions, the upfront investment in building a wiki may pay off. Candidates include long-running legal research and work that repeatedly analyzes information scattered across multiple materials. Conversely, for one-off work that deals with different materials each time, or for inquiries that full-text search alone can answer, the added cost of Dreaming is unlikely to be justified by its benefit.
Operational Risks from Bad Data and Misperceptions
A mechanism that stores memory as external files and has the agent update them itself poses challenges for both security and reliability. A particular concern is that incorrect information, once saved, may be referenced in later sessions and continue to be treated as correct knowledge. For example, if an agent memorizes a wrong operating procedure and uses it as a correct rule in the next session, it may repeat the same failure. Dreaming can serve as a way to fix such errors, but it also risks carrying false information over into a new wiki.
There is also the question of when to update memory. Taking notes during work lets the agent save important information at that moment, but it interrupts the task itself. Leaving memory organization to Dreaming reduces the burden during task execution, but information is not updated until the next batch process completes. Anthropic itself acknowledges that continuously re-verifying all memory is not realistic in terms of computing cost. Operations will therefore need to prioritize verifying frequently changing information and adjust Dreaming's run interval according to how often entries are referenced.
Another important issue is the mechanism that automatically loads part of memory into context at the start of a session. Preloading important information lets the agent use past knowledge without searching each time. But the more information is loaded, the more of the context window it consumes, and if it contains incorrect statements, they can adversely affect later decisions. In addition, the Claude Code documentation points out that the longer an instruction file becomes, the less accurately the model follows its instructions.
As a countermeasure, Claude Code's auto memory feature limits the information automatically loaded from MEMORY.md into each session to the first 200 lines or 25KB. This file records key points and pointers to individual notes, and detailed information is adopted in a hierarchical structure loaded only when needed. The important point is that, rather than packing all knowledge into context every time, the initially loaded information is kept small while still allowing the agent to reach the information it needs.
On the security side, there is also the danger of malicious data from outside entering long-term memory. If an agent reads a malicious website or a document supplied by a third party and mistakenly saves the instructions it contains into its own memory, that content could be carried over into later sessions. This means prompt injection no longer ends with a single exchange but continues to exert influence through memory files. In configurations where memory content is incorporated into the system prompt in particular, unauthorized instructions could steer the agent's behavior over a long period.
Anthropic's official cookbook, "Dreaming with a dynamic workflow", also urges caution on this point. It recommends giving priority to logs from agents the organization controls, and connecting the memory store as read-only to agents that perform ordinary tasks. Update permissions for memory are limited to the session that runs Dreaming, and unnecessary shell operations and network access are withheld, containing the scope of damage that malicious input could cause. Separating the permissions of agents that perform general tasks from those of agents that edit long-term memory is important.
However, the nightly batch-processing sample shown in the cookbook includes a configuration in which generated memory is reflected directly into the existing store without human review. Run as is, incorrect information could be written overnight and referenced in the next morning's work. In real operations, a step to inspect updated memory and a mechanism to roll back to a previous state when anomalies are detected are needed.
The Managed Agents memory management API has a version-control feature that tracks memory change history. The history is retained for 30 days in principle, and rollback is possible by retrieving an old version and writing its content back. However, there is no dedicated restore endpoint, and history older than 30 days may be deleted. Where long-term auditing is required, version history should be saved separately and a recovery system put in place for when problems occur.
A Staged Approach to Pilot Deployment
Currently, Anthropic's Managed Agents is available in beta, and the Dreams API, which provides the Dreaming feature, is at the Research Preview stage, requiring an application for access. It should therefore not be regarded as a finished feature ready for immediate use in general commercial environments. Still, the official documentation lays out concrete API specifications and processing steps, making technical preparation for a pilot possible.
The models supported by the Dreams API are Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5, Sonnet 5, Opus 4.8, Opus 4.7, and Sonnet 4.6. The Dreams endpoint requires the dedicated beta header dreaming-2026-04-21, while Managed Agents session operations use managed-agents-2026-04-01. Dreaming runs as an asynchronous job and can take from several minutes to several hours depending on the volume of input logs.
Importantly, the Dreams API is designed by default not to modify the input memory store and instead to output the organized content to a separate store. Note that the API reference also describes an option to set output_behavior to update_existing and update the existing store directly. How memory is updated therefore depends on the settings used.
With a configuration that outputs to a separate store, the content generated by Dreaming can be verified while the pre-update memory is preserved. Rather than applying new memory to production immediately, operators can have administrators review it or run automated tests, and begin using it only after confirming there are no problems. This is close to the idea of a staging environment in software development, and it reduces the risk that erroneous memory updates spill over into production work.
On cost, the standard API token pricing of the selected model applies to Dreams API processing. According to Anthropic, costs increase roughly linearly with the number and length of the session logs entered. Running Dreaming more often may shorten the lag in memory updates, but inference costs rise accordingly. Even if building a wiki reduces token consumption at answer time, the real economics cannot be judged without evaluating total cost including offline reasoning.
Companies considering adopting agent memory need not start with automatic Dreaming updates. A reasonable path is to use simple RAG (retrieval-augmented generation) on existing search infrastructure as the baseline, then evaluate a configuration that saves notes during sessions. Then add automatic wiki building and memory updates through Dreaming, and measure how answer quality, token consumption, response time, and operational burden change.
Evaluation should check not only the accuracy of final answers but also whether memory updates have increased false information or lost necessary facts. Especially when multiple agents use the same memory, the design must prevent editing conflicts and missing information. Mechanisms that let the system go back to the source materials to verify when saved memory becomes stale, and procedures for reversing erroneous updates, are also important. Anthropic's experiments confirmed performance gains from organizing memory, but they have not fully resolved these operational problems.
What this research shows is that, for long-term memory in AI agents, what matters more than how much information can be stored is what to keep, how to organize it, and when to update it. Dreaming could be a promising way to organize knowledge gained from past work outside of sessions and carry it into the next task. Its effect varies by the nature of the work, however, and challenges remain in computing cost and the inheritance of false information. Going forward, the key to practical use will be whether not only the ability to update memory autonomously, but also mechanisms to verify the accuracy of the generated knowledge and operate it safely, can be established.