Anthropic Engineering 于 2026 年 11 月 6 日发布文章《The components of agent memory》，作者为 Lance Martin，编辑协助来自 Caitlin Love、Tom Chivers、Rebecca Hiscott、Jake Eaton 与 Blake Wilson。文章讨论 Claude 如何在会话之间保留经验知识，以及名为 dreaming 的离线整理过程如何纠正错误笔记、写出新笔记、构建 wiki 一类表征，并决定哪些内容预先载入后续会话。官方 X 账号 @AnthropicAI 同日转发了这篇工程研究帖。本文完整改写该文公开正文与图注中的可核验信息；Lance Martin 的个人 X 身份未在本轮核验，故不杜撰其个人账号。

文章开头借用克尔凯郭尔的说法：人生只能向后理解，却必须向前过。Anthropic 认为，给 AI 智能体设计记忆时也面对类似张力。人类在生活中持续编码记忆，海马体在当下捕获体验，使记忆很快形成并立即可用，但只有一部分体验会巩固成长时知识。许多巩固发生在大脑“离线”时：睡眠与安静休息期间，海马体重放近期体验，并逐渐把它们蒸馏、整合进新皮层。

智能体记忆可以采用类似的分工。智能体大量工作会留在日志或转录里。Letta 与加州大学伯克利分校的研究者提出过 sleep-time compute：模型利用交互之间的空闲时间重组已有上下文。同一思路也可帮助智能体整理记忆——回看日志以修正错误，或产出新的笔记与表征。

Anthropic Engineering 把这种会话之间、利用空闲时间回看日志、纠正错误、写出新笔记或新表征的过程，称为 dreaming。

作者写到，dreaming 已被证明有助于给 Claude 提供有效记忆。下文按若干评测拆开说明记忆各组成部分，以及 dreaming 各自贡献了什么。Dreaming 可以纠正错误、创建笔记、构建新的记忆表征，或塑造预先载入未来会话的内容。

什么叫智能体记忆，什么不算

文中所说的 agent memory，指 Claude 从经验中获得、并在会话之间保留、之后可作为上下文再读入的知识，包括与用户的互动和被指派的任务。它不包括改动模型权重、单次对话内的 in-context learning，也不包括 compaction——即 Claude 用摘要替换较早轮次、以便在新上下文窗口里继续工作。

人类大脑里，体验前后释放的化学信号可以把某段记忆标成重要；被标记的记忆在离线期往往更常被重放，从而更稳定地进入长期记忆。

因此，Claude 可以在会话日志里当场给重要事件打标签，方便以后查找；也可以把它们写进记忆库，例如一个记忆笔记文件夹。

难点在于：在还不知道接下来会发生什么时，Claude 如何判断当下什么算 salient。

记忆有时是在预测未来需要什么

写下一条规则，等于预测这个模式以后还会用得上。例如，写下一条已核实事实，是在预测未来会话里的 agent 会想直接依赖它，而不再复查。作者认为，Claude 在这类预测上已经明显进步。

Continual Learning Bench（CL-Bench）1.0 衡量智能体用记忆处理长程任务的能力。其中一项任务要求 Claude 查数据库回答一系列问题；给出答案后，系统会告知正确答案，Claude 可以写入记忆以帮助回答后续问题。若答错，它可以记录失败、提出关于出错原因的理论、检验这些理论，再把发现写成以后作答的规则。

作者用 Claude Managed Agents 跑了 CL-Bench 1.0。每个问题开始于全新会话，唯一例外是可从跨会话持久存在的记忆目录取文件。

不同模型形成学习闭环的程度不同。Claude Sonnet 4.6 能生成关于答错原因的理论，记忆目录里是分散文件，各自列出若干未经检验的猜测。Claude Opus 4.7 把笔记收成单一参考文档，并开始标注哪些事实已核对、哪些仍未确认。Claude Sonnet 5 在评分器核对后把答案标为已确认，答错时写出纠正。Claude Opus 5 是文中这批模型里最先闭合闭环的：多数条目包含规则及其依据、先前问题的答案，以及对途中发现陷阱的明确警告。Claude Opus 5.5 与 Claude Sonnet 5.5 同样闭合了闭环，用记忆保存经验证的未来作答规则；有记忆时两者得分与 Opus 5 大致相当，尽管它们在无记忆基线上略高。

图注给出的 CL-Bench 数据库任务平均奖励为：Opus 5.5 无记忆 0.655、有记忆 0.838；Sonnet 5.5 为 0.644 与 0.833；Opus 5 为 0.564 与 0.828；Opus 4.7 为 0.383 与 0.700；Sonnet 5 为 0.306 与 0.610；Sonnet 4.6 为 0.330 与 0.364。右侧折线则显示同样模型在约 30 道题上的滚动平均奖励。

判断什么值得记住：宝可梦评测

作者还用《宝可梦 红》评测 Claude 对“该把什么写入记忆”的判断，因为这款游戏要求处理复杂长程任务。每次运行开始时，模型会得到一个可读写的记忆文件夹。

他们比较了 Claude Sonnet 3.7 与 Claude Fable 5 各一次运行、约进行到 10,000 步时的记忆文件夹。Sonnet 3.7 假定什么都可能重要，几乎不加筛选地写入：常为每场战斗、每件物品、每个 NPC 单独建文件；最终写出 413 个记忆文件，分布在 225 个文件夹，并拿到 1 枚徽章。Fable 5 则写了两个文件夹里的 9 个文件，外加顶层的 global.md，并拿到 4 枚徽章。

