- A hands-on Anthropic workshop on giving agents persistent memory across sessions using the new agent memory stores feature in Claude Managed Agents, plus a "dreaming" feature to refine that memory over time.
- A memory store is a persistent, file-system-like store mounted onto a session's container, which agents read and write using tools like bash and grep across multiple sessions.
- "Dreaming" is an asynchronous, multi-agent batch job that reviews an input memory store plus past session transcripts to fact-check, enrich, organize, and deduplicate, producing a non-destructive output memory store for future sessions.
Agents that remember
- The base case today: agents and sessions are isolated — information told in one session doesn't transfer to future sessions, which limits usefulness in real-world workflows; the demo proves this by telling one session about a CMA talk and finding a later session has no access to it.
- A memory store is a persistent, file-system-like store attached as a resource to sessions, giving agents the ability to read and write information across sessions; it's mounted as a real file system because that's a powerful interface — the model can use bash to explore, grep to search keywords, and read files.
- You can create as many memory stores as you like with whatever boundaries you choose (per user, per workspace, per organization); each is created with a name and description, viewable in the console as a file-system viewer, and supports manually adding memories.
- When mounting a memory store on a session you can pass a memory-store ID plus a steering prompt (to focus what the agent reads/writes) and an access field that defaults to read/write but can be set to read-only.
- In the memory-enabled demo, the agent first checks memory, saves new information to a
sessions.mdfile, and in a later session uses grep to find keywords (e.g. "CMA") and answer questions — solving the isolation problem; memory files are versioned and editable, supporting human-in-the-loop review. - Over time, agents tend to dump information to the memory store, which grows unbounded, disorganized, and stale; "dreaming" is an asynchronous batch process you launch via API or console that runs a multi-agent harness over an input memory store and a set of session transcripts.
- A dream job takes a model (e.g. Claude Opus 4.7 or Sonnet 4.6), an input memory store, and a list of session IDs (10–100+), plus optional instructions; it is non-destructive — it clones the input into an output memory store, spawns one subagent per input session to fact-check and enrich (adding dates, identifiers, an index file, event logistics), and shows a diff in the console.
- Dreaming is designed to be exhaustive, so it uses a lot of tokens, but most processing is agentic and cached (~95% cache-hit rate expected), with future cost-reduction options like a batch-style 50% discount; sessions, memory stores, and dreaming form three composable layers — isolated conversation, cross-session connection, and ongoing organization/enrichment.
Memory store — A persistent, file-system-like store attached to sessions so agents can read and write information across sessions.
Session — A typically ephemeral, isolated instance of an agent running, usually one conversation thread.
Dreaming — An asynchronous, multi-agent batch job that fact-checks, enriches, organizes, and deduplicates a memory store using past transcripts.
Dream job — A specific dreaming run taking a model, input memory store, and session IDs, producing an output memory store.
Output memory store — A non-destructive clone of the input that dreaming writes to, usable in future sessions.
Steering prompt — A prompt passed when mounting a memory store to focus what the agent reads or writes.
Access field — A setting (read/write or read-only) controlling whether a session can update a memory store.
Index file — A dreaming-created file of slugs referencing memory files so future agents can efficiently find what they need.
Cache-hit rate — The fraction of tokens served from cache (~95% expected for dreaming) that lowers cost.
Hello everyone. Thank you all for joining us today. My name is Kevin. I'm an engineer here at Anthropic, and today we'll be learning about how to build agents that remember. Today we're going to talk a little bit about the base case with agents today, which is that they're isolated, and this limits their usefulness in a lot of real-world workflows. We'll look at how we can solve this problem with our new agent memory stores feature that we've launched. This will give agents access to a live memory store that they can read and write to over multiple sessions. Then we'll look at how we can improve these memory stores over time using a new feature that we call dreaming. And finally we'll see how all of this ties together with both our CLI and our console interface.
In previous workshops we've learned about how Claude Managed Agents has these concepts called an agent, environment, and a session. In this workshop, we're going to add two additional concepts. The first is a memory store — a persistent file-system-like store that attaches as a resource to sessions that you create, and gives agents the ability to read and write information across sessions. A dream is an asynchronous job that runs in the background. It looks over an input memory store and a bunch of your previous sessions that are represented as transcripts, and then we run a harness over them to distill new information that maybe the original agents missed. We do things like fact-checking. We also organize, consolidate, and deduplicate information so that your memory stores don't grow unbounded over time.
Let's talk about the problem today. When you create agents on Claude AI today and sessions, most of the time you're creating one session at a time and these are isolated. The agent doesn't remember information from the past and it doesn't transfer information to future sessions. In our workshop repository I've run the bootstrap script, which created some seed information: an agent, an environment, and a few previous sessions that talk about things like the keynotes from day one and a previous workshop. First we're going to create a session that tells it some new information. We are creating a session with the agent and environment ID we created before, with a title of "write test with no memory." In the console, the session shows up with a status of idle. Then I send this session a first user message with information about the CMA talk yesterday, naming a few keywords like multi-agent orchestration, multi-agent orchestration outcomes, and memory, with a URL where I uploaded notes. The model responds: "Great, thanks for the information. Not sure what else you want me to do here." This is using Sonnet, the agent created at the beginning.
Then we create a second session — the retest. I send it a message asking for information about the stuff I just told it. As we'd expect, the agent says something like, "I don't really have access to that information. I can help you in these various ways." That's effectively the base case today: we told it something, asked another session about it later, and no information is transferred between the sessions.
So how do we solve this problem? Just like in humans, we've introduced the concept of memory. A memory store in the Claude Managed Agents platform is a file-system-like store. You can create as many memory stores as you like, so you don't have to restrict a memory store to one organization — you can create it per user, per workspace, etc. It's up to you to define the boundaries. Under the hood, this memory store gets attached as a file system to the session container, and the model has tools to read and write to it. The interesting thing is that we've mounted it as a file system because it's such a powerful interface for the model. You can use bash to explore the file system, grep to search for keywords, read files, and do a bunch of really powerful things.
First, creating it. The parameters you need are mainly a name (I'm calling mine "CWC memory") and a quick description. Once I create this memory store, you can see it in console under managed agents, memory stores. You can click into it and view a file-system viewer of what's currently in it — nothing right now. We also offer the ability to manually add memories, creating a file under a specific path with some content. There are two additional parameters you can set on the memory store when we mount it. The next step is to use it with your sessions. The memory store takes a memory-store ID. You can also give it a prompt that will steer the agent to read and write specific information — you might want it to focus on a specific link or area. Say you're making an investment agent: you want to focus on specific things to remember for the future. Additionally there is an access field that defaults to read/write; you can change that to read-only, which makes it so the session and agent can only read from that memory store, not update it.
Once I run this, I've created a new session in console, and this time it has a memory store attached. I send it the same text as before, telling it new information. Clicking into the session details, the model is first looking at memory to see if there's anything it needs to remember for this conversation. Of course there's nothing in our memory store, so now it saves the content I told it directly to the memory store under a sessions.md file, and tells me what it did. Then I create a new session with the same memory store and send an event asking what it found or learned from the CMA talk. Going back to console, the model is first looking at its memory store, using grep to find keywords (CMA), and it found a lot of information from our previous session, so it's now able to answer my question. This was difficult to do before.
What else can you do? We offer additional endpoints to manually inspect the store. You can list all of the memory files. Memory files in a memory store are also versioned — anytime you make a change, a new version is created, and we offer endpoints for that. In the memory store UI you can see the files it created, with a directory structure if Claude creates subdirectories to organize memory files. You can edit these memory files directly — if Claude wrote something incorrect, or you want to add more information.
Let's talk about dreaming. When you have agents reading and writing to this memory store over time, oftentimes they start dumping information — recording information for maybe every task you ask it to do. Over time your memory store grows, and there's no process to organize it, check for staleness, or consolidate duplicates. Dreaming is a batch process that runs asynchronously. You launch it using our API or through console, and it runs a new dreaming harness — a multi-agent setup. It looks over each input session you've given it: you specify an input memory store along with a group of transcripts that might enrich that memory store. It does fact-checking, enriching with additional details, dates, and specific identifiers, and organizes the memory files and deduplicates, producing an output memory store such that when you attach that output to additional sessions, it increases efficiency of information retrieval and the intelligence of the agent.
To get started with dreaming, you create the dream job. The model we're choosing is Claude Opus 4.7 — you can choose between that or Sonnet 4.6 depending on the level of quality you want and token costs. It takes two inputs: the memory store you want it to dream over and a list of session IDs. You can dream over maybe 10 sessions at a time, or 20, all the way up to 100 — we're looking to scale further. Optionally you can provide additional instructions. We provide a default prompt that does a bunch of things, but if you want dreaming to specifically fix things — maybe you're in a domain that requires very specific details — you might ask it to backfill those details. You can also steer it to organize files in a specific structure. We run the command and get back a dream ID.
In console, dreams are under managed agents, dreams. Once I create the dream job it starts pending, then starts running shortly after, and you can see the status both in console and through the API. You'll see the input memory store and a token count. A dream job can take anywhere from a couple minutes to hours, depending on the size or number of transcripts — that's the benefit of doing it asynchronously; this is not something you want to do live while your agents are working. As the harness runs, we update the token count so you can track its progress. Dreaming is actually built directly on top of Claude Managed Agents primitives, so we're creating a session for the dream job itself, and you can click into it to see exactly what the dream is doing — nice observability for diagnosing issues. Under the hood, the dreaming harness launches subagents to look over all the transcripts you've given it, each with a system prompt telling it what to do, and the orchestrator is responsible for making sure all the agents are running and kicking them off.
We don't touch the input memory store at all — this is a non-destructive process. We clone your input memory store into an output memory store, and the dream job writes to the new memory store so any edits are non-destructive. When it completes, the console shows a diff of what it did. Dreaming created an index file with slugs that reference the various memory files a future agent might need — it's more efficient to look at an index file and quickly grok what to look for instead of a wider grep. It's also adding additional information not present in the first couple of sessions — an event logistics file with the whole schedule of Code with Claude, names, and the schedule for day two. It reformatted the memory file I created in a previous session, adding a slug, a description, metadata, and more details. More information actually really does help future sessions: while an agent is working on a task currently, it's hard to predict what it might need later, so it's good to write additional details down, and dreaming can always go back and remove what's no longer needed. If you want a human-in-the-loop review process, the output memory store is where that's super helpful — a human can see if the dreaming harness made any mistakes.
Under the hood, dreaming is a multi-agent harness: an orchestrator spins up subagents, one subagent per input session, because we want dreaming to be exhaustive by design — if you give it 100 chances, you want Claude looking over all the information to make sure it's not missing anything.
To use this in a future session, once the dream is done you grab the output memory store by retrieving the dream resource with the dream ID. Then we do the same test as before. I create a new session using the output memory store from dreaming and send an event asking what sessions I attended, what resources I have links for, and what follow-ups I flagged. In console, when it reads from memory you'll see all the stuff dreaming did — the index, the event logistics — and it starts reading the index first, then goes straight to the sessions file. This time there's a lot more information: a recap of all the sessions I attended, timestamps for sessions planned for day two, and resource links. This showcases how dreaming can enrich information transferred between sessions. Optionally, if you're happy with the output memory store, you can retire the old memory store — this won't affect your previous sessions, it just keeps the number of memory stores in your organization reasonable.
You can view sessions, memory stores, and dreaming as three composable layers. A session is an isolated instance of an agent running — typically one conversation thread, typically ephemeral. A memory store augments that, connecting information across multiple sessions. And dreaming organizes, enriches, and improves your memory stores over time, so as you scale up sessions and information, your memory stays at a reasonable level, manageable, and doesn't blow up — and it checks for staleness to make sure information is up to date.
A couple of good audience questions. One was about token usage. By design we want dreaming to be exhaustive, so we expect it to use a lot of tokens. The nice thing is that because most of the processing is agentic, most of the tokens are cached — we expect about a 95% cache-hit rate on most dream sessions. We're exploring other ways of offering this at lower cost, like a batch-API-style 50% discount by scheduling at different times. Other token-usage controls include switching the model, steering the prompt, and general token budgeting.
Winding down, here's what we went over. We talked about the problem most agents face: how do you remember information across sessions? Memory is the first step — you give agents something where they can dump information and read from it. But that creates a problem where memory stores can grow unbounded, disorganized, and stale. Dreaming mitigates this: another set of agents whose entire job is to improve that memory store for future use. With that, I'd like to thank everyone for coming to this workshop. Hopefully by the end you know how to integrate memory into your own use cases.
TL;DR
- A hands-on Anthropic workshop on giving agents persistent memory across sessions using the new agent memory stores feature in Claude Managed Agents, plus a "dreaming" feature to refine that memory over time.
- A memory store is a persistent, file-system-like store mounted onto a session's container, which agents read and write using tools like bash and grep across multiple sessions.
- "Dreaming" is an asynchronous, multi-agent batch job that reviews an input memory store plus past session transcripts to fact-check, enrich, organize, and deduplicate, producing a non-destructive output memory store for future sessions.
Takeaways
- The base case today: agents and sessions are isolated — information told in one session doesn't transfer to future sessions, which limits usefulness in real-world workflows; the demo proves this by telling one session about a CMA talk and finding a later session has no access to it.
- A memory store is a persistent, file-system-like store attached as a resource to sessions, giving agents the ability to read and write information across sessions; it's mounted as a real file system because that's a powerful interface — the model can use bash to explore, grep to search keywords, and read files.
- You can create as many memory stores as you like with whatever boundaries you choose (per user, per workspace, per organization); each is created with a name and description, viewable in the console as a file-system viewer, and supports manually adding memories.
- When mounting a memory store on a session you can pass a memory-store ID plus a steering prompt (to focus what the agent reads/writes) and an access field that defaults to read/write but can be set to read-only.
- In the memory-enabled demo, the agent first checks memory, saves new information to a
sessions.mdfile, and in a later session uses grep to find keywords (e.g. "CMA") and answer questions — solving the isolation problem; memory files are versioned and editable, supporting human-in-the-loop review. - Over time, agents tend to dump information to the memory store, which grows unbounded, disorganized, and stale; "dreaming" is an asynchronous batch process you launch via API or console that runs a multi-agent harness over an input memory store and a set of session transcripts.
- A dream job takes a model (e.g. Claude Opus 4.7 or Sonnet 4.6), an input memory store, and a list of session IDs (10–100+), plus optional instructions; it is non-destructive — it clones the input into an output memory store, spawns one subagent per input session to fact-check and enrich (adding dates, identifiers, an index file, event logistics), and shows a diff in the console.
- Dreaming is designed to be exhaustive, so it uses a lot of tokens, but most processing is agentic and cached (~95% cache-hit rate expected), with future cost-reduction options like a batch-style 50% discount; sessions, memory stores, and dreaming form three composable layers — isolated conversation, cross-session connection, and ongoing organization/enrichment.
Vocabulary
Memory store — A persistent, file-system-like store attached to sessions so agents can read and write information across sessions.
Session — A typically ephemeral, isolated instance of an agent running, usually one conversation thread.
Dreaming — An asynchronous, multi-agent batch job that fact-checks, enriches, organizes, and deduplicates a memory store using past transcripts.
Dream job — A specific dreaming run taking a model, input memory store, and session IDs, producing an output memory store.
Output memory store — A non-destructive clone of the input that dreaming writes to, usable in future sessions.
Steering prompt — A prompt passed when mounting a memory store to focus what the agent reads or writes.
Access field — A setting (read/write or read-only) controlling whether a session can update a memory store.
Index file — A dreaming-created file of slugs referencing memory files so future agents can efficiently find what they need.
Cache-hit rate — The fraction of tokens served from cache (~95% expected for dreaming) that lowers cost.
Transcript
Hello everyone. Thank you all for joining us today. My name is Kevin. I'm an engineer here at Anthropic, and today we'll be learning about how to build agents that remember. Today we're going to talk a little bit about the base case with agents today, which is that they're isolated, and this limits their usefulness in a lot of real-world workflows. We'll look at how we can solve this problem with our new agent memory stores feature that we've launched. This will give agents access to a live memory store that they can read and write to over multiple sessions. Then we'll look at how we can improve these memory stores over time using a new feature that we call dreaming. And finally we'll see how all of this ties together with both our CLI and our console interface.
In previous workshops we've learned about how Claude Managed Agents has these concepts called an agent, environment, and a session. In this workshop, we're going to add two additional concepts. The first is a memory store — a persistent file-system-like store that attaches as a resource to sessions that you create, and gives agents the ability to read and write information across sessions. A dream is an asynchronous job that runs in the background. It looks over an input memory store and a bunch of your previous sessions that are represented as transcripts, and then we run a harness over them to distill new information that maybe the original agents missed. We do things like fact-checking. We also organize, consolidate, and deduplicate information so that your memory stores don't grow unbounded over time.
Let's talk about the problem today. When you create agents on Claude AI today and sessions, most of the time you're creating one session at a time and these are isolated. The agent doesn't remember information from the past and it doesn't transfer information to future sessions. In our workshop repository I've run the bootstrap script, which created some seed information: an agent, an environment, and a few previous sessions that talk about things like the keynotes from day one and a previous workshop. First we're going to create a session that tells it some new information. We are creating a session with the agent and environment ID we created before, with a title of "write test with no memory." In the console, the session shows up with a status of idle. Then I send this session a first user message with information about the CMA talk yesterday, naming a few keywords like multi-agent orchestration, multi-agent orchestration outcomes, and memory, with a URL where I uploaded notes. The model responds: "Great, thanks for the information. Not sure what else you want me to do here." This is using Sonnet, the agent created at the beginning.
Then we create a second session — the retest. I send it a message asking for information about the stuff I just told it. As we'd expect, the agent says something like, "I don't really have access to that information. I can help you in these various ways." That's effectively the base case today: we told it something, asked another session about it later, and no information is transferred between the sessions.
So how do we solve this problem? Just like in humans, we've introduced the concept of memory. A memory store in the Claude Managed Agents platform is a file-system-like store. You can create as many memory stores as you like, so you don't have to restrict a memory store to one organization — you can create it per user, per workspace, etc. It's up to you to define the boundaries. Under the hood, this memory store gets attached as a file system to the session container, and the model has tools to read and write to it. The interesting thing is that we've mounted it as a file system because it's such a powerful interface for the model. You can use bash to explore the file system, grep to search for keywords, read files, and do a bunch of really powerful things.
First, creating it. The parameters you need are mainly a name (I'm calling mine "CWC memory") and a quick description. Once I create this memory store, you can see it in console under managed agents, memory stores. You can click into it and view a file-system viewer of what's currently in it — nothing right now. We also offer the ability to manually add memories, creating a file under a specific path with some content. There are two additional parameters you can set on the memory store when we mount it. The next step is to use it with your sessions. The memory store takes a memory-store ID. You can also give it a prompt that will steer the agent to read and write specific information — you might want it to focus on a specific link or area. Say you're making an investment agent: you want to focus on specific things to remember for the future. Additionally there is an access field that defaults to read/write; you can change that to read-only, which makes it so the session and agent can only read from that memory store, not update it.
Once I run this, I've created a new session in console, and this time it has a memory store attached. I send it the same text as before, telling it new information. Clicking into the session details, the model is first looking at memory to see if there's anything it needs to remember for this conversation. Of course there's nothing in our memory store, so now it saves the content I told it directly to the memory store under a sessions.md file, and tells me what it did. Then I create a new session with the same memory store and send an event asking what it found or learned from the CMA talk. Going back to console, the model is first looking at its memory store, using grep to find keywords (CMA), and it found a lot of information from our previous session, so it's now able to answer my question. This was difficult to do before.
What else can you do? We offer additional endpoints to manually inspect the store. You can list all of the memory files. Memory files in a memory store are also versioned — anytime you make a change, a new version is created, and we offer endpoints for that. In the memory store UI you can see the files it created, with a directory structure if Claude creates subdirectories to organize memory files. You can edit these memory files directly — if Claude wrote something incorrect, or you want to add more information.
Let's talk about dreaming. When you have agents reading and writing to this memory store over time, oftentimes they start dumping information — recording information for maybe every task you ask it to do. Over time your memory store grows, and there's no process to organize it, check for staleness, or consolidate duplicates. Dreaming is a batch process that runs asynchronously. You launch it using our API or through console, and it runs a new dreaming harness — a multi-agent setup. It looks over each input session you've given it: you specify an input memory store along with a group of transcripts that might enrich that memory store. It does fact-checking, enriching with additional details, dates, and specific identifiers, and organizes the memory files and deduplicates, producing an output memory store such that when you attach that output to additional sessions, it increases efficiency of information retrieval and the intelligence of the agent.
To get started with dreaming, you create the dream job. The model we're choosing is Claude Opus 4.7 — you can choose between that or Sonnet 4.6 depending on the level of quality you want and token costs. It takes two inputs: the memory store you want it to dream over and a list of session IDs. You can dream over maybe 10 sessions at a time, or 20, all the way up to 100 — we're looking to scale further. Optionally you can provide additional instructions. We provide a default prompt that does a bunch of things, but if you want dreaming to specifically fix things — maybe you're in a domain that requires very specific details — you might ask it to backfill those details. You can also steer it to organize files in a specific structure. We run the command and get back a dream ID.
In console, dreams are under managed agents, dreams. Once I create the dream job it starts pending, then starts running shortly after, and you can see the status both in console and through the API. You'll see the input memory store and a token count. A dream job can take anywhere from a couple minutes to hours, depending on the size or number of transcripts — that's the benefit of doing it asynchronously; this is not something you want to do live while your agents are working. As the harness runs, we update the token count so you can track its progress. Dreaming is actually built directly on top of Claude Managed Agents primitives, so we're creating a session for the dream job itself, and you can click into it to see exactly what the dream is doing — nice observability for diagnosing issues. Under the hood, the dreaming harness launches subagents to look over all the transcripts you've given it, each with a system prompt telling it what to do, and the orchestrator is responsible for making sure all the agents are running and kicking them off.
We don't touch the input memory store at all — this is a non-destructive process. We clone your input memory store into an output memory store, and the dream job writes to the new memory store so any edits are non-destructive. When it completes, the console shows a diff of what it did. Dreaming created an index file with slugs that reference the various memory files a future agent might need — it's more efficient to look at an index file and quickly grok what to look for instead of a wider grep. It's also adding additional information not present in the first couple of sessions — an event logistics file with the whole schedule of Code with Claude, names, and the schedule for day two. It reformatted the memory file I created in a previous session, adding a slug, a description, metadata, and more details. More information actually really does help future sessions: while an agent is working on a task currently, it's hard to predict what it might need later, so it's good to write additional details down, and dreaming can always go back and remove what's no longer needed. If you want a human-in-the-loop review process, the output memory store is where that's super helpful — a human can see if the dreaming harness made any mistakes.
Under the hood, dreaming is a multi-agent harness: an orchestrator spins up subagents, one subagent per input session, because we want dreaming to be exhaustive by design — if you give it 100 chances, you want Claude looking over all the information to make sure it's not missing anything.
To use this in a future session, once the dream is done you grab the output memory store by retrieving the dream resource with the dream ID. Then we do the same test as before. I create a new session using the output memory store from dreaming and send an event asking what sessions I attended, what resources I have links for, and what follow-ups I flagged. In console, when it reads from memory you'll see all the stuff dreaming did — the index, the event logistics — and it starts reading the index first, then goes straight to the sessions file. This time there's a lot more information: a recap of all the sessions I attended, timestamps for sessions planned for day two, and resource links. This showcases how dreaming can enrich information transferred between sessions. Optionally, if you're happy with the output memory store, you can retire the old memory store — this won't affect your previous sessions, it just keeps the number of memory stores in your organization reasonable.
You can view sessions, memory stores, and dreaming as three composable layers. A session is an isolated instance of an agent running — typically one conversation thread, typically ephemeral. A memory store augments that, connecting information across multiple sessions. And dreaming organizes, enriches, and improves your memory stores over time, so as you scale up sessions and information, your memory stays at a reasonable level, manageable, and doesn't blow up — and it checks for staleness to make sure information is up to date.
A couple of good audience questions. One was about token usage. By design we want dreaming to be exhaustive, so we expect it to use a lot of tokens. The nice thing is that because most of the processing is agentic, most of the tokens are cached — we expect about a 95% cache-hit rate on most dream sessions. We're exploring other ways of offering this at lower cost, like a batch-API-style 50% discount by scheduling at different times. Other token-usage controls include switching the model, steering the prompt, and general token budgeting.
Winding down, here's what we went over. We talked about the problem most agents face: how do you remember information across sessions? Memory is the first step — you give agents something where they can dump information and read from it. But that creates a problem where memory stores can grow unbounded, disorganized, and stale. Dreaming mitigates this: another set of agents whose entire job is to improve that memory store for future use. With that, I'd like to thank everyone for coming to this workshop. Hopefully by the end you know how to integrate memory into your own use cases.