- Mahesh, a platform PM at Anthropic, presents memory as the next agent primitive (after MCP, harnesses, and skills) — the key to self-learning agents that improve from their own experience and from other agents in the same environment.
- Memory in Claude-managed agents models memory as a file system Claude manages with bash and grep, with permission scopes, optimistic concurrency, version history, attribution, and a portable standalone API for enterprise control.
- Anthropic launches "dreaming" in research preview: an out-of-band, asynchronous batch process that mines recent agent transcripts for patterns and mistakes, then produces organized, deduplicated, verified memory updates — Harvey saw a 6x increase in task completion on a legal benchmark.
Memory and dreaming for self-learning agents
- Memory is positioned as the primitive that unlocks continuous self-learning: agents can learn about tasks (success criteria, common mistakes, working strategies), their environments (codebases, files), and from other agents sharing the same environment.
- Memory in managed agents (public beta) is modeled as a file system — a hierarchy of files Claude manages with familiar bash and grep tools; Claude Opus 4.7 is state-of-the-art at file-system-based memory, better at deciding what to remember and how to structure it.
- The design maximizes intelligence by default by getting out of Claude's way, echoing the evolution from constrained CLAUDE.md notes and the memory tool toward delegating more decision-making to the model.
- Multi-agent scaling drove two properties: permission scopes (read-only org-wide knowledge vs read-write working memory) and optimistic concurrency (using a content/precondition hash so an agent verifies before overwriting another's memory).
- Enterprise control requirements produced version history (a full audit log of every memory update), attribution metadata (which agent, what time, what session), and a portable standalone API so customers can run PII scanning, cleanup, or cloning in their own pipelines.
- Dreaming is out-of-band and asynchronous — it runs separately from the hot path (no added latency), can be triggered via console or API on a cron basis or when agents spin down, and looks across multiple agents to find shared patterns a single agent's limited perspective would miss.
- Dreaming applies scaling-law thinking to memory quality: like test-time compute, it spends extra tokens to keep large knowledge bases organized and fresh, producing a diff that updates, deduplicates, removes stale entries, and adds verification notes — Rakuten dropped first-pass mistakes by 90%.
Memory (primitive) — An agent capability for continuous self-learning and context management over long-horizon tasks.
Dreaming — An out-of-band batch process that mines recent transcripts for patterns and mistakes to produce organized, up-to-date memory.
Managed agents API — Anthropic's cloud API for running agents with memory, dreaming, and enterprise controls.
File-system memory — Modeling memory as a hierarchy of files Claude manages with bash and grep.
Permission scopes — Per-memory-store access control, e.g. read-only org knowledge vs read-write working memory.
Optimistic concurrency — Using a content/precondition hash to verify before overwriting shared memory across many agents.
Version history — An audit log of every memory update with attribution metadata (agent, time, session).
Out-of-band — Running outside an agent's session context, so it adds no latency to the agent's active task.
Test-time compute — Spending more tokens/effort at run time to get better outcomes; the analogy used to motivate dreaming.
Self-learning agents — Agents that evolve and improve automatically based on prior tasks and shared experience.
Hello everyone, how's it going? Thanks for coming. My name is Mahesh and I'm a product manager on the platform team here at Anthropic. Over the past year and a half, I've gotten to work on primitives like MCP and skills. And today I want to talk about the primitive that I'm most excited about next, which is memory. I'll talk about why we think memory is so important and why we've been spending so much time on it at Anthropic, how we think about designing memory systems built for frontier agents, and I'm excited to also talk about dreaming, a brand new product that we're launching today in research preview in the managed agents API.
Model capabilities have improved really quickly over the last couple of years. Agents are capable of tasks that take many hours and can run for hours or almost days at a time. As models and agents have improved, we've also invested in building higher and higher-level capabilities and primitives that get out of those models' way and give them access to additional bits of their environment. For example, we launched MCP, which gives agents access to external tools and data. We launched harnesses that were really powerful, like Claude Code and the agent SDK. And in October, we launched skills, which let agents pick up brand new capabilities that either other agents have designed and shared with them or humans designed for them. Each primitive has let agents do increasingly powerful things for longer periods, but we still think something is unsolved, and that's continuous self-learning and context management over long-horizon tasks.
So memory is the next primitive. It's the thing I think will get us to self-learning agents that evolve and improve based on the tasks they're working on and their own experience. With memory, agents can learn about the tasks they work on — success criteria, common mistakes, strategies that are or are not working. They can learn about their environments — the codebases they interact with, the files and assets they keep up to date. And they can also learn from other agents in the same environment. They can share learnings, figure out what's going wrong elsewhere in a system, and incorporate that into their own memory. This last point is the one I've been most excited about. I think self-managed memory is going to be super important in large and complex multi-agent systems where a swarm of agents working in a similar environment on discrete tasks are essentially building up their own understanding and their own model of the worlds they're in over time.
To help get to this vision, we just launched memory in cloud-managed agents in public beta a couple weeks ago. This gives developers a frontier memory system that works out of the box to maximize intelligence by default, to support these systems of many agents running concurrently in the same environment, and most importantly, to give enterprises and developers the flexibility and control they need to run these in production. We've already heard from a bunch of teams building on this. Rakuten, for example, mentioned this helped them drop their first-pass mistakes in their internal knowledge agents by 90%, because agents were able to catch mistakes and share them with the next iteration of agents, which also led to better token efficiency, lower costs, and better latency.
I want to talk about the requirements we kept in mind. The first and most important is memory needs to be built to maximize intelligence by default. Agent builders have been designing memory systems for a while. We ourselves launched CLAUDE.md originally with Claude Code about a year and a half ago. This was a pretty constrained early version of memory where an agent could leave notes for itself, and sometimes the user would also leave notes in the same file. We also launched the memory tool within our SDKs, a pretty well-specified tool call with specific parameters and output formats. As agents have improved, we've tried to get more and more out of Claude's way and delegate more of this decision-making to Claude without over-constraining the design. As we did with skills, we came to the conclusion that agents are able to manage a virtual environment and their own file system, so why can't we go the same direction with memory? Memory in Claude-managed agents models memory as a file system to Claude — a series of files with a specific hierarchy and format that Claude can manage and update on its own. It can use familiar tools like bash and grep to update this memory, keep it organized, and constantly change it as it works on a task. This tracks with what we're seeing in the latest models. With Claude Opus 4.7, which we just launched last month, we saw it was state of the art at file-system-based memory. It's a lot better at discerning what content to put into memory, what's worth remembering, figuring out the right structure, how many files to split memory into, and keeping it organized — all with just bash and grep tools that already make Claude so good at agentic coding.
The other thing we had in mind is that it needs to scale with the multi-agent systems we're going to be building. Multi-parallel agents is something we're already starting to do with Claude Code — power users have 10 or 15 Claude Code sessions running at the same time — and we're seeing this in an enterprise setting where enterprises, including Anthropic, have hundreds or sometimes thousands of agents running in parallel, interacting with the same shared state and shared memory. A couple of properties come out of this. One is we want to give agents the ability to mix and match between the session and the memory stores it has access to. So one property is permission scopes — the ability for one agent to have read-only access to one memory store, maybe organization-wide knowledge, a set of best practices, a runbook for common tasks. And then it has read-write memory for another store, maybe working memory that's more specific and frequently updated. The other property is concurrency. If there are hundreds or thousands of agents interacting at the same time with the same memory state, it needs to know it's not going to clobber the memory as it works. So we implemented optimistic concurrency, where one agent can use a content hash to check if it's going to overwrite another agent's memory before it makes an update.
From talking to customers, the final and most important property is developer and enterprise control for actual production agents. The first and probably most sought-after property is version history — the ability for developers to see an entire audit log of every time memory was updated, and to give agents access to the same audit log so they can keep track of what change was made and when. It's also attribution metadata — what agent made an update, what time, what session made that change — to go super granularly so this is predictable and in developers' control. The other property is a standalone API. We talked to a lot of customers building bespoke systems outside managed agents to manage and curate their memory. We talked to customers that do PII scanning to make sure memory doesn't have sensitive content. We also talked to customers that wanted to clean up memory in their own separate pipeline or clone it into external systems. So we didn't want to lock them into a specific system. We built this portable API so they could control these additional things on their own.
Taking a step back, we've formed this picture of the different layers as we build a frontier memory system. There's the storage layer, where the data is actually stored, and what metadata and attribution data we leave alongside it. There's the structure and content layer — things like our decision to model memory as files in a file system, and earlier, skills as a form of procedural memory with a lightweight spec. And then there's the process layer — how often memory is actually updated, what triggers updates, and what sources it uses to decide what changes to make. Agent memory, the API we've been discussing, solves part of this. But as we started to scale this up into more complex multi-agent systems, we saw limitations. We saw cases where memory sessions were missing learnings that other agents and sessions had already figured out. We saw common mistakes and shared patterns across multiple agents in the same environment. And we saw they weren't super efficient at keeping up this large-scale memory store in a holistic way. They were siloed into the specific task they were working on.
So for the past couple of months, we've been experimenting with different types of processes to supplement this with, and we landed on one. We call this process dreaming, and today we're launching this in research preview in the managed agents API. Dreaming is a process that looks for patterns and mistakes across your recent agent sessions and their transcripts and automatically produces organized and up-to-date memory content. We've worked with a few customers in early testing — for example, Harvey, when they deployed dreaming in one of their legal benchmarks that tests a realistic legal scenario, saw a six-times increase in the task completion rate for one of their legal scenarios. We're really excited to see how other customers use this.
How does dreaming work? It's a batch asynchronous process that runs separately from the work you're doing within a specific session. You can kick off dreaming periodically using our console or API on a cron basis, or plug it in using our API into an existing process. For example, some customers kick off dreaming once their agents have finished a task and are spinning down and want to save those learnings. Dreaming comprehensively looks through recent transcripts, looks for common mistakes — things like a failed tool call — or strategies that are working, and finds opportunities to update the memory state to improve it in the future. It produces an updated memory state that you can apply immediately or run some checks and manual review on via the API. The ultimate goal of dreaming is continuous self-learning and self-improvement, where the next day's agents automatically get better based on the learnings and work of the previous day's experience.
We're excited about dreaming from a design and research perspective for a couple of reasons. First, compared to the memory APIs we've been talking about, dreaming is out of band. It happens outside the context of an agent working on a specific session or task. This has a couple of benefits. It's a really good fit for multi-agent systems. When a single agent is reading and writing memory, it has the perspective of itself, its own context, and its task. But dreaming lets us go a step above that and look at multiple agents at the same time to find shared patterns and learnings that a single agent might not notice from its own limited perspective. From a harness design perspective, we've found consistently that it's important for agents to have really discrete and clear objectives. Dreaming lets us separate out this new objective of memory quality, because over the coming months memory is going to be increasingly important and load-bearing to the actual outcomes. This lets us separate the memory quality objective from the task completion objective that a lot of agents already have. And because dreaming is out-of-band, in the background, it does this without adding any latency to the hot path of an agent's existing task.
The other design perspective is large-scale memory systems and how to use compute effectively to create and curate these. Today, most memory deployments are pretty localized to a specific user, task, or small team. But agent systems are quickly getting to enterprise scale. Within Anthropic and other enterprises, they already have hundreds or thousands of agents running concurrently that share state. So this starts to turn into a really large knowledge base as opposed to a simple memory store. To support this, we need ways to let Claude scale up memory systems to be super large while still being up to date and not too token intensive. Dreaming lets us do this by following similar scaling laws of using additional compute and effort to keep these systems organized. One way to think about this is test-time compute or thinking models — giving models the ability to explore and spend more tokens leads to better final outcomes. Dreaming is a similar thing that lets a dreaming agent spend more tokens to keep these systems well organized and up to date. Another perspective is like a search system, where there's upfront effort to produce a high-quality, up-to-date index that's then used at retrieval time to get the latest results efficiently. Dreaming creates this index upfront and curates it so all downstream agents can use it, amortizing the effort across all those agents.
So now with memory and dreaming in the managed agents API, we build this picture of a frontier memory system. Memory on the left side is a primitive for agents to immediately, in real time, read and write things and remember things as working on a task. And dreaming is a comprehensive process built on top of that to verify the state of memory, organize it, enrich it, and backfill it with additional information based on the tasks the agents are doing during a day. Dreaming is the bridge between these intermediate memory systems and the larger-scale knowledge bases that we think are going to be really prominent over the next few months.
Let's walk through a quick demo. What we're looking at here is an SRE agent that is looking at alerts coming in and reacting based on those alerts, spinning up specific agents that do triage work or sometimes submit PRs. Each of these agents is equipped with a couple of memory stores. We can see it has an org-wide knowledge memory store, an SRE memory store, and a codebase memory store. If we click into the org-wide knowledge memory store, it's read-only. It's a set of runbooks and SLO guidelines. It points the agents to specific owners they might need to ping, and it doesn't get updated very often — we don't want agents making changes as they work. There's also the SRE memory store that's read-write, and the SRE agents can constantly make changes as they react and learn. We see this alert, a P1 coming in from the dispatch service, and we spin up an SRE agent that kicks off an investigation. It investigates the CPU utilization, checks traffic patterns, queries for recent PRs that got deployed, and writes down these learnings in a new diff in that memory store. A couple minutes later, that same alert gets paged again, and a different SRE agent spins up with access to the same memory store. The first thing it does is see that note within its memory store that says, "We already did this investigation. Here's what we found. Here's a way to short-circuit what you're looking at." Ultimately it saves a bunch of time it would have spent investigating the same thing. So we see an immediate token efficiency gain and an intelligence gain. We want to deploy these in an enterprise and have reliability, so if we click into the memory store, it has version history. Every time an update was made, we can go back in time and see what changes were made, which agent made the change, and when it was written. We also have this precondition hash, which lets us do optimistic concurrency to verify it is what it is before overriding it.
We've been talking about agent memory, but let's see how dreaming can make this a more holistic, up-to-date memory system. We'll pivot to the cloud console, which reflects the exact state of what we're looking at in the API. We'll click into the team SRE memory store, which reflects the latest state of memory. If we navigate to the dreaming tab, we can kick off a dreaming job where we say we want to update this specific memory store and look at a bunch of the sessions from the past 7 days that touched this memory store. I click into the dream and we see the work it's doing under the hood. It says here are some of the input sessions it's going to look into. It spins up an actual session where you can see what's happening, looking at specific transcript entries, spinning up sub-agents to look through those transcripts, identify learnings, and produce the updated memory state. We'll jump ahead and look at the completed dreaming job. It produces a diff, a set of updated files to apply to the memory store. The first is an update to this dispatch latency note from the demo earlier. It says a bunch of these agents were triggered exactly 60 seconds after an upstream spike in CPU utilization, and figures out there might be some retry logic getting triggered that's really inefficient and leading to wasted time. It identifies that because each individual agent isn't noticing that 60-second pattern, and leaves a note so future agents benefit. It also does a deduplication and creation step — it sees five of the same entries from previous agents and consolidates them into a single entry. It removes a stale entry that's no longer valid. And it adds a verification note: "At this time, based on this transcript I just looked at, this memory is actually accurate. I was able to verify it based on the work the agent was doing, and therefore you can rely on it the next day." So there's that verification, backfill, and organization step that we think memory and dreaming are really useful for.
With this demo, we've seen how to build production agents using the memory and dreaming APIs in the managed agents API. To close out, I think that over the next couple of months, we're going to start seeing agents that run for days or many hours at a time, and memory is going to be a really important part of what makes that ultimately possible. So I'm really excited to see what everyone builds with memory and dreaming in the cloud managed agents API, and you should get started today. Thank you.
TL;DR
- Mahesh, a platform PM at Anthropic, presents memory as the next agent primitive (after MCP, harnesses, and skills) — the key to self-learning agents that improve from their own experience and from other agents in the same environment.
- Memory in Claude-managed agents models memory as a file system Claude manages with bash and grep, with permission scopes, optimistic concurrency, version history, attribution, and a portable standalone API for enterprise control.
- Anthropic launches "dreaming" in research preview: an out-of-band, asynchronous batch process that mines recent agent transcripts for patterns and mistakes, then produces organized, deduplicated, verified memory updates — Harvey saw a 6x increase in task completion on a legal benchmark.
Takeaways
- Memory is positioned as the primitive that unlocks continuous self-learning: agents can learn about tasks (success criteria, common mistakes, working strategies), their environments (codebases, files), and from other agents sharing the same environment.
- Memory in managed agents (public beta) is modeled as a file system — a hierarchy of files Claude manages with familiar bash and grep tools; Claude Opus 4.7 is state-of-the-art at file-system-based memory, better at deciding what to remember and how to structure it.
- The design maximizes intelligence by default by getting out of Claude's way, echoing the evolution from constrained CLAUDE.md notes and the memory tool toward delegating more decision-making to the model.
- Multi-agent scaling drove two properties: permission scopes (read-only org-wide knowledge vs read-write working memory) and optimistic concurrency (using a content/precondition hash so an agent verifies before overwriting another's memory).
- Enterprise control requirements produced version history (a full audit log of every memory update), attribution metadata (which agent, what time, what session), and a portable standalone API so customers can run PII scanning, cleanup, or cloning in their own pipelines.
- Dreaming is out-of-band and asynchronous — it runs separately from the hot path (no added latency), can be triggered via console or API on a cron basis or when agents spin down, and looks across multiple agents to find shared patterns a single agent's limited perspective would miss.
- Dreaming applies scaling-law thinking to memory quality: like test-time compute, it spends extra tokens to keep large knowledge bases organized and fresh, producing a diff that updates, deduplicates, removes stale entries, and adds verification notes — Rakuten dropped first-pass mistakes by 90%.
Vocabulary
Memory (primitive) — An agent capability for continuous self-learning and context management over long-horizon tasks.
Dreaming — An out-of-band batch process that mines recent transcripts for patterns and mistakes to produce organized, up-to-date memory.
Managed agents API — Anthropic's cloud API for running agents with memory, dreaming, and enterprise controls.
File-system memory — Modeling memory as a hierarchy of files Claude manages with bash and grep.
Permission scopes — Per-memory-store access control, e.g. read-only org knowledge vs read-write working memory.
Optimistic concurrency — Using a content/precondition hash to verify before overwriting shared memory across many agents.
Version history — An audit log of every memory update with attribution metadata (agent, time, session).
Out-of-band — Running outside an agent's session context, so it adds no latency to the agent's active task.
Test-time compute — Spending more tokens/effort at run time to get better outcomes; the analogy used to motivate dreaming.
Self-learning agents — Agents that evolve and improve automatically based on prior tasks and shared experience.
Transcript
Hello everyone, how's it going? Thanks for coming. My name is Mahesh and I'm a product manager on the platform team here at Anthropic. Over the past year and a half, I've gotten to work on primitives like MCP and skills. And today I want to talk about the primitive that I'm most excited about next, which is memory. I'll talk about why we think memory is so important and why we've been spending so much time on it at Anthropic, how we think about designing memory systems built for frontier agents, and I'm excited to also talk about dreaming, a brand new product that we're launching today in research preview in the managed agents API.
Model capabilities have improved really quickly over the last couple of years. Agents are capable of tasks that take many hours and can run for hours or almost days at a time. As models and agents have improved, we've also invested in building higher and higher-level capabilities and primitives that get out of those models' way and give them access to additional bits of their environment. For example, we launched MCP, which gives agents access to external tools and data. We launched harnesses that were really powerful, like Claude Code and the agent SDK. And in October, we launched skills, which let agents pick up brand new capabilities that either other agents have designed and shared with them or humans designed for them. Each primitive has let agents do increasingly powerful things for longer periods, but we still think something is unsolved, and that's continuous self-learning and context management over long-horizon tasks.
So memory is the next primitive. It's the thing I think will get us to self-learning agents that evolve and improve based on the tasks they're working on and their own experience. With memory, agents can learn about the tasks they work on — success criteria, common mistakes, strategies that are or are not working. They can learn about their environments — the codebases they interact with, the files and assets they keep up to date. And they can also learn from other agents in the same environment. They can share learnings, figure out what's going wrong elsewhere in a system, and incorporate that into their own memory. This last point is the one I've been most excited about. I think self-managed memory is going to be super important in large and complex multi-agent systems where a swarm of agents working in a similar environment on discrete tasks are essentially building up their own understanding and their own model of the worlds they're in over time.
To help get to this vision, we just launched memory in cloud-managed agents in public beta a couple weeks ago. This gives developers a frontier memory system that works out of the box to maximize intelligence by default, to support these systems of many agents running concurrently in the same environment, and most importantly, to give enterprises and developers the flexibility and control they need to run these in production. We've already heard from a bunch of teams building on this. Rakuten, for example, mentioned this helped them drop their first-pass mistakes in their internal knowledge agents by 90%, because agents were able to catch mistakes and share them with the next iteration of agents, which also led to better token efficiency, lower costs, and better latency.
I want to talk about the requirements we kept in mind. The first and most important is memory needs to be built to maximize intelligence by default. Agent builders have been designing memory systems for a while. We ourselves launched CLAUDE.md originally with Claude Code about a year and a half ago. This was a pretty constrained early version of memory where an agent could leave notes for itself, and sometimes the user would also leave notes in the same file. We also launched the memory tool within our SDKs, a pretty well-specified tool call with specific parameters and output formats. As agents have improved, we've tried to get more and more out of Claude's way and delegate more of this decision-making to Claude without over-constraining the design. As we did with skills, we came to the conclusion that agents are able to manage a virtual environment and their own file system, so why can't we go the same direction with memory? Memory in Claude-managed agents models memory as a file system to Claude — a series of files with a specific hierarchy and format that Claude can manage and update on its own. It can use familiar tools like bash and grep to update this memory, keep it organized, and constantly change it as it works on a task. This tracks with what we're seeing in the latest models. With Claude Opus 4.7, which we just launched last month, we saw it was state of the art at file-system-based memory. It's a lot better at discerning what content to put into memory, what's worth remembering, figuring out the right structure, how many files to split memory into, and keeping it organized — all with just bash and grep tools that already make Claude so good at agentic coding.
The other thing we had in mind is that it needs to scale with the multi-agent systems we're going to be building. Multi-parallel agents is something we're already starting to do with Claude Code — power users have 10 or 15 Claude Code sessions running at the same time — and we're seeing this in an enterprise setting where enterprises, including Anthropic, have hundreds or sometimes thousands of agents running in parallel, interacting with the same shared state and shared memory. A couple of properties come out of this. One is we want to give agents the ability to mix and match between the session and the memory stores it has access to. So one property is permission scopes — the ability for one agent to have read-only access to one memory store, maybe organization-wide knowledge, a set of best practices, a runbook for common tasks. And then it has read-write memory for another store, maybe working memory that's more specific and frequently updated. The other property is concurrency. If there are hundreds or thousands of agents interacting at the same time with the same memory state, it needs to know it's not going to clobber the memory as it works. So we implemented optimistic concurrency, where one agent can use a content hash to check if it's going to overwrite another agent's memory before it makes an update.
From talking to customers, the final and most important property is developer and enterprise control for actual production agents. The first and probably most sought-after property is version history — the ability for developers to see an entire audit log of every time memory was updated, and to give agents access to the same audit log so they can keep track of what change was made and when. It's also attribution metadata — what agent made an update, what time, what session made that change — to go super granularly so this is predictable and in developers' control. The other property is a standalone API. We talked to a lot of customers building bespoke systems outside managed agents to manage and curate their memory. We talked to customers that do PII scanning to make sure memory doesn't have sensitive content. We also talked to customers that wanted to clean up memory in their own separate pipeline or clone it into external systems. So we didn't want to lock them into a specific system. We built this portable API so they could control these additional things on their own.
Taking a step back, we've formed this picture of the different layers as we build a frontier memory system. There's the storage layer, where the data is actually stored, and what metadata and attribution data we leave alongside it. There's the structure and content layer — things like our decision to model memory as files in a file system, and earlier, skills as a form of procedural memory with a lightweight spec. And then there's the process layer — how often memory is actually updated, what triggers updates, and what sources it uses to decide what changes to make. Agent memory, the API we've been discussing, solves part of this. But as we started to scale this up into more complex multi-agent systems, we saw limitations. We saw cases where memory sessions were missing learnings that other agents and sessions had already figured out. We saw common mistakes and shared patterns across multiple agents in the same environment. And we saw they weren't super efficient at keeping up this large-scale memory store in a holistic way. They were siloed into the specific task they were working on.
So for the past couple of months, we've been experimenting with different types of processes to supplement this with, and we landed on one. We call this process dreaming, and today we're launching this in research preview in the managed agents API. Dreaming is a process that looks for patterns and mistakes across your recent agent sessions and their transcripts and automatically produces organized and up-to-date memory content. We've worked with a few customers in early testing — for example, Harvey, when they deployed dreaming in one of their legal benchmarks that tests a realistic legal scenario, saw a six-times increase in the task completion rate for one of their legal scenarios. We're really excited to see how other customers use this.
How does dreaming work? It's a batch asynchronous process that runs separately from the work you're doing within a specific session. You can kick off dreaming periodically using our console or API on a cron basis, or plug it in using our API into an existing process. For example, some customers kick off dreaming once their agents have finished a task and are spinning down and want to save those learnings. Dreaming comprehensively looks through recent transcripts, looks for common mistakes — things like a failed tool call — or strategies that are working, and finds opportunities to update the memory state to improve it in the future. It produces an updated memory state that you can apply immediately or run some checks and manual review on via the API. The ultimate goal of dreaming is continuous self-learning and self-improvement, where the next day's agents automatically get better based on the learnings and work of the previous day's experience.
We're excited about dreaming from a design and research perspective for a couple of reasons. First, compared to the memory APIs we've been talking about, dreaming is out of band. It happens outside the context of an agent working on a specific session or task. This has a couple of benefits. It's a really good fit for multi-agent systems. When a single agent is reading and writing memory, it has the perspective of itself, its own context, and its task. But dreaming lets us go a step above that and look at multiple agents at the same time to find shared patterns and learnings that a single agent might not notice from its own limited perspective. From a harness design perspective, we've found consistently that it's important for agents to have really discrete and clear objectives. Dreaming lets us separate out this new objective of memory quality, because over the coming months memory is going to be increasingly important and load-bearing to the actual outcomes. This lets us separate the memory quality objective from the task completion objective that a lot of agents already have. And because dreaming is out-of-band, in the background, it does this without adding any latency to the hot path of an agent's existing task.
The other design perspective is large-scale memory systems and how to use compute effectively to create and curate these. Today, most memory deployments are pretty localized to a specific user, task, or small team. But agent systems are quickly getting to enterprise scale. Within Anthropic and other enterprises, they already have hundreds or thousands of agents running concurrently that share state. So this starts to turn into a really large knowledge base as opposed to a simple memory store. To support this, we need ways to let Claude scale up memory systems to be super large while still being up to date and not too token intensive. Dreaming lets us do this by following similar scaling laws of using additional compute and effort to keep these systems organized. One way to think about this is test-time compute or thinking models — giving models the ability to explore and spend more tokens leads to better final outcomes. Dreaming is a similar thing that lets a dreaming agent spend more tokens to keep these systems well organized and up to date. Another perspective is like a search system, where there's upfront effort to produce a high-quality, up-to-date index that's then used at retrieval time to get the latest results efficiently. Dreaming creates this index upfront and curates it so all downstream agents can use it, amortizing the effort across all those agents.
So now with memory and dreaming in the managed agents API, we build this picture of a frontier memory system. Memory on the left side is a primitive for agents to immediately, in real time, read and write things and remember things as working on a task. And dreaming is a comprehensive process built on top of that to verify the state of memory, organize it, enrich it, and backfill it with additional information based on the tasks the agents are doing during a day. Dreaming is the bridge between these intermediate memory systems and the larger-scale knowledge bases that we think are going to be really prominent over the next few months.
Let's walk through a quick demo. What we're looking at here is an SRE agent that is looking at alerts coming in and reacting based on those alerts, spinning up specific agents that do triage work or sometimes submit PRs. Each of these agents is equipped with a couple of memory stores. We can see it has an org-wide knowledge memory store, an SRE memory store, and a codebase memory store. If we click into the org-wide knowledge memory store, it's read-only. It's a set of runbooks and SLO guidelines. It points the agents to specific owners they might need to ping, and it doesn't get updated very often — we don't want agents making changes as they work. There's also the SRE memory store that's read-write, and the SRE agents can constantly make changes as they react and learn. We see this alert, a P1 coming in from the dispatch service, and we spin up an SRE agent that kicks off an investigation. It investigates the CPU utilization, checks traffic patterns, queries for recent PRs that got deployed, and writes down these learnings in a new diff in that memory store. A couple minutes later, that same alert gets paged again, and a different SRE agent spins up with access to the same memory store. The first thing it does is see that note within its memory store that says, "We already did this investigation. Here's what we found. Here's a way to short-circuit what you're looking at." Ultimately it saves a bunch of time it would have spent investigating the same thing. So we see an immediate token efficiency gain and an intelligence gain. We want to deploy these in an enterprise and have reliability, so if we click into the memory store, it has version history. Every time an update was made, we can go back in time and see what changes were made, which agent made the change, and when it was written. We also have this precondition hash, which lets us do optimistic concurrency to verify it is what it is before overriding it.
We've been talking about agent memory, but let's see how dreaming can make this a more holistic, up-to-date memory system. We'll pivot to the cloud console, which reflects the exact state of what we're looking at in the API. We'll click into the team SRE memory store, which reflects the latest state of memory. If we navigate to the dreaming tab, we can kick off a dreaming job where we say we want to update this specific memory store and look at a bunch of the sessions from the past 7 days that touched this memory store. I click into the dream and we see the work it's doing under the hood. It says here are some of the input sessions it's going to look into. It spins up an actual session where you can see what's happening, looking at specific transcript entries, spinning up sub-agents to look through those transcripts, identify learnings, and produce the updated memory state. We'll jump ahead and look at the completed dreaming job. It produces a diff, a set of updated files to apply to the memory store. The first is an update to this dispatch latency note from the demo earlier. It says a bunch of these agents were triggered exactly 60 seconds after an upstream spike in CPU utilization, and figures out there might be some retry logic getting triggered that's really inefficient and leading to wasted time. It identifies that because each individual agent isn't noticing that 60-second pattern, and leaves a note so future agents benefit. It also does a deduplication and creation step — it sees five of the same entries from previous agents and consolidates them into a single entry. It removes a stale entry that's no longer valid. And it adds a verification note: "At this time, based on this transcript I just looked at, this memory is actually accurate. I was able to verify it based on the work the agent was doing, and therefore you can rely on it the next day." So there's that verification, backfill, and organization step that we think memory and dreaming are really useful for.
With this demo, we've seen how to build production agents using the memory and dreaming APIs in the managed agents API. To close out, I think that over the next couple of months, we're going to start seeing agents that run for days or many hours at a time, and memory is going to be a really important part of what makes that ultimately possible. So I'm really excited to see what everyone builds with memory and dreaming in the cloud managed agents API, and you should get started today. Thank you.