对照图用相同比例画出两份记忆目录的树状面积图：Sonnet 3.7 一侧约有 413 个文件、977,930 个字符，分布在 locations、main、battles 以及多个 consolidated 文件夹；Fable 5 一侧约有 10 个文件、43,406 个字符，落在 locations、gameplay 与 global.md。

Sonnet 3.7 的做法主要问题在于游戏状态持续变化，详尽记录很快过时，Claude 越来越把时间花在翻记忆上而不是推进游戏。大约在第 10,000 步，Sonnet 3.7 开始建第四个“master”记忆文件夹；随后 17 步里，它新建 6 个文件、删除 9 个文件，却没有对游戏本身采取动作。

Fable 5 更倾向于记住游戏界面不会直接告诉它的内容。金钱数额或地图位置等每回合都能从屏幕读到，再存一遍是冗余的；而策略、计划与经验证规则，只有 Claude 自己总结出来并写下来才会留存。它的 global.md 充当仪表盘，保存当前目标、攻打道馆的预先计划，以及模型自己的记忆使用规则；locations 文件夹放特定路线导航计划，gameplay 文件夹放基于对游戏机制理解的策略。例如，连续 7 个精灵球都没抓住相对容易捕捉的鲤鱼王后，Claude 写下：若连续 3 个以上球失败，就改变按键时机，在菜单步骤之间插入额外 wait；它写到，这样做之后立刻捕获成功。

记忆文件夹小得多的 Fable 5，游戏进度远超 Sonnet 3.7。Opus 5.5 采取类似策略：只保留跟踪当前目标与下一步的小文件夹，边玩边改写，并通关了游戏。

该告诉 Claude 记忆是干什么的，而不是怎么写

作者发现，告诉 Claude 记忆是做什么用的、但不规定具体怎么用，往往更有效。在 CL-Bench 上，他们只说明有一个记忆文件夹可用；对 Opus 4.7 与 Opus 5，这种笼统指引已足以有效使用记忆，并带来明显提升。

他们也测试过给模型规定“该写什么”的具体规则，每次只加一条，并比较有规则与无规则时记忆带来的增益。当规则设为“只记录失败”时，Opus 5 与 Opus 4.7 都失去了记忆原本带来的大部分提升。对更强的模型，让它们自行判断显著性，比提前规定固定规则更有效；后者甚至可能削弱表现。

左图给出 Sonnet 4.6 的平均奖励：基线 0.330，仅有记忆 0.364，记忆并配合更明确的读写与验证提示后为 0.641；图中参考线标出 Opus 4.7 有记忆时的 0.700，以及 Opus 5 有记忆时的 0.828。右图则是改为“只记录失败”后，记忆带来的增益变化：Opus 5 为 −0.234，Opus 4.7 为 −0.150，Sonnet 4.6 为 −0.020。

引导对较旧模型帮助最大。例如 Sonnet 4.6 常常不读记忆目录里的文件，也不去检验关于答错原因的理论。此时，提示它在作答前先读记忆文件、并明确检验理论，几乎把基准分数翻倍。Sonnet 5 会自己这样做：在未被提示的情况下，它在 10 次中有 9 次作答前先读记忆；Sonnet 4.6 则不到一半。

对前沿 Claude 模型，作者通常只给简单指引：当有人要求，或某件事明显值得记住时，创建记忆笔记，并把判断留给 Claude。

Dreaming 可以纠正记忆

Claude 是按会话中的显著性判断写记忆的，因此从一开始就错、或随环境漂移的笔记，仍可能在后续会话被读到并被信任。

Dreaming 让 Claude 可以把笔记拿回原始会话转录去核对。

他们在 Managed Agents 挂载记忆目录玩宝可梦时，看到过正面例子。

游戏中有一段要穿过月见山：入口在地图西侧，出口在东侧。入口附近有单向岩架陷阱，掉下去会落回刚才来的路线，且没有明显回头爬上的办法。Claude 把山入口的宝可梦中心当作地标，因此会不会走下岩架，取决于它认为宝可梦中心在山的哪一侧。

有一次 Claude 错误记下宝可梦中心在东侧。它走出中心后宣称“月见山已经在我身后”，并把笔记更新为“Mt Moon DONE”。实际上月见山并不在身后。几步之后，它走下岩架，又落回来时的路线。

导航工具没有显示坠落，Claude 于是判断自己“冲过头、跑得太西了”，并认为自己本来就在正确一侧——实际上并不是。

作者随后对含有错误宝可梦中心位置的记忆文件夹运行 dreaming：Claude 对照会话转录核对笔记，发现错误并改写。转录提供了校验记忆的 ground truth。笔记纠正后，Claude 直接回到月见山，并最终到达华蓝市。

未纠正笔记的那次运行里，Claude 三次掉回先前路线。第三次失败后，它写下打算停下来、不再循环；实验设置的自动回复要求它继续。它于是一路退回月见山前的尼比市，希望疗伤补货。那次运行结束时，Claude 始终没有到达华蓝市。

图注给出的进度曲线覆盖约 3,000 次累计动作：记忆加 dreaming 的那次运行，在第 1,935 次动作到达华蓝市；只有原始错误记忆的那次反复坠崖并退回尼比市；完全没有记忆的那次始终没有到达华蓝市。

