Claude's Dreams Rebuild an Agent's Memory Store, and Never Touch the Original (2026)

Two inputs, one new output

A dream is "an asynchronous job" that takes exactly two kinds of input: "a pre-existing memory store: the store Claude verifies, deduplicates, and reorganizes, and 1 to 100 sessions: past transcripts Claude mines for patterns and insights to fold into the output."

What it produces is described just as precisely: "a new, reorganized memory store: duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced."

Note the third item. Merging duplicates and replacing stale entries is cleanup. Surfacing new insights from transcripts is something else — it reads sessions the store never captured and writes down what they imply. If you have transcripts but no store yet, the docs give the workaround: "create an empty memory store first and pass it as the memory_store input."

The input is never modified

This is the design choice that makes the rest safe to use:

"The input store is never modified, so you can review the output and discard it if you don't like the result."

Restated later, in stronger terms: "The dream itself never deletes or modifies its inputs." And it holds through failure — on a failed or canceled dream, "the output memory store is left as-is with whatever was written before failure," and "the output store persists with partial contents so you can inspect what was produced before stopping."

So the failure mode of a bad dream is a store you delete. Not a store you have to reconstruct.

It steers, but it is not an editor

The optional instructions field, capped at 4,096 characters, "steers what the dreaming pipeline synthesizes. It is applied throughout the pipeline: what to read closely, what to merge or drop, and how to structure the output store." Anthropic's own example is a focus statement: "Focus on coding-style preferences; ignore one-off debugging notes."

Then comes the caveat that will save people a wasted run:

"The pipeline is a synthesis pass over the inputs, not an editor applied to the text of the store, so imperative directives that target specific lines ("change sentence X to Y", "fix the count in section Z") generally produce no change."

For targeted changes, the docs point you elsewhere: "use the Memory Stores API on the output store directly." Dreams are for the shape of the store, not for line edits.

It takes as long as it takes, and you can watch

"Dreams run asynchronously and typically take minutes to a few hours, driven by the number of input transcripts." The lifecycle is pending, running, then one of completed, failed, or canceled.

There is a small operational detail worth knowing: "The output store ID appears in the dream's outputs[] shortly after the dream starts running, once the workflow has cloned the input store; a running dream can briefly report an empty outputs[]." An empty array early on is not an error.

And you can observe the work: a running dream's session_id "points at the underlying session running the pipeline," whose events you can stream "to observe what the dream is reading and writing in real time." That session "is archived (not deleted) when the dream reaches a terminal state, so the transcript remains available afterward."

Two ways to finish

When a dream completes, its output "is an ordinary memory store in your workspace." From there, two documented paths. Leverage it: "attach it to future sessions as a memory_store resource in place of (or alongside) the input memory store." Discard it: delete or archive the store.

Alongside is the quiet option in that sentence. You are not forced to choose between the curated store and the original.

It does address a real structural problem. Incremental writes accumulate contradictions. That is not a bug in Anthropic's implementation; it is what append-mostly stores do. A periodic synthesis pass with a review gate is a reasonable answer, and the mechanics of the stores it operates on are covered in Claude's agent memory stores.

It does not run itself. There is no schedule, no background trigger. You create a dream, choose the model, poll for status, review the output, and attach or discard. Every one of those is an explicit call.

It is gated twice, and the gate is specific. "Dreaming is a research preview feature," with access by request. And the headers matter: "Dream endpoints are gated by the dreaming-2026-04-21 beta header; the managed-agents-2026-04-01 header on its own doesn't grant access to dreams." Session and memory-store calls need only the latter.

It costs tokens, proportionally. "Dreams are billed at standard API token rates for the model you select," and "Cost scales roughly linearly with the number and length of input sessions." Anthropic's own recommendation is to start small: "Start with a small batch of sessions and scale up once you're satisfied with the curation quality."

It does not protect you from removing its inputs mid-run. A documented warning: "Archiving or deleting an input memory store mid-run (or deleting an input session) will cause the dream to fail with input_memory_store_unavailable or input_session_unavailable." The inputs are read-only to the dream, not locked against you.

It has size limits you can hit. The error list includes input_memory_store_too_large, memory_store_org_limit_exceeded for organizations at their store cap, and timeout when "The pipeline exceeded its runtime budget."

"Claude now maintains its own memory automatically." For Managed Agents, not through Dreams. This is a job you invoke with explicit inputs, a model choice, and a decision at the end.

"It fixes wrong memories." It replaces "stale or contradicted entries" with the latest value based on what the inputs support. If you want a specific sentence changed, that is the Memory Stores API on the output store — the docs say imperative line-level directives "generally produce no change."

