Anthropic Launches 'Dreaming' Preview to Stop Multi-Agent Errors

Anthropic发布“Dreaming”预览版以遏制多智能体错误 异步后台处理通过在活跃运行时循环之外整理共享记忆库，将智能体任务完成率提升至六倍。 在本次演示中，Anthropic介绍了记忆（memory）与“dreaming”两项基础原语，旨在为长期运行的AI智能体实现持续自主学习和上下文管理。尽管处于公开测试阶段的记忆系统将记忆建模为虚拟文件系统以满足企业级多智能体需求，但单个智能体往往仍局限在各自的活跃任务中。为了弥合这一差距，Anthropic新推出的带外“dreaming”功能可异步分析整个智能体集群的交互记录，从而识别宏观模式、精简冗余数据并提炼核心洞察。这一组合架构确保了并行智能体能够大幅减少错误、削减Token成本，并无缝继承团队的集体知识。 Anthropic 推出面向 Agent 开发的全新核心原语“Memory”（记忆），旨在解决长周期任务中的自主学习与上下文管理难题，早期采用者 Rakuten 反馈其首轮错误率降低了 90%。 (3:15) Anthropic 将记忆系统建模为虚拟文件系统，使 Claude 能直接使用 Bash 和 Grep 等工具进行管理，并通过权限范围划分与乐观并发控制支持企业级多 Agent 并行扩展。 (4:15) 针对标准记忆在多 Agent 协同中难以全局维护的局限，Anthropic 推出异步后台批处理机制“Dreaming”（做梦），法律科技公司 Harvey 借此在基准测试中实现了 6 倍的任务完成率提升。 (9:39) Dreaming 采用带外运行设计，将记忆整理与即时任务解耦，像搜索引擎索引器一样通过前期算力分析多会话转录本，实现跨 Agent 模式提取、去重与知识验证。 (12:04)

Anthropic product manager Mahesh presents managed agent memory and an asynchronous background mechanism called "dreaming" as key primitives for continuous agent self-learning, arguing that separating live task execution from offline knowledge curation enables multi-agent systems to scale over long horizons without latency or token bloat. Virtual File Systems and Enterprise Memory Controls (3:15) Anthropic models agent memory as a virtual file system rather than a flat document, allowing models such as Claude Opus 4.7 to manage, search, and update information using command-line tools like Bash and Grep. To support enterprise swarms running hundreds or thousands of parallel sessions, the architecture introduces permission scopes—differentiating static, read-only organizational runbooks from an agent's read-write working memory—alongside optimistic concurrency via precondition content hashes to prevent agents from clobbering shared records. The system also incorporates detailed audit logs, version histories, and timestamped attribution metadata to track modifications across sessions. To prevent vendor lock-in and satisfy corporate governance, a standalone portable API allows external pipelines to audit state, clean records, or scan for personally identifiable information. According to Anthropic, early adopter Rakuten observed a 90% decrease in first-pass errors within its internal knowledge agents after deploying this memory architecture, alongside reductions in latency, costs, and token usage. The Process Layer and Need for Dreaming (9:39) Anthropic structures agent memory into three distinct architectural tiers: the storage layer for raw records and metadata, the structure and content layer for file hierarchies and skills, and the process layer governing update triggers and synthesis. While the standard memory API addresses storage and structure, real-time agents operating on active tasks remain siloed within immediate contexts and cannot holistically synthesize knowledge across concurrent sessions. To address the process layer, Anthropic introduced "dreaming" into research preview as an out-of-band batch mechanism. The core design philosophy centers on separation of concerns: keeping memory quality decoupled from task execution on the active "hot path." This allows operational agents to focus entirely on task completion while the background process systematically extracts patterns, analyzes transcripts, and refines shared organizational memory. Asynchronous Curation and Upfront Compute Investment (12:04) Dreaming operates asynchronously and can be invoked periodically through the cloud console, scheduled via cron jobs, or triggered automatically after an agent session concludes. Anthropic likens the mechanism to a search engine indexer that expends compute upfront—similar to test-time compute in reasoning models—to analyze recent transcripts, detect recurring tool failures, extract successful workflows, and generate updated memory diffs. By investing compute out-of-band, dreaming amortizes maintenance across all reading agents, preventing shared stores from degrading into bloated, token-heavy scratchpads. The process automatically deduplicates redundant entries, purges obsolete records, and appends verification notes. In customer testing highlighted by Anthropic, legal technology company Harvey recorded a six-fold (6x) increase in task completion rates on a legal benchmark after deploying dreaming. Multi-Agent Collaboration in Site Reliability Engineering (17:43) A demonstration of site reliability engineering (SRE) agents illustrates how shared memory stores function in real-world workflows. When responding to a P1 dispatch alert, an initial agent investigates CPU utilization, traffic surges, and recent pull requests, writing its findings to a shared read-write SRE store while referencing read-only company runbooks. When a second alert triggers minutes later, a newly spawned agent reads the prior diff and immediately short-circuits the investigation, bypassing redundant diagnostic work. A subsequent dreaming job executed on seven days of SRE transcripts detects higher-level system behavior that isolated agents missed: dispatch latency alerts consistently occurred 60 seconds after upstream CPU spikes due to inefficient retry logic. The dreaming run consolidated five identical diagnostic notes into a single entry, verified the conclusions against transcript evidence, and applied an updated memory state without human intervention. As AI agents shift toward workflows running continuously across hours or days, Anthropic positions the pairing of real-time virtual file memory and asynchronous dreaming as foundational infrastructure required to coordinate multi-agent knowledge bases without continuous manual curation.