Dreaming 可以构建新的记忆表征

有了 dreaming，Claude 还可以构建帮助它在记忆里导航的表征。文中讨论的一类表征叫 wiki：由 Claude 自己撰写和维护的一组页面，把某一主题下已知内容汇总起来，并链接到其他笔记。

这些链接相当于一张地图，帮助 Claude 在记忆中筛选并定位需要的内容。

作者用 Stainless 的内部文档语料评估 wiki 作为记忆表征的收益；Stainless 是他们在五月收购的软件公司，语料约 35 万个文件、约 4.2 亿 tokens。他们构造了关于该语料的 25 道题评测集，给 Claude 搜索工具，并指示它用 dreaming 基于这些文件建 wiki。在 128 个会话里，他们让 Opus 5 agents 探索文件、撰写或修正带链接的 wiki 页面、合并重复项，并对照来源核对主张。各会话基于先前进度继续，并用共享日志协调。

把 dreaming 从 2 个会话扩到 128 个会话后，这 25 道题上达到的评分标准比例从 13% 升到 48%。Claude 增量建设 wiki：先建初版，再用后续 dreaming 增补、编辑或修剪。早期像新员工，仅靠 wiki 答题能力有限；dreaming 越多，知识地图越丰富。测试中，wiki 在同时提供搜索工具时帮助最大：搜索加 wiki 的总分随 wiki 成长从 54% 升到 61%，仅有搜索工具时为 53%；只用 wiki 答题时最好成绩为 48%。搜索加 wiki 还大约每题节省 20,000 tokens。

图注还给出示例 wiki 规模：2 个会话后约有 103 个页面、766 条链接；128 个会话后约有 222 个页面、12,893 条链接。横轴侧写到的 dreaming token 规模，从约 2M 增长到约 128M。

为了看清哪类任务受益于 wiki，作者使用 Harvey LAB 基准，以及一组关于并购的文档。基准给 Claude 一组文档，要求生成法律简报，再按标准列表打分。他们让 Claude 从文档建 wiki，再分别基于 wiki 或直接文件搜索来回答并购问题或生成 LAB 简报。

一项测试包含关于并购的 24 个问题，其中超过一半需要跨多份文档找信息，许多问题还要求判断或计算。在这些需要跨文档或额外判断的条目上，查阅 wiki 时 Claude 得分为 87%，仅用搜索时为 73%。

图注还说明：在 wiki 收益更明显的那侧，24 条标准大多连到 10 份文档中的两份或更多，其中 9 条需要判断或算术；在收益不明显的那侧，57 条标准大多能在单份文档里用文本搜索找到，通常是交易概览备忘录。

另一些情况下 wiki 用处更小。某一 LAB 任务中，简报标准往往能从单份文档用文本搜索取回，wiki 相对搜索没有明显增益。

在另一项 LAB 任务里，wiki 甚至长得比原始文档还大：约 10 份文档、115 KB 文本，对应出 68 个页面、255 条链接、203 KB，约为语料的 1.77 倍；其中一些 wiki 页面还没有任何链接。

作者把它比作博尔赫斯短篇《On Exactitude in Science》里把地图画得和帝国一样大的制图者：这份 wiki 细节极多，实际上几乎没有抽象。

Dreaming 可以把笔记推上记忆层级

Dreaming 还可以把笔记推到记忆层级的顶端，由 agent harness 在每个新会话开始时预先注入 Claude 的上下文。这样 Claude 不必先去搜索，甚至不必事先知道有东西需要搜索。

把记忆提升进新会话（一种 context injection）必须谨慎。注入内容占用宝贵 tokens，错误笔记会被带进每个会话；载入也不保证 Claude 会照做——Claude Code 文档提醒，更长的指令文件会降低遵从度。因此记忆层级顶层必须保持相对较小，dreaming 在这里的大量工作，就是把细节下沉、只留下链接。

Claude Code 的 auto memory 也用类似方式保持注入层很小，并由 Claude 在会话中维护。它不会把全部 auto memory 载入每个会话的上下文，而只载入 MEMORY.md 的前 200 行或 25 KB。这段页眉充当索引，告诉 Claude 自己知道什么、去哪里找。

Dreaming 可以围绕特定目标塑造记忆

Dreaming 也可以塑造记忆如何生长。例如 Claude Duet 这类助手，往往受益于围绕它所服务的人来组织记忆；dreaming 可被调成服务于特定目标。

指导记忆如何生长的指令因任务而异，并告诉 Claude 什么信息真正重要。LAB 基准中有一项模拟公司收购、提供一组合同；简报按是否正确描述合同条款评分。

作者起初只用基本建 wiki 指令，没有说明该怎样使用 wiki。该任务高度依赖合同条款。建 wiki 时，多个 agents 同时写入同一张合同条款共享表。结果是关键事实缺失：根据这份 wiki 生成的简报，只覆盖了 57 项事实中的 41 项，即 72%。原因是共享表对条款摘要很差，且因 agents 互相覆盖而整段缺失。

初始指令没有说明合同条款才是重点。作者随后让 Claude 在一个循环里回顾失败、提出改指令的方案，再重建 wiki。改进后，每份合同由单个 agent 写成独立页面，并逐字引用条款，而不是汇总进共享表。用这份改进后的 wiki 生成简报再评分，可满足的标准从 72% 升到 100%，也就是 57/57。

