- Ravi, who leads the API knowledge team at Anthropic, introduces two new features for Claude Managed Agents — memory and dreaming — that let agents learn over time and improve from one task to the next.
- Memory is modeled as a file system so Claude can use familiar tools (bash, grep) to read, update, and organize what it saves, with multi-agent support (read-only and read-write scopes), optimistic concurrency control, version history, attribution, and a standalone API.
- Dreaming is a decoupled, out-of-band batch process that analyzes session transcripts across agents, finds patterns in mistakes and inefficiencies, and produces a verified, better-organized snapshot of memory — with customers like Harvey seeing a six-times increase in completion rates on a legal benchmark.
Memory and dreaming for self learning agents
- The path to memory ran through MCP (2024, external tools/data), Claude Code and the Agent SDK (2025, lowering the barrier to building agents), skills (a generic abstraction for new capabilities), and Claude Managed Agents (reliably running agents); the through line is agents doing more over longer horizons, with a 2025 METR study finding task length doubling every seven months.
- Memory lets agents carry learnings forward so performance improves from task to task, environment to environment, and agent to agent — including swarms of agents maintaining a shared understanding of their organization.
- Memory for Claude Managed Agents is a frontier system built to maximize intelligence out of the box; built with partner teams, Rakuten saw a 97% decrease in first-pass errors and WiseDocs reduced common issues using cross-session memory, with the common feedback that the primitive lets teams focus on the product, not the infra.
- Memory is modeled as a file system because Claude (especially Opus 4.7, state-of-the-art at file-system-based memory) is great at navigating file systems with bash and grep and at discerning which context to save and how to structure it — the principle being to "get out of Claude's way" and "let it cook."
- For multi-agent use, memory supports read-only scopes (e.g. infrequently updated org-wide memory all agents can read) and read-write scopes (granular stores agents write freely), creating a scalable hierarchy, with optimistic concurrency control preventing agents from clobbering each other's writes.
- Memory includes enterprise controls: version control creates an audit trail, developers can diff between versions, there's attribution for which agent wrote which part, and a standalone API offers CRUD plus enterprise operations like exports and redactions.
- As the memory-writing pattern scaled to multi-agent use, agents repeated the same mistakes and inefficiencies and updated memory in a locally (not globally) optimal way with duplication and fragmentation — so a feedback loop in the processing layer, called dreaming, was built to fix this.
- Dreaming is a batch, out-of-band process (decoupled from the agent loop, adding no latency) that analyzes session transcripts, inspects memory state, and proposes verified optimizations; it can run ad hoc, nightly, hourly, or be triggered by events; Harvey saw a six-times increase in completion rates on a legal benchmark, and dreaming itself is built on Claude Managed Agents, spinning off sub-agents to analyze transcripts in parallel.
Memory — A file-system-modeled system that lets Claude Managed Agents carry learnings forward and improve from task to task.
Dreaming — An out-of-band batch process that analyzes transcripts across agents and sessions to find patterns and produce a better-organized memory snapshot.
Claude Managed Agents — Anthropic's platform for reliably running agents, which memory and dreaming are built for and on.
Read-only scope — A memory store, e.g. org-wide knowledge, that all agents can read but is updated infrequently.
Read-write scope — A more granular memory store that agents can read and write freely.
Optimistic concurrency control — A model preventing agents from overwriting each other's memory changes.
Out-of-band — Describing dreaming as decoupled from the agent loop, off the hot path, so it adds no latency.
Skills — A basic, flexible format for bolting new capabilities onto a model, the inspiration for memory's file-based design.
MCP — Model Context Protocol (2024), giving models principled access to external tools and data.
Hello. Thank you for joining us today. I'm excited to kick things off on the breakout stage. My name is Ravi and I lead the API knowledge team within platform at Anthropic. Since joining Anthropic last year, my focus has been creating the building blocks for agents to interact with many forms of knowledge, ranging from the context window itself to skills, files, and even content on the web. And we recently released two features that I'm most excited about: memory and dreaming. We now have the building blocks for agents to learn over time and improve from one task to the next. I'll talk about why we think memory is important, how we designed it, and we'll close out with dreaming, our new frontier memory feature.
But first, a quick timeline of milestones that got us here. The important thing is models have been improving and agents are capable of completing tasks that take many, many hours and are increasingly complex. So in 2024, we released Model Context Protocol, MCP. This gave models access to external tools and data in a principled way. In 2025, we released Claude Code and the Agent SDK, which lowered the barrier to using and building agents — which, as an aside, blows my mind that that was in 2025. It honestly feels like a lifetime ago. Later that year, we launched skills, which gave models a generic abstraction for unlocking and effectively bolting on new capabilities to complete specific tasks. Last month, we released Claude Managed Agents, a platform for reliably running agents that takes care of the hard parts. Now, the important through line here is that agents can do more, and they can operate over longer and longer time horizons. In 2025, METR released a study saying the length of tasks that agents can complete is doubling every seven months. And we're seeing this happen. But managing context over long-horizon tasks is still a work in progress, and that's where memory comes in.
Memory lets agents learn. It lets agents carry forward learnings from their previous tasks. In the simplest sense, imagine a set of tasks — task one, task two, task three, and so on. The goal is for performance to improve from one task to the next. In the base case, without something like memory, performance on each task might be similar, because every agent is just starting from the same slate. In the optimal case, performance improves from task one to two, task two to three, and so on. That's the goal: learning from task to task, but also from environment to environment, and agent to agent. So with memory, agents can learn from common strategies and previous mistakes. They can learn from the tools they have access to, or code bases and files. And finally, they can transfer these learnings to and from other agents. Think swarms of agents contributing to and maintaining a shared understanding of the organization they work in. This is the dream.
So we recently launched memory for Claude Managed Agents. This is a major step towards this vision. It gives developers a frontier memory system that is built to maximize intelligence out of the box, and it supports multi-agent systems all with enterprise control and observability. We built memory in partnerships with several teams that are using managed agents, and the results speak for themselves. Rakuten saw a 97% decrease in first-pass errors in agents deployed in production. WiseDocs reduced common issues using cross-session memory in their document verification pipeline. The through line here, and the common feedback we get, is that our memory primitive allows teams to focus on building the product, not the infra — all while reaping the benefits of increased intelligence that comes along with better memory.
Now, you might be thinking, is memory really new? Rightfully so. Memory is a concept that's not entirely new, but our approach for it with agents has greatly evolved. Previously, we built memory focusing on capabilities in the harness. So you might be familiar with Claude.md for Claude Code, or dedicated memory tools in the SDKs. But one pattern we're seeing is that as models improve, we really just want to get out of Claude's way, similar to what we did with skills. Skills was a very basic format that was highly flexible, and it created endless possibilities, and the model understood how to operate with it. With memory, we've leaned into that same direction with files.
Let's talk about some of the capabilities that we designed memory around. With the current set of models, we know a few things. Models and Claude are great at navigating virtual environments and a file system. Claude is also very capable at using familiar tools like bash and grep to read, update, and organize files. Opus 4.7, which we launched last month, is a state-of-the-art model at file-system-based memory. It's increasingly capable of discerning which context is most important to save for its future self, and how it should be structured and represented. So with memory, we've modeled it as a file system to Claude. The key principle is getting out of Claude's way and letting it use the capabilities it already has that are very strong. Or as we like to say, let it cook.
But we've talked about Claude's memory capabilities within the context of a single agent. We want it to work across multiple agents that are operating in the same environment at the same time, or maybe across environments. This introduces new requirements. For example, letting multiple sessions share the same memory store at the same time. And maybe they want different scopes. So we offer read-only scopes and read-write scopes. For example, you could have organization-wide memory that's read-only and updated fairly infrequently, accessible by all agents. And the same set of agents can have access to more granular memory stores that they can read and write freely. This creates a hierarchy and allows the memory system to really scale. Now, to combat write conflicts, to make sure that one agent isn't clobbering another's writes, we employed an optimistic concurrency control model to avoid agents overriding each other's changes.
Last but not least, memory needs to work for real production agents. This means enterprise-grade controls. Version control creates an audit trail as agents make changes. Developers can see how memory evolves over time. They can even diff between versions. And there's attribution to see which agent wrote which part of the memory. One of the most important pieces is that memory has a standalone API. It enables developers to manage their memory from anywhere. Teams are building their systems in many different environments, so they can use memory via these APIs, which provide standard CRUD operations, but also more enterprise-focused operations like exports and redactions.
So we've covered three key components of a memory architecture. One, we started with the storage layer, which is how the data is managed itself and how changes are tracked. Next, the structure of memory, optimizing it in a format that allows Claude to get the most out of it. And finally, Claude-driven processing for updating the memory. Now, let's stop at that processing point. Agents writing memory as they work is very key to the processing layer. Think of it as taking notes while you're doing something. But as we scaled up this pattern to more complex multi-agent use cases, we started seeing some limits across different sessions. We started seeing some common patterns. For example, agents were prone to making many of the same mistakes, and they learned from their mistakes independently. Agents also displayed some of the same patterns of inefficiency. And the general theme was memory was being updated in a locally optimal way, but it wasn't globally optimal. In some cases, there was duplication or fragmentation. So we started thinking really deeply about this problem, and in the last couple of months, we built a feedback loop in the processing layer that combated some of these problems. Now, I've said it a couple times, but this time I mean it. This really is the dream. We call this process dreaming.
Dreaming is available in research preview right now, and it can be used with managed agents. It's a process that looks for patterns in mistakes across agents and sessions. And it automatically organizes and curates their memory. Customers like Harvey saw a six-times increase in completion rates for their legal benchmark with dreaming. And we're actively seeing other usage of dreaming. A quick overview of how dreaming works: it is a batch process. It runs out of band from sessions. It's completely decoupled. Think of it like a feedback loop. Agents write memories and dreaming refines them, and this process repeats. Dreaming can be kicked off ad hoc, nightly, hourly, or it can even be triggered by events like the end of a session. It's all controlled via API, so it's very flexible. Each dreaming run analyzes session transcripts. It inspects the existing state of memory and it proposes optimizations to the memory in scenarios where sessions were inefficient, made mistakes, or needed improved guidance. And the output is a verified, better-organized snapshot of memories that agents can choose to adopt. Dreaming truly enables continuous self-learning. It closes the loop on memory.
I mentioned out of band. The out-of-band component of dreaming is really critical. Creating a process that's decoupled from the underlying agent loop has benefits. For one, this architecture makes it useful for multi-agent systems. Looking at cross-session, cross-agent transcripts discerns patterns that a single agent in isolation might struggle to identify. There's also benefits to having a dedicated dreaming harness. It allows for clearer objectives. Since dreaming is an independent process, there's no risk of agents needing to trade off between improving their memory quality or actually just completing their task objective. It's clean separation. And lastly, it doesn't add any latency to the agent. It's completely removed from the hot path.
So, zooming out, we now have a robust memory layer that can be shared across agents and environments instead of only within specific tasks or usage. We also have dreaming, a process that globally optimizes and reconciles memory across agents. The result is a capable memory system for organizational memory that is capable of scaling up both the size as well as the quality of memory. The way I think about it is sharing memory that's constantly improving across agents raises the floor for every agent. And dreaming raises it even further. If you really explode the size of this capability and you pull it all together, memory becomes a huge source of knowledge that Claude can use to understand the organization and the world that it's operating in.
One way to think about dreaming is like thinking models or test-time compute, where letting models spend some tokens to explore a problem on average produces better outcomes. With dreaming, agents are doing the same thing. They're spending some work up front to curate and produce higher-quality memory, and that pays dividends for all downstream agent performance. We believe that dreaming and memory form the basis of a frontier system. Memory on the left helps agents learn and remember from task to task. And dreaming on the right verifies, organizes, and enriches the memory. The way I think about it is dreaming is the bridge between memory as we know it today and organization-scale memory and knowledge.
Now, I'm going to flip over to a demo. This uses both dreaming and memory in practice. It's an agent platform for SREs. And everyone loves being on call, right? Here we have a system that looks at incoming alerts and pages. For some of them, it spins up agents that decide how to triage and fix the issues as they come up. It has access to a couple of memory stores. One is a read-only org-wide knowledge memory store. This contains things like the SLO policy or runbooks and on-call mappings — information that doesn't change very often, but is important for every agent. It also has access to read-write memory stores that are specific to the task at hand. We can dig into an interesting example here where an agent investigated and found the root cause of an alert. It put up a fix, and it noted in memory that a fix was in flight and it was incoming. And then the shared memory store can be read by subsequent sessions. So here we can see that when a similar issue arises, the downstream session already knows that a fix is in flight and it's able to act based on that information. I really think this is such a cool pattern because the — I was once an SRE in my career — and this really helps coordinate across all agents. It's really cross-session memory at work.
Now, for running in enterprises, an important piece here is audit logs and history. With memory, you can see the full version history. You can switch between different versions and you can also attribute the writes to specific sessions. There's also a precondition here, and that's the optimistic concurrency model to make sure that agents aren't clobbering each others' writes. Now we'll flip over to the Claude console. Here we see the list of underlying memory stores that we were using in that application. We'll go over to our team SRE memory store and you can see exactly the underlying files that were populated there. And we're going to head over to the Dreams tab. We're going to kick off a dream. This can also be done via the API but also in the UI. We're going to select the team SRE memory store and a batch of sessions from the last 7 days, so that's about five. And we're going to start dreaming.
As it begins, you can see it making progress. You can look at the dream and see that there are five input sessions, and then you'll see there's actually an output memory store that's being compiled. You can open the dreaming session. This is an important piece — dreaming itself is built on Claude Managed Agents. So it's a feature for Claude Managed Agents built on Claude Managed Agents itself. You can see that it spins off a series of sub-agents to analyze transcripts in parallel, and it has all the same UX as the rest of managed agents. We'll fast-forward to a completed dream session, and you can see the diffs on the memory store updates. In this example, we see that across sessions and across agents, there's a common pattern of an alert triggering 60 seconds after a CPU spike. This is a recurring pattern. So it starts to discern that there might be some issue with the retry behavior. It makes a note. The dreaming process makes a note and updates memory so that the next agent that sees this pattern can act on this information. And similarly it updates the triage log in a more holistic way rather than just being a rote log of all the events that happened. That's memory and dreaming at work.
So we'll flip back over to the slides and close out. With that demo we saw how we can build a production agent that uses memory and dreaming to self-improve the agents. This year I think is going to be a really big one. We're going to see agents run for longer and longer time scales — days, for example — and continuously building upon and improving their understanding and view of the world around them is very critical to unlocking that capability. I think memory systems are going to be a big part of what makes this behavior possible. So give it a try. I'm excited to see what everyone builds with it. And I'll be outside if you have more questions. Thank you.
TL;DR
- Ravi, who leads the API knowledge team at Anthropic, introduces two new features for Claude Managed Agents — memory and dreaming — that let agents learn over time and improve from one task to the next.
- Memory is modeled as a file system so Claude can use familiar tools (bash, grep) to read, update, and organize what it saves, with multi-agent support (read-only and read-write scopes), optimistic concurrency control, version history, attribution, and a standalone API.
- Dreaming is a decoupled, out-of-band batch process that analyzes session transcripts across agents, finds patterns in mistakes and inefficiencies, and produces a verified, better-organized snapshot of memory — with customers like Harvey seeing a six-times increase in completion rates on a legal benchmark.
Takeaways
- The path to memory ran through MCP (2024, external tools/data), Claude Code and the Agent SDK (2025, lowering the barrier to building agents), skills (a generic abstraction for new capabilities), and Claude Managed Agents (reliably running agents); the through line is agents doing more over longer horizons, with a 2025 METR study finding task length doubling every seven months.
- Memory lets agents carry learnings forward so performance improves from task to task, environment to environment, and agent to agent — including swarms of agents maintaining a shared understanding of their organization.
- Memory for Claude Managed Agents is a frontier system built to maximize intelligence out of the box; built with partner teams, Rakuten saw a 97% decrease in first-pass errors and WiseDocs reduced common issues using cross-session memory, with the common feedback that the primitive lets teams focus on the product, not the infra.
- Memory is modeled as a file system because Claude (especially Opus 4.7, state-of-the-art at file-system-based memory) is great at navigating file systems with bash and grep and at discerning which context to save and how to structure it — the principle being to "get out of Claude's way" and "let it cook."
- For multi-agent use, memory supports read-only scopes (e.g. infrequently updated org-wide memory all agents can read) and read-write scopes (granular stores agents write freely), creating a scalable hierarchy, with optimistic concurrency control preventing agents from clobbering each other's writes.
- Memory includes enterprise controls: version control creates an audit trail, developers can diff between versions, there's attribution for which agent wrote which part, and a standalone API offers CRUD plus enterprise operations like exports and redactions.
- As the memory-writing pattern scaled to multi-agent use, agents repeated the same mistakes and inefficiencies and updated memory in a locally (not globally) optimal way with duplication and fragmentation — so a feedback loop in the processing layer, called dreaming, was built to fix this.
- Dreaming is a batch, out-of-band process (decoupled from the agent loop, adding no latency) that analyzes session transcripts, inspects memory state, and proposes verified optimizations; it can run ad hoc, nightly, hourly, or be triggered by events; Harvey saw a six-times increase in completion rates on a legal benchmark, and dreaming itself is built on Claude Managed Agents, spinning off sub-agents to analyze transcripts in parallel.
Vocabulary
Memory — A file-system-modeled system that lets Claude Managed Agents carry learnings forward and improve from task to task.
Dreaming — An out-of-band batch process that analyzes transcripts across agents and sessions to find patterns and produce a better-organized memory snapshot.
Claude Managed Agents — Anthropic's platform for reliably running agents, which memory and dreaming are built for and on.
Read-only scope — A memory store, e.g. org-wide knowledge, that all agents can read but is updated infrequently.
Read-write scope — A more granular memory store that agents can read and write freely.
Optimistic concurrency control — A model preventing agents from overwriting each other's memory changes.
Out-of-band — Describing dreaming as decoupled from the agent loop, off the hot path, so it adds no latency.
Skills — A basic, flexible format for bolting new capabilities onto a model, the inspiration for memory's file-based design.
MCP — Model Context Protocol (2024), giving models principled access to external tools and data.
Transcript
Hello. Thank you for joining us today. I'm excited to kick things off on the breakout stage. My name is Ravi and I lead the API knowledge team within platform at Anthropic. Since joining Anthropic last year, my focus has been creating the building blocks for agents to interact with many forms of knowledge, ranging from the context window itself to skills, files, and even content on the web. And we recently released two features that I'm most excited about: memory and dreaming. We now have the building blocks for agents to learn over time and improve from one task to the next. I'll talk about why we think memory is important, how we designed it, and we'll close out with dreaming, our new frontier memory feature.
But first, a quick timeline of milestones that got us here. The important thing is models have been improving and agents are capable of completing tasks that take many, many hours and are increasingly complex. So in 2024, we released Model Context Protocol, MCP. This gave models access to external tools and data in a principled way. In 2025, we released Claude Code and the Agent SDK, which lowered the barrier to using and building agents — which, as an aside, blows my mind that that was in 2025. It honestly feels like a lifetime ago. Later that year, we launched skills, which gave models a generic abstraction for unlocking and effectively bolting on new capabilities to complete specific tasks. Last month, we released Claude Managed Agents, a platform for reliably running agents that takes care of the hard parts. Now, the important through line here is that agents can do more, and they can operate over longer and longer time horizons. In 2025, METR released a study saying the length of tasks that agents can complete is doubling every seven months. And we're seeing this happen. But managing context over long-horizon tasks is still a work in progress, and that's where memory comes in.
Memory lets agents learn. It lets agents carry forward learnings from their previous tasks. In the simplest sense, imagine a set of tasks — task one, task two, task three, and so on. The goal is for performance to improve from one task to the next. In the base case, without something like memory, performance on each task might be similar, because every agent is just starting from the same slate. In the optimal case, performance improves from task one to two, task two to three, and so on. That's the goal: learning from task to task, but also from environment to environment, and agent to agent. So with memory, agents can learn from common strategies and previous mistakes. They can learn from the tools they have access to, or code bases and files. And finally, they can transfer these learnings to and from other agents. Think swarms of agents contributing to and maintaining a shared understanding of the organization they work in. This is the dream.
So we recently launched memory for Claude Managed Agents. This is a major step towards this vision. It gives developers a frontier memory system that is built to maximize intelligence out of the box, and it supports multi-agent systems all with enterprise control and observability. We built memory in partnerships with several teams that are using managed agents, and the results speak for themselves. Rakuten saw a 97% decrease in first-pass errors in agents deployed in production. WiseDocs reduced common issues using cross-session memory in their document verification pipeline. The through line here, and the common feedback we get, is that our memory primitive allows teams to focus on building the product, not the infra — all while reaping the benefits of increased intelligence that comes along with better memory.
Now, you might be thinking, is memory really new? Rightfully so. Memory is a concept that's not entirely new, but our approach for it with agents has greatly evolved. Previously, we built memory focusing on capabilities in the harness. So you might be familiar with Claude.md for Claude Code, or dedicated memory tools in the SDKs. But one pattern we're seeing is that as models improve, we really just want to get out of Claude's way, similar to what we did with skills. Skills was a very basic format that was highly flexible, and it created endless possibilities, and the model understood how to operate with it. With memory, we've leaned into that same direction with files.
Let's talk about some of the capabilities that we designed memory around. With the current set of models, we know a few things. Models and Claude are great at navigating virtual environments and a file system. Claude is also very capable at using familiar tools like bash and grep to read, update, and organize files. Opus 4.7, which we launched last month, is a state-of-the-art model at file-system-based memory. It's increasingly capable of discerning which context is most important to save for its future self, and how it should be structured and represented. So with memory, we've modeled it as a file system to Claude. The key principle is getting out of Claude's way and letting it use the capabilities it already has that are very strong. Or as we like to say, let it cook.
But we've talked about Claude's memory capabilities within the context of a single agent. We want it to work across multiple agents that are operating in the same environment at the same time, or maybe across environments. This introduces new requirements. For example, letting multiple sessions share the same memory store at the same time. And maybe they want different scopes. So we offer read-only scopes and read-write scopes. For example, you could have organization-wide memory that's read-only and updated fairly infrequently, accessible by all agents. And the same set of agents can have access to more granular memory stores that they can read and write freely. This creates a hierarchy and allows the memory system to really scale. Now, to combat write conflicts, to make sure that one agent isn't clobbering another's writes, we employed an optimistic concurrency control model to avoid agents overriding each other's changes.
Last but not least, memory needs to work for real production agents. This means enterprise-grade controls. Version control creates an audit trail as agents make changes. Developers can see how memory evolves over time. They can even diff between versions. And there's attribution to see which agent wrote which part of the memory. One of the most important pieces is that memory has a standalone API. It enables developers to manage their memory from anywhere. Teams are building their systems in many different environments, so they can use memory via these APIs, which provide standard CRUD operations, but also more enterprise-focused operations like exports and redactions.
So we've covered three key components of a memory architecture. One, we started with the storage layer, which is how the data is managed itself and how changes are tracked. Next, the structure of memory, optimizing it in a format that allows Claude to get the most out of it. And finally, Claude-driven processing for updating the memory. Now, let's stop at that processing point. Agents writing memory as they work is very key to the processing layer. Think of it as taking notes while you're doing something. But as we scaled up this pattern to more complex multi-agent use cases, we started seeing some limits across different sessions. We started seeing some common patterns. For example, agents were prone to making many of the same mistakes, and they learned from their mistakes independently. Agents also displayed some of the same patterns of inefficiency. And the general theme was memory was being updated in a locally optimal way, but it wasn't globally optimal. In some cases, there was duplication or fragmentation. So we started thinking really deeply about this problem, and in the last couple of months, we built a feedback loop in the processing layer that combated some of these problems. Now, I've said it a couple times, but this time I mean it. This really is the dream. We call this process dreaming.
Dreaming is available in research preview right now, and it can be used with managed agents. It's a process that looks for patterns in mistakes across agents and sessions. And it automatically organizes and curates their memory. Customers like Harvey saw a six-times increase in completion rates for their legal benchmark with dreaming. And we're actively seeing other usage of dreaming. A quick overview of how dreaming works: it is a batch process. It runs out of band from sessions. It's completely decoupled. Think of it like a feedback loop. Agents write memories and dreaming refines them, and this process repeats. Dreaming can be kicked off ad hoc, nightly, hourly, or it can even be triggered by events like the end of a session. It's all controlled via API, so it's very flexible. Each dreaming run analyzes session transcripts. It inspects the existing state of memory and it proposes optimizations to the memory in scenarios where sessions were inefficient, made mistakes, or needed improved guidance. And the output is a verified, better-organized snapshot of memories that agents can choose to adopt. Dreaming truly enables continuous self-learning. It closes the loop on memory.
I mentioned out of band. The out-of-band component of dreaming is really critical. Creating a process that's decoupled from the underlying agent loop has benefits. For one, this architecture makes it useful for multi-agent systems. Looking at cross-session, cross-agent transcripts discerns patterns that a single agent in isolation might struggle to identify. There's also benefits to having a dedicated dreaming harness. It allows for clearer objectives. Since dreaming is an independent process, there's no risk of agents needing to trade off between improving their memory quality or actually just completing their task objective. It's clean separation. And lastly, it doesn't add any latency to the agent. It's completely removed from the hot path.
So, zooming out, we now have a robust memory layer that can be shared across agents and environments instead of only within specific tasks or usage. We also have dreaming, a process that globally optimizes and reconciles memory across agents. The result is a capable memory system for organizational memory that is capable of scaling up both the size as well as the quality of memory. The way I think about it is sharing memory that's constantly improving across agents raises the floor for every agent. And dreaming raises it even further. If you really explode the size of this capability and you pull it all together, memory becomes a huge source of knowledge that Claude can use to understand the organization and the world that it's operating in.
One way to think about dreaming is like thinking models or test-time compute, where letting models spend some tokens to explore a problem on average produces better outcomes. With dreaming, agents are doing the same thing. They're spending some work up front to curate and produce higher-quality memory, and that pays dividends for all downstream agent performance. We believe that dreaming and memory form the basis of a frontier system. Memory on the left helps agents learn and remember from task to task. And dreaming on the right verifies, organizes, and enriches the memory. The way I think about it is dreaming is the bridge between memory as we know it today and organization-scale memory and knowledge.
Now, I'm going to flip over to a demo. This uses both dreaming and memory in practice. It's an agent platform for SREs. And everyone loves being on call, right? Here we have a system that looks at incoming alerts and pages. For some of them, it spins up agents that decide how to triage and fix the issues as they come up. It has access to a couple of memory stores. One is a read-only org-wide knowledge memory store. This contains things like the SLO policy or runbooks and on-call mappings — information that doesn't change very often, but is important for every agent. It also has access to read-write memory stores that are specific to the task at hand. We can dig into an interesting example here where an agent investigated and found the root cause of an alert. It put up a fix, and it noted in memory that a fix was in flight and it was incoming. And then the shared memory store can be read by subsequent sessions. So here we can see that when a similar issue arises, the downstream session already knows that a fix is in flight and it's able to act based on that information. I really think this is such a cool pattern because the — I was once an SRE in my career — and this really helps coordinate across all agents. It's really cross-session memory at work.
Now, for running in enterprises, an important piece here is audit logs and history. With memory, you can see the full version history. You can switch between different versions and you can also attribute the writes to specific sessions. There's also a precondition here, and that's the optimistic concurrency model to make sure that agents aren't clobbering each others' writes. Now we'll flip over to the Claude console. Here we see the list of underlying memory stores that we were using in that application. We'll go over to our team SRE memory store and you can see exactly the underlying files that were populated there. And we're going to head over to the Dreams tab. We're going to kick off a dream. This can also be done via the API but also in the UI. We're going to select the team SRE memory store and a batch of sessions from the last 7 days, so that's about five. And we're going to start dreaming.
As it begins, you can see it making progress. You can look at the dream and see that there are five input sessions, and then you'll see there's actually an output memory store that's being compiled. You can open the dreaming session. This is an important piece — dreaming itself is built on Claude Managed Agents. So it's a feature for Claude Managed Agents built on Claude Managed Agents itself. You can see that it spins off a series of sub-agents to analyze transcripts in parallel, and it has all the same UX as the rest of managed agents. We'll fast-forward to a completed dream session, and you can see the diffs on the memory store updates. In this example, we see that across sessions and across agents, there's a common pattern of an alert triggering 60 seconds after a CPU spike. This is a recurring pattern. So it starts to discern that there might be some issue with the retry behavior. It makes a note. The dreaming process makes a note and updates memory so that the next agent that sees this pattern can act on this information. And similarly it updates the triage log in a more holistic way rather than just being a rote log of all the events that happened. That's memory and dreaming at work.
So we'll flip back over to the slides and close out. With that demo we saw how we can build a production agent that uses memory and dreaming to self-improve the agents. This year I think is going to be a really big one. We're going to see agents run for longer and longer time scales — days, for example — and continuously building upon and improving their understanding and view of the world around them is very critical to unlocking that capability. I think memory systems are going to be a big part of what makes this behavior possible. So give it a try. I'm excited to see what everyone builds with it. And I'll be outside if you have more questions. Thank you.