Anthropic 平台团队产品经理 Mahesh 宣布在托管智能体 API 中推出处于公测阶段的记忆功能以及进入研究预览阶段的“做梦”（dreaming）机制，旨在为长周期与多智能体系统提供持续自学习与上下文管理支持。 长周期任务催生前沿记忆基语 (0:07) 随着人工智能模型执行长达数小时或数天的复杂任务，现有的外部工具协议（如 MCP）、开发者工具包与技能（skills）机制仍难以解决智能体持续自学习与跨周期上下文管理的问题。为弥补这一缺失，Anthropic 将记忆确立为下一代核心基语，使智能体能够根据自身经验演进、理解成功标准、规避常见错误，并在多智能体集群中共享认知。 虚拟文件系统与企业级控制机制 (3:15) 为了摆脱以往单一文件（如 Claude.md）或受限 SDK 工具的束缚，Anthropic 将记忆构建为分层虚拟文件系统，让 Claude Opus 4.7 能够使用 Bash 与 Grep 等工具自主管理、检索与更新文件。面对企业多智能体并发场景，系统引入了基于内容哈希的乐观并发控制以防写入覆盖，并支持权限作用域划分，例如为智能体赋予全局运维手册的只读权限以及各自工作记忆的读写权限。同时，系统提供包含智能体、会话和时间戳属性的审计日志，配合独立的便携式 API，便于外部流水线进行 PII 审查与数据清洗。 做梦机制打破即时记忆的孤岛局限 (9:39) 标准记忆虽然覆盖了存储层与结构层，但处于活跃任务中的单个智能体往往局限于局部视野，无法从全局跨会话日志中提炼系统性认知。为此，Anthropic 开发了异步批处理过程“做梦”（dreaming）。它独立于智能体执行任务的实时链路，通过周期调度或任务结束触发，分析历史对话记录，识别失败的工具调用模式与成功策略。Anthropic 援引早期测试数据指出，乐天（Rakuten）借助记忆系统使内部知识智能体的首发错误率下降了 90%，而法律科技公司 Harvey 应用做梦机制后，在实际法律基准测试中的任务完成率提升了 6 倍。 解耦计算负载与知识库压缩整理 (12:04) “做梦”借鉴了搜索引擎索引与测试期计算（test-time compute）的设计理念，将“任务执行”与“记忆质量管理”两个目标分离。它在离线状态下预先投入算力，对膨胀的记忆库进行清洗、去重和验证，从而避免海量经验导致活跃智能体的上下文膨胀并产生额外延迟。在现场演示的 SRE 场景中，做梦作业扫描了过去 7 天的会话，从分散的报警排查记录中识别出 CPU 突增 60 秒后重试逻辑低效的共性模式，并将多条冗余记录合并为一条经核验的诊断结论，供后续智能体直接复用以节省排查开销。 Anthropic 预计未来智能体将普遍持续运行数小时乃至数天，实时记忆与后台做梦机制的结合将成为支撑大规模企业知识库演进的关键桥梁，但该系统在更广泛多智能体复杂场景下的长期稳定性与治理表现仍有待进一步观察。