"Reviewing is optional." Reviewing is the feature. An unreviewed dream attached straight to production sessions discards the one property that makes the design safe, and the whole reason the input is preserved.

"More sessions is better." More sessions cost more and take longer, and the guidance is to scale up after you like the quality — not before. Cost and runtime both track transcript volume.

"It is the same thing ChatGPT does." Different layer, different ergonomics. OpenAI's Dreaming curates a consumer memory in the background. Anthropic's Dreams are a developer-triggered synthesis job that emits a reviewable artifact and never modifies its source.

"Canceling undoes it." Cancel stops the run; it does not clean up. A canceled dream leaves its partial output store in place for you to inspect or delete. Archiving a dream also "does not touch its output memory store," and for dreams themselves "There is no unarchive."

Step 1: Decide what "stale" means for your store before you curate it

A synthesis pass is only as good as the judgment you give it. Before running anything, write down which categories of entry in your store are allowed to change and which must be preserved.

The instructions field is where that judgment goes, and it works best as high-level guidance: "focus areas... content to preserve unchanged, or output conventions you want applied across the store," in Anthropic's phrasing. "Prefer the most recent statement of a coding preference" is the right altitude. "Fix the number in section three" is not.

Step 2: Build a review step you will actually perform

The input store is preserved so that review is possible. Make it happen in practice by deciding two things in advance: what you will diff, and what would make you discard.

A useful default is to attach the output alongside the input for a period rather than in place of it, which the docs explicitly permit, and watch whether agent behavior improves. Conflicts between remembered entries are the thing to look for, and the general habit is covered in detecting conflicts in AI memory.

While a dream runs, streaming its session's events tells you what it is reading and writing. That is worth doing at least once, because seeing which transcripts it leans on is the fastest way to learn whether your session selection was right.

Step 3: Keep the store you curate independent of any one vendor's pipeline

Here is the structural point, and it is not a criticism of Dreams. The mechanism is sound and the review gate is the right design. It is also scoped to memory stores on one platform, behind a research-preview flag, for agents built one way.

Meanwhile the memories that decay fastest are the ones spread across everything you use — the preference you stated in a chat, the correction you gave a coding agent, the decision recorded in a session transcript somewhere else. Duplicates and contradictions accumulate across tools even faster than inside one store, and no single vendor's curation pass can see them.

A memory layer you own is where that consolidated store lives, and where the same habit applies: read it, correct it, prune it, keep the version history. MemoryLake sets up in three steps.

Step 1: Create an API key

Sign in and generate an API key from your dashboard. Your own store is the one you can open and inspect directly, which is what makes the review habit above practical rather than aspirational. Anthropic's memory stores stay where they are, managed through Anthropic's own API.

Step 2: Upload your first memories

Put in the durable facts: decisions and their reasons, domain vocabulary, standing preferences, the corrections you have given more than once. The same material a dream would synthesize, held where every tool you use can reach it.

Step 3: Connect your AI & agents

Point your agents at the store. Curation then becomes something you do once for the knowledge itself, rather than once per vendor's memory system — the case made in syncing AI memory across your tools.

The first change is that "my agent's memory got worse over time" becomes a diagnosable condition rather than a vague complaint. Anthropic put a name and a mechanism on it: incremental writes, duplicates, contradictions, stale entries.

The second is that review becomes the default expectation for any curation feature. Dreams set a good precedent by never modifying the input. It is a reasonable thing to ask of every memory system you adopt.

The third is that the scope question gets sharper. A per-platform curation pass helps the store it can see. What it cannot see is everything the same person told four other tools, which is the argument for auditing what your AI remembers as one exercise rather than several.

• Start with a small batch of sessions. Cost and runtime both scale with transcript volume, and Anthropic recommends scaling up only after you like the quality.
• Write instructions at the right altitude. Focus areas and output conventions work; line-level directives generally produce no change.
• Attach alongside before replacing. The output can sit next to the input store rather than in place of it.
• Do not touch the inputs mid-run. Archiving or deleting an input store or session fails the dream outright.
• Expect an empty outputs[] briefly. The output store ID appears shortly after the dream starts running, once the input has been cloned.
• Use the Memory Stores API for precise edits. Dreams reshape; the API edits.
• Clean up after a cancel. Canceled and failed dreams leave partial output stores in place on purpose.
• Re-check as it leaves preview. Dreaming is a research preview feature with its own beta header, and preview behavior moves.

The mechanism worth copying here is not the synthesis. It is the guarantee around it: read the store, read the transcripts, write a new store, and leave the original untouched so a human can say no.

That is a design that takes memory seriously as something you can be wrong about. Whether you have access to Dreams or not, the habit generalizes — curate deliberately, review before adopting, and keep the knowledge that matters somewhere you can read it yourself.