Dreaming 可以补上单次会话留下的缺口

Claude 写记忆笔记时，只看得到当次会话上下文。Dreaming 可以跨多个会话搜索共同模式或纠正共同错误。

在为 LAB 基准建 wiki 时，Claude 有时会链接到尚未创建的页面。第二轮 dreaming 补上了许多缺口。

在某一任务里，第二轮 dreaming 发现 wiki 中有 9 条链接指向尚未创建的页面，并把它们改指到同一文档已有页面；它还新增了包括索引在内的 3 个页面。图注给出前后规模：第二轮前约 38 个条目、225 条链接，其中 6 个页面上的 9 条链接指向不存在的 escrow-agreement；第二轮后约 41 个条目、278 条链接，那 9 条链接都指向 buyer-form-escrow-agreement，并新增 index、instructions email 与 escalations 三个页面。

仍未解决的问题

关于如何设计智能体记忆系统，文章列出若干开放问题。其一是 Claude 何时该创建记忆：在任务进行中写入记忆库，可以在源头捕获显著性，并立刻供后续轮次或会话使用，但当场记笔记会分走对主任务的注意力；dreaming 可以把记忆创建推到后台，但其产出未必立即可用。

其二是如何可靠地保持记忆更新。Claude 可能做出错误预测，或写下一开始就错的规则；环境变化也会让记忆漂移、变得无关。Dreaming 是修复途径之一，但需要算力。让 Claude 持续检查全部记忆未必现实；更重要的或许是把 dreaming 聚焦在可能变化的信息上，或按记忆被访问的频率等仔细调节节奏。

也可以把转录搜索视为 Claude 记忆的基础。表征（如 wiki）与搜索结合有时有效，但维护表征、防止错误与幻觉累积同样需要算力。

尽管 Claude 对显著性的判断已经改进，没有任何模型能真正预知未来轮次会发生什么。Dreaming 给了 Claude 向后回看、用算力整理记忆、纠正错误、并维护便于未来会话取用表征的机会。作者写到，记忆系统会随 Claude 能力提升而演变，关于如何设计 Claude 的记忆系统，他们仍有许多要学。

致谢与图表署名

正文由 Lance Martin 撰写；编辑指导来自 Caitlin Love、Tom Chivers、Rebecca Hiscott、Jake Eaton 与 Blake Wilson。作者感谢 Barry Zhang、Theodora Chu、Daliang Li、Mahesh Murag、Jake Noble、Ravi Trivedi、Tina Vachovsky、Brad Abrams、Henry de Valence、Jeremy Fox、Matt Bell、Allen Li、Chris Gorgolewski、Eugene Yan、Artur Renault、Wei Zhang 与 Kevin Chen 的讨论与贡献，并感谢 David Hershey 的 Claude Plays Pokémon 工作。配图由 Monika Tuchowska 制作。

来源范围：完整改写 https://www.anthropic.com/research/components-of-agent-memory 公开正文；发现帖为 https://x.com/AnthropicAI/status/2118814753154064501 。15 张正文配图均使用官方 CDN 绝对地址，alt 取自原页；未对图片做超出图注/alt 的场景臆测，也未声称播放或交互验证。本文不把 Anthropic 的评测数字外推为已上线产品对所有用户的默认行为。

原文附带媒体

原文 Figure 1：会话间记忆层级与 Dreaming 示意；与开篇 dreaming 定义段对应，集中保留于文末。 原文 Figure 2：记忆笔记层高亮；与记忆笔记定义段对应，集中保留于文末。 原文 Figure 3：CL-Bench 有无记忆柱状图与滚动均值；与模型分数段对应，集中保留于文末。 原文 Figure 4：宝可梦记忆目录树状面积图（Sonnet 3.7 vs Fable 5）；与文件数/徽章对比段对应，集中保留于文末。 原文 Figure 5：Sonnet 4.6 引导与“只记失败”增益；与 steering 评测段对应，集中保留于文末。 原文 Figure 6：Dreaming 对照转录纠正笔记；与纠错机制段对应，集中保留于文末。 原文 Figure 7：月见山岩架 Raw memory vs Memory + dreaming；与错误地标段对应，集中保留于文末。 原文 Figure 8：通往华蓝市进度曲线；与三次坠崖对照段对应，集中保留于文末。 原文 Figure 9：Dreaming 构建 wiki 等表征；与表征定义段对应，集中保留于文末。 原文 Figure 10：wiki 扩展评分与网络图；与 Stainless 语料评测段对应，集中保留于文末。 原文 Figure 11：LAB/并购标准与源文档关联；与 87%/73% 对比段对应，集中保留于文末。 原文 Figure 12：wiki 体积超过语料；与 Borges 类比段对应，集中保留于文末。 原文 Figure 13：笔记提升至注入上下文层；与 context injection 段对应，集中保留于文末。 原文 Figure 14：共享条款页 vs 每合同独立页；与 41/57→57/57 段对应，集中保留于文末。 原文 Figure 15：第二轮 dreaming 修补断链前后；与补缺口段对应，集中保留于文末。

The components of agent memory

Published Nov 6, 2026 · Team: Engineering

Written by Lance Martin with editorial guidance from Caitlin Love, Tom Chivers, Rebecca Hiscott, Jake Eaton, and Blake Wilson. (Full acknowledgements at end.)