[0:07] Mahesh: memory is the key to unlocking true continuous self-learning and context management over long-horizon tasks. [3:15] Mahesh: dropped first-pass mistakes in their internal knowledge agents by 90% because the agents could catch errors and pass those learnings to subsequent iterations. [3:15] Mahesh: Claude views memory as a hierarchy of files that it can manage, search, and update using familiar tools like Bash and Grep. [9:39] Mahesh: Dreaming is an asynchronous, batch process that runs separately from active agent sessions. It analyzes recent transcripts and patterns across multiple sessions to automatically generate organized, up-to-date memory. [9:39] Mahesh: observed a staggering six-fold (6x) increase in task completion rates. [12:04] Mahesh: Dreaming separates the objective of 'memory quality' from 'task completion.' This allows active agents to focus entirely on executing their immediate tasks efficiently, while the background dreaming process handles the heavy lifting of organizing and curating long-term knowledge. [16:49] Mahesh: effectively lets us amortize this effort across all of those agents that are reading from a memory store. [16:49] Mahesh: the bridge between these more intermediate memory systems and these larger scale knowledge bases [17:43] Mahesh: Because it has access to the same memory store, the new agent immediately reads the previous note, allowing it to 'short-circuit' the investigation. [21:35] Mahesh: Because individual agents only see their own sessions, they cannot spot this trend on their own; the dreaming process synthesizes these isolated experiences to benefit future agents. [21:35] Mahesh: an really important part of that system and what makes it ultimately possible.