Søren Kierkegaard wrote that life can only be understood backward, but it must be lived forward. We've encountered a similar bind when designing memory for AI agents.

As humans, we encode memory constantly as we go about our lives. The hippocampus plays a central role in this, capturing experiences in the moment so that memories form quickly and are immediately available. But only some experiences are consolidated into long-term knowledge.

Much of that consolidation appears to happen when our brains are offline. As we sleep, and during quiet rest, the hippocampus replays our recent experiences. This is thought to gradually distill those experiences and integrate them into the neocortex—the part of our brains that stores most of what we think of as knowledge.

Agent memory can use a similar division of labor. Agents capture much of their work in logs or transcripts. Researchers at Letta and UC Berkeley proposed sleep-time compute as a way for models to use idle time between interactions to reorganize their existing context. The same idea can help agents organize their memory by reflecting on logs to fix mistakes or produce new notes and representations. This process is often called dreaming (Figure 1).

We've found that dreaming has been a useful tool for helping us give Claude effective memory. In this post, we share how we've come to think about agent memory and walk through several evaluations we've used to explore agent memory, including the use of dreaming, and what each component contributes to memory organization.

Claude can use dreaming to organize memory. This can correct mistakes, create notes, build new memory representations, or shape what's preemptively loaded into future sessions.

!Figure 1. Diagram of a memory hierarchy between one session and the next. From bottom to top: transcripts (a searchable event log), memory notes written by Claude, memory representations such as wikis, and injected context loaded into every session. Inside a box labeled "Dreaming," arrows run from transcripts up to each layer, and in both directions between neighboring upper layers.

Memory notes

By "agent memory," we mean knowledge that Claude gains from experience—including interactions with users and tasks it's been assigned—and that it retains between sessions, saved as context it can read later. It excludes other ways models can learn or manage context, such as changes to their weights (the internal parameters set during training), in-context learning (knowledge gained within a single conversation), and compaction (summaries written by Claude that replace its older turns so it can continue working in a new context window).

In the human brain, chemical signals released before, during, or after an experience can mark a memory as important. Marked memories tend to be replayed more often than unmarked ones during offline periods. This process, called replay, helps stabilize and integrate them into long-term memory.

Similarly, Claude can tag salient events in a session log as they happen, so they're easier to find later, or it can write them to a memory store, such as a folder of memory notes (Figure 2). But how can Claude tell what's salient in the moment, before it knows what's coming next?

Claude can write notes to memory.

!Figure 2. The same memory hierarchy, with the memory notes layer highlighted. An arrow runs from the session directly to the memory notes, described as salient observations written by Claude.

Memory can be a prediction about what the future will need

Memory is, occasionally, a prediction. By writing down a rule, an agent predicts that the pattern it's describing will be relevant again. For instance, writing down a verified fact is a prediction that an agent in a future session will want to rely on that fact without double-checking it. Over time, Claude has become much better at making these kinds of predictions.

Consider a task from Continual Learning Bench (CL-Bench) 1.0, a benchmark that measures an agent's ability to use memory in order to tackle long-horizon tasks. One particular task asks Claude to answer a series of questions by looking up information in a database. After Claude gives an answer, it's told the correct solution and can write a memory to help answer future questions.

Memory can support a learning loop here. If Claude gets a question wrong, it can record the failure, come up with theories about what went wrong, test those theories, and turn what it finds into a rule about how to answer in the future.

We ran the CL-Bench 1.0 task using Claude Managed Agents. Claude started each question in a fresh session, with one exception: it could retrieve files from a memory directory that persisted from one session to the next.

Different models achieved different levels of success at creating their own learning loops. Claude Sonnet 4.6 got as far as generating theories about why an answer was wrong. Its memory directory contained a scattering of files, each listing several untested guesses.

Claude Opus 4.7 consolidated its notes into a single reference document and began marking which facts it had checked and which were still unconfirmed. Claude Sonnet 5 marked each answer as confirmed after the grader had checked it, and wrote a correction when it had answered wrong.

Claude Opus 5 was the first of these models to close the loop. Most of its entries included a rule (and also how it knew the rule was true), answers to earlier questions, and clear warnings about traps it had discovered along the way (Figure 3).

Like Opus 5, Claude Opus 5.5 and Claude Sonnet 5.5 both closed the loop, using memory to capture validated rules about how to best answer future questions. With memory, both scored about the same as Opus 5, though their baseline performance without memory was slightly higher.

!Figure 3. Left: bar chart of mean reward on the CL-Bench database task, stateless baseline versus memory store. Opus 5.5: 0.655, 0.838. Sonnet 5.5: 0.644, 0.833. Opus 5: 0.564, 0.828. Opus 4.7: 0.383, 0.700. Sonnet 5: 0.306, 0.610. Sonnet 4.6: 0.330, 0.364. Right: line chart of running-mean reward over 30 questions for the same models, with and without memory.

Claude has learned to judge salience

We also evaluated Claude's ability to play Pokémon Red, a game that challenges Claude to navigate complex long-horizon tasks, as a test of Claude's judgment about what to save to memory. At the start of each run, we gave each model a folder of memory files that it could read from and write to while it played (Figure 4).

We compared the memory folders from one run each of Claude Sonnet 3.7 and Claude Fable 5, when each was about 10,000 steps into the game. A key difference we noticed was what each model thought was worth remembering. Sonnet 3.7 assumed everything might matter and wrote to memory indiscriminately. Its memory folder contained an archive of encounters, often with a separate file for each battle it fought, each item it found, and each non-player character it met. Ultimately, Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge (badges mark a player's progress through the game).

Fable 5, by comparison, wrote nine files in two folders, plus a single top-level file called global.md, and earned four badges.

!Figure 4. Two treemaps of Pokémon memory directories at the same scale, where area shows characters of memory. Claude Sonnet 3.7's is large and crowded, with 413 files and 977,930 characters across folders such as locations, main, battles, and several "consolidated" folders. Claude Fable 5's is small, with 10 files and 43,406 characters in locations, gameplay, and global.md.

Sonnet 3.7's approach was a problem mainly because the game state of Pokémon changes constantly—Sonnet 3.7's detailed record was continuously going out of date. As a result, as Claude progressed, it had to spend more time and resources combing through its memories rather than playing the game. Around step 10,000, for example, Sonnet 3.7 started its fourth folder of "master" memory files. Over the next 17 steps, it created six files, deleted nine others, and took no actions in the game itself.

Fable 5's approach used memory for things the game didn't explicitly tell it. Some of the kinds of information Sonnet 3.7 wrote to memory—such as how much money the player has or where the player is on the map—can be read off the screen every turn, so storing it is redundant. By contrast, memory files about strategy, plans, and tested rules exist only if Claude works them out, and they disappear unless Claude writes them down.

Fable 5 organized its memory accordingly. Its global.md file acted as a dashboard, holding the current goal, a prewritten plan for tackling gyms (the challenges where badges are won), and the model's own rules for using memory. A locations folder held plans for navigating particular routes, and a gameplay folder held strategies based on what it had learned about how the game works. For example, after seven Poké Balls in a row failed to catch a Magikarp (one of the easiest Pokémon to catch), Claude wrote, "If 3+ balls fail in a row, VARY the timing (insert extra 'wait' presses between menu steps) - the catch landed right after doing this."

With a much smaller memory folder, Fable 5 progressed much further in the game than Sonnet 3.7. Opus 5.5 took a similar approach: it kept a small folder of memory notes that tracked its current goal and next steps, rewrote them as it played, and beat the game.

Steering Claude to write memory

We've found that it helps to tell Claude what memory is for, but not how to use it. On CL-Bench, we simply told Claude that a memory folder was available. That general guidance was enough for Opus 4.7 and Opus 5 to use memory effectively, and it gave both a noticeable boost in performance (Figure 3).

We also tested giving the models specific rules about what they should write to memory, with one rule per test. We compared how much each model gained from memory with each rule against how much it gained without it. When we set a rule to "record only failures," both Opus 5 and Opus 4.7 lost much of the performance boost that memory gave them (Figure 5, right). For stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance, and those rules could end up weakening performance.

!Figure 5. Left: bar chart of Sonnet 4.6's mean reward on the CL-Bench database task: 0.330 at baseline, 0.364 with memory, and 0.641 with memory and refined instruction. Reference lines mark Opus 4.7 with memory at 0.700 and Opus 5 with memory at 0.828. Right: change in memory gain when told to record only failures: Opus 5, −0.234; Opus 4.7, −0.150; Sonnet 4.6, −0.020.

We also noticed that steering helped older models the most. For instance, Sonnet 4.6 often didn't read files from its memory directory and failed to test its theories about why an answer was wrong.

In this case, prompting Claude to read its memory files before answering—and then to explicitly test its theories—nearly doubled its benchmark score (Figure 5, left). Sonnet 5 does this on its own. Without being prompted to, it read its memory before answering 9 out of 10 times. By comparison, Sonnet 4.6 did this less than half of the time.

With frontier Claude models, we typically give simple guidance to create memory notes when a person asks them to or when something is clearly worth remembering, and we leave that judgment up to Claude.

Dreaming can correct memory

Since Claude writes to memory based on what it judges to be salient in-session, a note that's wrong from the start or that drifts as the environment changes can be read, and trusted, by Claude in a later session.

Dreaming gives Claude a way to test its notes against the original transcripts (Figure 6). We saw a positive example of this when Claude played Pokémon using Managed Agents with a mounted directory for its memories.

!Figure 6. The memory hierarchy with dreaming, highlighting an arrow from the transcripts layer up to the memory notes layer, which shows dreaming correcting notes against transcripts.

In one part of the game, the player has to get through Mt. Moon, a cave system with its entrance on the west side of the map and its exit on the east. Near the entrance is a trap: a one-way ledge that drops the player onto the route they came from, with no clear way to climb back up. Claude was using the PokéCenter, a building at the mountain's entrance, as a landmark, so whether it walked off the ledge depended on which side of the mountain it thought the PokéCenter was on.

At one point, Claude wrote down (incorrectly) that the PokéCenter was on the east side. When it walked out of the PokéCenter, it announced, "Mt Moon is behind me," and updated its notes: "Mt Moon DONE." But Mt. Moon was not behind it. A few actions later, Claude went over the ledge and landed back on the route it had come from (Figure 7). Its navigation tool didn't show the drop, so Claude concluded, "I overshot far west," and that it had been on the correct side all along. It hadn't.

!Figure 7. Two Pokémon map panels with the agent next to a ledge. Left, "Raw memory," where the stored note is wrong: an arrow shows the agent heading for the next city. Right, "Memory + dreaming," where an offline pass corrected the note: an arrow shows the agent heading back to the cave entrance.

We then tested whether dreaming could help Claude avoid this trap. We ran dreaming on the memory folder that contained the wrong location for the PokéCenter: Claude checked the note against the session transcript, caught its error, and rewrote it. The transcript gave Claude a ground truth to validate its memory against. With the corrected memory note, Claude went straight back into Mt. Moon and eventually reached Cerulean City.

In the run with the uncorrected note, Claude dropped back onto that earlier route three times. After the third failure, Claude seemed to give up, writing, "I'm going to stop rather than keep looping." Our setup's automatic reply instructed it to continue. So it did, all the way back to Pewter City, the town before the mountain, where it hoped to heal and restock. The run ended without Claude ever reaching Cerulean City.

!Figure 8. Line chart of progress toward Cerulean over 3,000 cumulative actions. The memory plus dreaming run reaches Cerulean at action 1,935. The raw memory run falls off the ledge and backtracks to Pewter. The run with no memory never reaches Cerulean.

Dreaming can build new memory representations

With dreaming, Claude can build representations to help navigate memory (Figure 9). One type of memory representation it uses is called a wiki, a collection of pages written and maintained by Claude that gathers what Claude knows about one subject and links it to other notes. These links effectively provide Claude with a map it can use to sift through its memory and efficiently locate memories when they're needed.

!Figure 9. The memory hierarchy with dreaming, highlighting arrows from transcripts and from memory notes up to the memory representations layer, such as wikis.

Representations like wikis can help Claude traverse its ever-growing knowledge base. We explored the benefit of wikis as a memory representation using a corpus of internal documents—about 350,000 files, roughly 420M tokens—from Stainless, a software company we acquired in May. We created an evaluation set of 25 questions about this corpus and gave Claude a search tool to explore it. We also instructed Claude to build a wiki based on these files using dreaming. Over 128 sessions, we prompted Opus 5 agents to explore the files, write or correct linked wiki pages, merge duplicates, and check claims against the sources.

Each session built on the progress that agents made in prior sessions, using a shared log to coordinate work. As we scaled dreaming from two sessions to 128, performance on the 25 questions grew from 13% to 48% of graded criteria (Figure 10).

Claude builds its wikis incrementally. After creating an initial wiki, it uses subsequent rounds of dreaming to add to, edit, or prune it. In the early rounds of dreaming, Claude's knowledge is like that of a new employee, and its ability to answer questions based on the wiki alone is limited. The more it dreams, the richer its knowledge map grows, like that of a seasoned employee. In our tests, we found that the wiki helped Claude the most when we also gave it access to a search tool. When it used both search and the wiki, Claude's aggregate score rose from 54% to 61% as that wiki grew, compared with 53% when it had access to the search tool alone. Claude's best score was 48% when it used only the wiki to answer questions. Using search and the wiki also saved about 20,000 tokens per question.

!Figure 10. Center: line chart of graded criteria met as wiki generation grows from 2M to 128M dreaming tokens. Wiki plus search tool rises from 54% to 61%, wiki alone rises from 13% to 48%, and the search tool with no wiki is flat at 53%. Left and right: network graphs of an example wiki, with 103 pages and 766 links after 2 sessions and 222 pages and 12,893 links after 128 sessions.

We wanted to test which kinds of tasks benefited from Claude having a wiki. To do this, we used the Harvey LAB benchmark along with a collection of documents about a merger. The benchmark gives Claude a set of documents and asks Claude to generate a legal brief based on their content. The benchmark then grades the brief against a list of criteria. While a tad less engaging, perhaps, than a Pokémon run, these evaluations give us diverse collections of documents to build wikis from.

We instructed Claude to build a wiki from the documents. We then asked Claude to answer questions (about the merger) or generate legal briefs (the LAB benchmark) both from the wiki and from a direct file search. One test asked 24 questions about the merger (Figure 11, left), more than half of which needed Claude to find information across several documents, and many of which also needed Claude to use judgment or do math. On those items (red and orange lines), Claude scored 87% when it consulted the wiki, compared with 73% when it used search alone.

!Figure 11. Two diagrams linking graded criteria to source documents. Left, the task where the wiki showed more benefit: most of the 24 criteria connect to two or more of 10 documents, and nine need judgment or arithmetic. Right, the task where the wiki showed less benefit: most of the 57 criteria can be found by text search in a single document, usually the deal overview memo.

In other cases, the wiki was less useful. On one LAB task (Figure 11, right), brief criteria often could be retrieved with a text search from a single document, and the wiki showed no clear gain in performance relative to search. On another LAB task, the wiki grew larger than the documents themselves (Figure 12). Like the mapmakers in Borges's one-paragraph short story "On Exactitude in Science," who drafted a map so detailed it was as large as the empire it represented, Claude had made an extremely detailed wiki that effectively abstracted nothing.

!Figure 12. Diagram of a wiki build and second pass. On the left, a circle holds the corpus: 10 documents, 115 KB of text. An arrow leads to a larger circle holding the wiki built from it: 68 pages, 255 links, and 203 KB, or 1.77 times the corpus. Some of the wiki's pages have no links.

Dreaming can promote notes up the memory hierarchy

Dreaming can also float notes to the top of the memory hierarchy, and the agent harness can preemptively load them into Claude's context at the start of every session (Figure 13). This means Claude doesn't need to search for them, or even to know there's something to search for.

Promoting memories into a new session (a form of context injection) must be done carefully. Injected memories use up valuable tokens, and an incorrect note can be carried into every session. Loading a note also doesn't guarantee that Claude acts on it: our documentation on Claude Code warns that longer instruction files reduce adherence. So the top layer of the memory hierarchy has to stay relatively small, and much of dreaming's work here is keeping it that way—by moving some details down the hierarchy and leaving links behind.

Claude Code's auto memory keeps its injected layer small in the same way, with Claude maintaining it during the session. Claude doesn't load all of its auto memory into every session's context window. It loads only the first 200 lines or 25 KB of MEMORY.md. This header serves as an index, which shows Claude what it knows and where to find it.

!Figure 13. The memory hierarchy with dreaming, highlighting arrows from transcripts and from memory representations up to the injected context layer at the top, which feeds into the next session.

Dreaming can focus memory on a specific goal

Dreaming can also shape how memory grows. An assistant like Claude Duet, for example, often benefits from having memories that are organized around the person it's helping, and dreaming can be tuned to build memory in service of a particular goal.

The instructions that guide how memory grows differ by task and tell Claude what information actually matters. For example, one task in the LAB benchmark simulates a company acquisition and provides a set of contracts. The brief is graded on whether it correctly describes the contract terms.

We started with basic instructions for generating the wiki that didn't tell Claude how to use the wiki. This task relied heavily on contract terms. While the wiki was being built, several agents wrote to a shared table of contract terms at the same time (Figure 14, left).

The result was a wiki that was missing key facts. When we graded a brief generated from the wiki, Claude had included only 41 of the 57 facts (72%). When we looked at what had gone wrong, we found that the shared table summarized the contract terms poorly and was missing some of them altogether, because agents had overwritten one another's work.

The contract terms were the most important part of the wiki, but the instructions didn't say that. To find better instructions, we ran a loop in which Claude reflected on its failures, proposed a change to the instructions, and rebuilt the wiki. This loop allowed Claude to discover how important it was to follow the contract terms, and it rewrote the instructions for building the wiki accordingly.

Each contract got its own page in the wiki, written by a single agent, which quoted the terms word for word rather than summarizing them into a shared table. When we graded the brief generated from this improved wiki, 100% of the criteria could be met, up from 72%.

!Figure 14. Two diagrams. Before: four agents write to the same shared page, provisions.md, and one agent's save erases another's lines; 41 of 57 graded facts survived. After: four agents each write their own contract's page, with terms copied word for word; all 57 of 57 graded facts survived.

Dreaming can fill in gaps a session leaves behind

When Claude writes memory notes, it sees only the context in that particular session. Dreaming can search across many sessions to find common patterns or correct common mistakes.

When building the wikis for the LAB benchmark (as an example, see Figure 14), sometimes Claude would link to pages that hadn't yet been created. A second dreaming pass closed many of these gaps. On one task (Figure 15), dreaming found nine links to a missing page in the wiki and repointed them to an existing page for the same document. It also added three new pages, including an index, to improve the wiki.

!Figure 15. Two network graphs of a wiki. Before the second pass: 38 entries and 225 links, with nine links from six pages pointing to "escrow-agreement," a page that doesn't exist. After: 41 entries and 278 links, with all nine links pointing to "buyer-form-escrow-agreement" and three new pages: index, instructions email, and escalations.

Thinking backward, looking forward

There are many open questions about how to design memory systems for agents. One is when Claude should create memory. When Claude works on a task, it can write to a memory store (e.g., a folder, file, or database), capturing salience at the source and making important details immediately available for future turns or sessions. But logging notes in the moment inevitably draws Claude's attention away from its main task. In contrast, dreaming can push memory creation to the background, but any outputs from dreaming may not be immediately accessible to Claude.

Another question is how to keep memory reliably up to date. Claude can make incorrect predictions or write rules to memory that are wrong from the start. Memory can also drift and become irrelevant as the environment changes. Dreaming is one way to fix these mistakes (Figure 8), but it requires compute. Directing Claude to continuously check all its memories might not be practical. It may be important instead to focus dreaming on information that's likely to change or to carefully tune the cadence of dreaming (e.g., based on how often memories are accessed).

It's also reasonable to consider transcript search as the foundation of Claude's memory. Combining representations (e.g., wikis) with search (Figure 10) can sometimes be effective. But Claude needs to use compute to maintain memory representations and make sure they don't accumulate errors or hallucinations.

Even though Claude's judgment about salience has improved, no model can really know what will happen in future turns. Dreaming gives Claude an opportunity to look backward and use compute to organize its memory, correct mistakes, and maintain representations that allow future sessions to access memory more readily. Memory systems will evolve as Claude gets more capable, and we still have a lot to learn about designing Claude's memory systems.

Acknowledgements

Written by Lance Martin with editorial guidance from Caitlin Love, Tom Chivers, Rebecca Hiscott, Jake Eaton, and Blake Wilson. We're grateful to Barry Zhang, Theodora Chu, Daliang Li, Mahesh Murag, Jake Noble, Ravi Trivedi, Tina Vachovsky, Brad Abrams, Henry de Valence, Jeremy Fox, Matt Bell, Allen Li, Chris Gorgolewski, Eugene Yan, Artur Renault, Wei Zhang, and Kevin Chen for helpful discussions and contributions, and to David Hershey for Claude Plays Pokémon. Figures by Monika Tuchowska.