[0:07] Hello. [0:08] Everyone, how's it going? [0:11] Thanks for coming. [0:14] My name is Mahesh and I'm a product [0:16] manager on the platform team here at [0:19] Anthropic. Uh over the past year and a [0:21] half, I've gotten to work on primitives [0:23] like MCP and skills. And today I want to [0:26] talk about the primitive that I'm most [0:28] excited about next, which is memory. [0:31] Um I'll talk about why we think memory [0:34] is so important and why we've been [0:35] spending so much time on it at [0:37] Anthropic. How we think about designing [0:39] memory systems that are built for [0:41] frontier agents. And I'm excited to also [0:44] talk about dreaming, a brand new product [0:46] that we're launching today in research [0:48] preview in the managed agents API. [0:55] Model capabilities have improved really [0:58] quickly over the last couple of years. [1:00] And agents are capable of tasks that [1:02] take many, many hours and can run for [1:06] hours or almost days at a time. And as [1:08] models and agents have improved, we've [1:10] also invested in building higher and [1:13] higher level capabilities and primitives [1:15] that kind of get out of those models' [1:17] way and give them access to additional [1:20] bits of their environment and things [1:22] that they can manage and become more [1:24] powerful over time. [1:26] So, for example, we launched MCP, which [1:29] gives agents access to external tools [1:32] and data. [1:33] We launched harnesses that were really [1:35] powerful like Claude Code and the agent [1:38] SDK. And in October, we launched skills, [1:40] which let agents pick up brand new [1:42] capabilities that either other agents [1:45] have designed and shared with them or [1:47] humans and users that they interact with [1:49] designed for them. [1:51] Each primitive has let agents do [1:53] increasingly powerful things for longer [1:55] periods of time, but we still think that [1:58] something is still kind of unsolved, and [2:00] that's continuous self-learning and [2:03] context management over long horizon [2:05] tasks. [2:08] So, memory is the next primitive. It's [2:11] the thing that I think we'll get us to [2:13] self-learning agents that evolve and [2:15] improve based on the tasks that they're [2:17] working on and their own experience. [2:20] With memory, agents can learn about the [2:23] tasks they work on, things like the [2:25] success criteria, common mistakes, [2:27] strategies that are or are not working. [2:30] They can learn about their environments, [2:32] things like the code bases that they [2:34] interact with, the files and the assets [2:36] that they're constantly keeping up to [2:37] date. And they can also learn from other [2:40] agents that are in the same environment [2:42] as them. They can share learnings, they [2:44] can figure out what's going wrong [2:45] elsewhere in a system, and incorporate [2:48] that into their own memory. [2:50] And I think this last point is the one [2:51] that I've been most excited about this [2:53] year and over the next couple of months. [2:55] I think self-managed memory is going to [2:57] be super important in these large and [2:59] complex multi-agent systems where a [3:02] swarm of agents that are working in a [3:04] similar environment on discrete tasks [3:07] are essentially building up their own [3:09] understanding and their own model of the [3:11] worlds that they're in over time. [3:15] So, to help get to this vision, we just [3:17] launched memory in cloud-managed agents [3:19] in public beta a couple of weeks ago. [3:22] This gives developers a frontier memory [3:24] system that works out of the box to [3:26] maximize intelligence by default, to [3:30] support these systems of many agents [3:32] running concurrently in the same [3:34] environment, and most importantly, to [3:36] give enterprises and developers the [3:39] flexibility and control they need to [3:41] actually run these in production in an [3:43] enterprise setting. [3:46] We've already heard from a bunch of [3:48] teams building on this to date, um that [3:50] all say that this helps them get to [3:52] continuous learning and continuous [3:54] improving agents a lot faster. Uh, [3:57] Rakuten, for example, mentioned that uh, [3:59] this helped them drop their first pass [4:01] mistakes in their internal uh, knowledge [4:03] agents by 90% because agents were able [4:06] to catch mistakes and share them with [4:08] the next iteration of agents, which also [4:11] led to better token efficiency, and [4:13] lower costs, and better latency because [4:15] they started deploying memory systems. [4:20] So, I want to talk a bit about the [4:22] requirements that we kept in mind uh, [4:24] that we discovered while talking to [4:25] customers and building this. [4:28] The first and most important is memory [4:30] needs to be built to maximize [4:32] intelligence by default. [4:34] Agent builders have uh, been designing [4:36] memory systems for a while. I mean, we [4:38] ourselves launched Claude.md uh, [4:40] originally with Claude code, I think uh, [4:42] about a year and a half ago, and this [4:44] was a pretty constrained early version [4:46] of memory where an agent could leave [4:48] notes for itself. Sometimes the user [4:50] would also leave notes in the same [4:52] memory file, and we also launched [4:54] something like the memory tool uh, [4:56] within our SDKs, which was a pretty [4:58] well-specified tool call with specific [5:01] parameters and output formats that uh, [5:04] API builders could use. [5:06] As agents have improved, we've tried to [5:08] get more and more out of Claude's way [5:11] and delegate more of this [5:12] decision-making to Claude without [5:14] over-constraining um, the design of [5:16] these harnesses. [5:18] And as we did with skills, we kind of [5:20] came to the conclusion that, "Hey, we [5:22] know that agents are able to manage a [5:24] virtual environment and manage their own [5:26] file system, so why can't we go the same [5:28] direction with memory?" [5:30] Memory in Claude-managed agents models [5:33] memory as a file system to Claude, a [5:35] series of files with a specific [5:37] hierarchy and format that Claude can [5:39] manage and update on its own. [5:42] It can use familiar tools like Bash and [5:45] Grep to update this memory, to keep it [5:47] organized and to constantly change it as [5:50] it starts working on a task. [5:52] Now this this also tracks with what [5:54] we're seeing in the latest models. With [5:56] Claude Opus 4.7, which we just launched [5:59] last month, we saw that it was [6:00] state-of-the-art at file system-based [6:02] memory. That means it's a lot better at [6:05] discerning what content to put into [6:07] memory, what's worth remembering. It's [6:09] better at figuring out what's the right [6:11] structure for memory, how many files [6:13] should I split memory into, how do I [6:15] keep it organized inside of a file [6:17] system. And ultimately it all does this [6:20] with just Bash tools and grep tools that [6:22] already make Claude so good at agentic [6:24] coding. [6:29] The other thing that we had in mind when [6:31] designing memory is that it needs to [6:33] scale with the multi-agent systems that [6:35] we're going to be building over the [6:36] coming months. [6:38] Multi-multi-parallel agents is something [6:40] that we're already kind of starting to [6:41] do with Claude Code. There's a lot of uh [6:43] by-product that have like 10 or 15 [6:46] Claude Code sessions running at the same [6:47] time, and we're starting to see this in [6:49] an enterprise setting as well where [6:51] enterprises, including Anthropic, have [6:53] hundreds or sometimes even thousands of [6:55] agents running in parallel interacting [6:58] with the same set of shared state and [7:00] the same shared memory. [7:02] So there's a couple of properties that [7:03] come out of this. [7:04] One is we want to give agents the [7:06] ability to mix and match between the [7:08] session and the work that it's doing [7:11] and the set of memory stores that it has [7:13] access to. So one property of memory and [7:16] managed agents is permission scopes. The [7:19] ability for one agent to have read-only [7:21] access to one memory store, and maybe [7:24] that memory store is organization-wide [7:26] knowledge, uh a set of best practices, a [7:29] runbook for how to deal with these [7:31] common tasks. And then it has read-write [7:33] memory for another memory store. So [7:36] maybe that's another one where it has [7:37] working memory that's a lot more [7:39] specific and frequently updated based on [7:41] the work it's doing. [7:44] The other property that came out of this [7:46] was concurrency. If there are hundreds [7:48] or thousands of agents interacting at [7:50] the same time with the same set memory [7:52] state, it needs to be able to know that [7:55] it's not going to clobber the memory or [7:56] overwrite it as it continues working. [7:58] So, we implemented optimistic [8:00] concurrency where one agent can [8:03] essentially use a content hash to [8:05] check if it's going to overwrite another [8:07] agent's memory before it actually makes [8:09] an update. [8:13] From talking to customers, the final and [8:15] most important property from all of this [8:18] is about developer and enterprise [8:20] control for actual production agents. A [8:23] couple of things came out of this. The [8:25] first and probably most sought-after [8:27] property is version history. It's the [8:29] ability for the developers building with [8:32] managed agents to see an entire audit [8:35] log of every time memory was updated and [8:38] to actually even give agents access to [8:40] the same audit log in the future so they [8:42] can keep track of what change was made [8:44] and when. [8:46] It's also attribution metadata to say [8:49] what agent made an update, what time did [8:51] it make that update, what session made [8:53] that specific change, and to go super [8:54] granularly so this is predictable and in [8:57] developers control. [9:00] The other property that came out of this [9:02] was a standalone API. We talked to a lot [9:05] of customers that are building the spoke [9:07] systems outside of managed agents to [9:09] manage and curate their memory and keep [9:11] it up to date. We talked to customers [9:13] that do PII scanning to make sure that [9:15] memory doesn't have sensitive content [9:17] that shouldn't be in there. We also [9:19] talked to customers that wanted to clean [9:21] up memory in their own separate pipeline [9:23] or to clone it into external systems. [9:26] So, we didn't want to lock them in into [9:27] a specific system that was only [9:29] available to managed agents. We built [9:31] this portable API so they can go and [9:32] control these additional things on their [9:34] own. [9:39] So, taking a step back, we've started to [9:41] form this picture of the different [9:43] layers that we need to work in as we [9:45] build a frontier memory system. [9:47] We've talked about the storage layer, [9:49] which is where the data is actually [9:51] stored, what kind of metadata and [9:54] attribution data we're leaving alongside [9:56] of it. [9:57] We've talked about the structure and the [9:59] content layer. This is things like our [10:01] decision to model files uh memory as [10:03] files in a file system. And earlier um [10:06] with skills as a form of procedural [10:07] memory that have a pretty lightweight [10:09] spec that say, "Hey, here's how you can [10:11] actually learn how to do this new [10:13] capability and equip yourself with new [10:15] knowledge." [10:17] And then there's the process layer. This [10:18] is things like how often is memory [10:21] actually updated, what triggers updates [10:23] to that memory, and what sources does it [10:26] use to decide what changes to make to [10:28] memory and have new things to learn. [10:32] And we think that agent memory, the API [10:34] that we've been discussing, solves part [10:35] of this. Um but as we started to scale [10:38] this up into these more complex [10:40] multi-agent systems, we also saw a bunch [10:42] of limitations. We saw cases where [10:45] memory was sessions were kind of missing [10:47] learnings that other agents and other [10:49] sessions had already kind of figured out [10:51] on their own. We saw these common [10:53] mistakes and these shared patterns [10:55] across multiple agents working in the [10:57] same environment. [10:59] And we also saw that they weren't super [11:00] efficient at keeping up this large-scale [11:03] memory store and keeping it up to date [11:05] in a holistic and efficient way. They [11:06] were kind of siloed into the specific [11:08] task that they were working on. [11:11] So, for the past couple of months, we've [11:12] been experimenting with a couple of [11:14] different types of processes to kind of [11:17] supplement this with. And we landed on [11:20] one. Um we call this process dreaming, [11:22] and today we're launching this in [11:24] research preview in the managed agents [11:26] API. [11:29] Dreaming is a process that looks for [11:30] patterns and mistakes across your recent [11:33] agent sessions and their transcripts and [11:35] automatically produces organized and [11:38] up-to-date memory content. [11:42] We've worked with a few customers in [11:43] early testing and for example Harvey [11:46] when they deployed dreaming in one of [11:48] their legal benchmarks which tests out a [11:49] pretty realistic legal scenario, they [11:52] saw a six-times increase in the task [11:55] completion rate for one of their legal [11:56] scenarios. And we're really excited to [11:58] see how other customers use this uh when [12:01] they start testing out this research [12:02] preview. [12:04] So, let's talk a bit about why we got [12:06] excited about dreaming in the first [12:08] place and some of the design and harness [12:10] considerations we kept in mind as we [12:12] designed it. [12:14] So, how does dreaming work? It's a batch [12:17] asynchronous process that runs [12:19] separately from the work that you're [12:20] doing uh within a specific session [12:23] that's working on a specific task. [12:25] You can kick off dreaming periodically [12:27] um using our console or via or API on [12:30] kind of a cron basis or you can plug it [12:33] in using our API into an existing [12:35] process. For example, some customers [12:37] kick off dreaming once their agents have [12:39] finished a task and are spinning down [12:41] and want to save those learnings to the [12:42] memory state. [12:44] And dreaming comprehensively looks [12:46] through recent transcripts, looks for [12:48] common mistakes, things that a bunch of [12:50] agents are doing like a failed tool call [12:52] or strategies that are working out for [12:54] them, and finds opportunities to update [12:56] the memory state that will improve it in [12:58] the future. And it produces this updated [13:01] memory state that you can then apply [13:02] immediately to your memory store or [13:04] maybe you want to run some checks and do [13:06] some manual review um which you can do [13:08] via the API. [13:10] The ultimate goal of dreaming is [13:12] continuous self-learning and [13:13] self-improvement where the next day's [13:15] agents automatically get better based on [13:18] the learnings and the work of the [13:19] previous day's experience. [13:26] We're excited about dreaming from a [13:28] design and research perspective for a [13:30] couple of reasons. The first property [13:33] is, compared to the memory APIs we've [13:35] been talking about previously, dreaming [13:37] is out-of-band. It happens outside the [13:39] context of an agent working on a [13:41] specific session or a specific task. [13:44] And this has a couple of benefits. The [13:46] The first that is that it's a really [13:48] good fit for multi-agent systems. [13:52] When a single agent is reading and [13:53] writing memory, it has the perspective [13:55] of itself, of its own context, and of [13:57] its task. But dreaming lets us go kind [13:59] of a step above that and look at [14:01] multiple agents at the same time to find [14:04] these shared patterns and learnings that [14:06] a single agent might not learn or notice [14:08] from its own limited perspective. [14:11] From a harness design perspective, we've [14:14] also found consistently that it's [14:16] important for agents to have really [14:17] discrete and clear objectives as they [14:20] start working on a task. So, dreaming [14:22] really lets us separate out this new [14:24] objective of memory quality because we [14:27] think over the coming months, memory is [14:29] going to be increasingly important and [14:31] load-bearing to the actual outcomes and [14:33] the work that agents are doing. [14:35] So, this lets us separate the memory [14:37] quality objective from the task [14:40] completion and task performance [14:41] objective that a lot of agents already [14:43] have today. [14:45] And again, because dreaming is an [14:47] out-of-band process, it's in the [14:48] background, it does this without adding [14:51] any latency to the hot path of an [14:53] agent's existing task. [14:58] The other design perspective we had here [15:00] and thing that we wanted to enable, [15:01] which I'm very excited about, is [15:03] large-scale memory systems and how we [15:05] can use compute effectively to create [15:07] and curate these. [15:09] Today, most memory deployments are [15:11] pretty localized to a specific user or a [15:13] specific task or maybe a small team [15:16] that's working together. But agent [15:18] systems are quickly getting to [15:19] enterprise scale and again, within an [15:22] Anthropic and within other enterprises [15:24] that we work with they already have [15:25] hundreds or thousands of agents running [15:27] concurrently that share state. [15:30] So this effectively starts to turn into [15:31] a really large knowledge base as opposed [15:34] to just a simple memory store to to [15:36] store working context about a specific [15:38] task. [15:40] And to support this we need to find ways [15:42] to let Claude scale up memory systems to [15:44] be super large while still being up to [15:46] date and fresh and not too token [15:48] intensive. [15:50] Dreaming is a process that lets us do [15:52] this by essentially following similar [15:54] scaling laws of using additional compute [15:56] and additional effort to keep these [15:58] memory systems organized. [16:00] One way to think about this is how we [16:02] consider test time compute or thinking [16:04] models from a couple of years ago where [16:07] giving models the ability to go explore [16:09] and try different things and especially [16:11] spend more tokens leads to a lot better [16:14] final outcomes on the task they're [16:15] working on. And dreaming is a similar [16:17] thing that lets a dreaming agent spend [16:19] more tokens to keep these systems well [16:22] organized and up to date. [16:25] Another perspective we have here is like [16:26] a search system where there's this [16:29] upfront effort to kind of produce this [16:31] high-quality up-to-date index that then [16:34] is then used at retrieval time or search [16:36] time to get the latest results super [16:38] efficiently and performatively. So this [16:41] is something that dreaming also lets us [16:43] do by creating this index upfront and [16:45] then curating it so that all the [16:47] downstream agents can use it. And [16:49] effectively lets us amortize this effort [16:51] across all of those agents that are [16:53] reading from a memory store. [16:58] So now with memory and dreaming in the [17:00] managed agents API we start to build [17:02] this picture of what we think of as a [17:05] frontier memory system at least so far. [17:08] Memory on the left side is a primitive [17:10] for agents to immediately in real time [17:12] read and write things and remember [17:14] things as as working on a task. [17:16] And dreaming is a comprehensive process [17:18] built on top of that to verify the state [17:21] of memory, [17:22] to organize it, and to enrich and [17:24] backfill it with additional information [17:27] um that based on the tasks that the [17:29] agents are doing during a day. [17:31] Dreaming is kind of the bridge between [17:33] these more intermediate memory systems [17:35] and these larger scale knowledge bases [17:38] that again we think are going to be [17:39] really prominent over the next few [17:40] months. [17:43] So, let's walk through a [17:46] quick demo. [17:49] What we're looking at here is a SRE [17:52] agent. Let me make sure this starts. [17:54] There you go. That is looking at alerts [17:56] that are coming in and it's reacting [17:59] based on those alerts, spinning up [18:00] specific agents that either do a bunch [18:03] of triage work, maybe sometimes it spin [18:05] up spins up an agent to go submit PRs. [18:08] And each of these agents are equipped [18:10] with a couple of memory stores. [18:12] We can see that it has an org-wide [18:14] knowledge memory store. It has an SRE [18:17] and a code base memory store. [18:19] And so if we click into the org-wide [18:21] knowledge memory store, we can see it's [18:22] read-only. It's a set of, let's say, [18:25] runbooks and SLO guidelines. [18:27] Um it it points the agents to the [18:29] specific owners that they might need to [18:31] go ping. And it's something that doesn't [18:33] get updated very often. We don't want [18:34] agents necessarily to be going and [18:36] making changes as they work. [18:38] Now, there's also the SRE memory store [18:40] that's read-write. And of course the SRE [18:42] agents are able to constantly make [18:45] changes to this as they react and learn [18:47] from the environment around them. [18:49] So, we see this alert, this P1 that's [18:51] coming in from the dispatch service, and [18:53] we spin up this SRE agent um that goes [18:56] and starts to kick off an investigation. [18:58] It goes and investigates the CPU [19:00] utilization. Um maybe it goes and checks [19:02] out some of the traffic patterns and [19:04] queries for some of the recent PRs that [19:06] have gotten deployed. [19:07] It writes down these learnings um if we [19:10] click into the SRE memory store and [19:12] notes these in a new diff that gets [19:14] updated in that memory store. [19:16] Now, a couple minutes later, that same [19:17] alert gets paged again, and a different [19:20] SRE agent spins up with access to the [19:22] same memory store. [19:23] The first thing it does is it sees that [19:25] note within its memory store that says, [19:27] "Hey, we already did this investigation. [19:28] Here's what we found. Here's a way you [19:30] can short-circuit what you're looking [19:31] at." And ultimately, it saves um the a [19:34] bunch of time that it would have spent [19:36] going and investigating the same thing. [19:38] So, we see an immediate token efficiency [19:40] gain and an intelligence gain since it [19:42] now knows um what else it can go [19:45] investigate. [19:47] Now, this is great, um but we want to [19:48] actually be able to deploy these in an [19:50] enterprise and actually have reliability [19:52] and see what decision-making led to [19:54] certain things um certain outcomes. So, [19:57] if we click into the memory store, we [19:58] can see it has version history. It says, [20:01] "Every single time an update was made to [20:02] this." We can actually go back in time [20:04] and see what changes were made. [20:07] We can also see which agent made that [20:08] change. When was it written? And we also [20:10] have this little precondition hash, [20:12] which is again what lets us do this [20:14] optimistic concurrency to say, "Hey, I [20:16] made this change. Let's actually verify [20:17] it is what it is before I go and [20:19] override it." [20:21] So, we've been talking about agent [20:23] memory, but let's now see how dreaming [20:26] can now make this a more holistic and [20:28] up-to-date memory system. So, we'll go [20:31] and um pivot over to the cloud console, [20:35] where it actually reflects the exact [20:36] state of what we're looking at in the [20:38] API. It's the set of memory stores that [20:40] we've created, and we'll click into the [20:42] team SRE memory store, which again [20:44] reflects the latest state of memory that [20:45] we had written. [20:47] If we go and navigate to the dreaming [20:49] tab, specifically, [20:51] we can kick off a dreaming job where we [20:53] say, "Hey, I want to go and update and [20:55] create this specific memory store, [20:57] and I want to look at a bunch of the [20:59] sessions um that we've been looking at [21:00] for the past 7 days. These are all the [21:02] sessions that touched this memory store, [21:04] and we We to start a dreaming job to [21:06] look over those. [21:08] So, I'll click into the dream and we can [21:11] see some of the work that it's doing [21:12] under the hood. It says, "Hey, here are [21:14] some of the input sessions that it's [21:15] going to go and spend time looking into, [21:17] look through the transcripts." And it [21:18] spins up within the cloud console an [21:21] actual session where you can go and see [21:22] what's happening. It's looking at the [21:24] specific transcript entries, and it's [21:26] going to spin up a bunch of sub agents [21:28] that go and look through those [21:29] transcripts, try to identify those [21:31] learnings, and then produce that updated [21:33] memory state. [21:35] So, we'll jump ahead a few minutes and [21:37] look at the completed dreaming job to [21:39] see what the output was. [21:41] It produces a diff, which is a set of [21:44] updated files that it's going to apply [21:45] to this memory store. [21:47] The first one is an update to this [21:49] dispatch latency note that we were [21:50] looking at in the demo earlier. [21:52] It said, "Hey, a bunch of these agents [21:54] were triggered exactly 60 seconds after [21:57] an upstream spike in CPU realization." [22:00] And it kind of figures out based on that [22:01] pattern that there might be some retry [22:03] logic that's getting triggered that's [22:05] really inefficient and leading to a lot [22:07] of wasted time when we're actually [22:08] triaging this stuff. So, it identifies [22:10] that because each of the individual [22:12] agents aren't really noticing that [22:13] pattern. They don't know that other [22:15] agents are also seeing kind of that [22:16] 60-second pattern every single time, and [22:19] it leaves a note. And the goal with this [22:20] is future agents benefit from this [22:22] learning and can go figure this out more [22:24] efficiently. [22:26] It also does a deduplication and [22:27] creation step. It sees that there were [22:29] five of the same entries from previous [22:32] agents that were working with this [22:33] memory store, and it consolidates [22:35] consolidates that into a single entry. [22:37] It removes a stale entry that's no [22:39] longer valid that it saw in the [22:41] transcript that is no longer relevant. [22:44] And then it adds this verification note. [22:45] It says, "At this time, based on this [22:47] transcript I just looked at, this memory [22:49] is actually accurate. I was able to [22:51] verify it based on the work that the [22:53] agent was doing, and therefore you can [22:54] rely on it in the next day when you [22:56] start using the same memory store." [22:59] So, there's that verification backfill [23:01] organization steps that we think memory [23:03] and dreaming are really useful for. [23:05] Um and so with this demo, what we've [23:07] kind of seen is how we can actually [23:09] build production agents using the memory [23:12] and dreaming APIs in the managed agents [23:14] API. [23:15] And to close out, I think that over the [23:17] next couple of months, we're going to [23:18] start seeing agents that run for days or [23:21] many, many hours at a time. And I think [23:24] that memory is going to be an really [23:26] important part of that system and what [23:28] makes it ultimately possible. [23:30] So, I'm really excited to see what [23:31] everyone builds with memory and dreaming [23:33] in the Cloud Managed Agents API. [23:35] Um and you should get started today. [23:37] Thank you. [23:39] >> Woo!