claude dreams: Agents That Reorganize Memory Offline

The claude dreams feature is Anthropic's answer to a problem every long-running agent eventually hits: memory that grows messier the longer the agent works. On November 6, Anthropic published a research post called The components of agent memory, alongside a Dreams API in research preview for Claude Managed Agents. A dream is an offline job that reads an agent's memory store plus past session transcripts and produces a new, reorganized memory store: duplicates merged, stale entries replaced, mistakes corrected against the transcript record. Source

The name is literal. Anthropic draws the analogy from neuroscience: humans encode experience constantly, but much of the consolidation into long-term knowledge happens offline, during sleep and quiet rest, when the hippocampus replays recent experience and distills it into the neocortex. Anthropic credits researchers at Letta and UC Berkeley with the sleep-time compute proposal: use idle time between interactions to reorganize existing context. Dreaming is that idea applied to agent memory. Source

What Anthropic shipped

The Dreams API is in research preview on Claude Managed Agents. A dream is an asynchronous job that takes two inputs: a pre-existing memory store, which Claude verifies, deduplicates, and reorganizes, and one to one hundred past sessions, whose transcripts Claude mines for patterns to fold into the output. The dream produces a separate output memory store. The input store is never modified, so a team can review the result and discard it if the reorganization went somewhere unhelpful. Source

The API call itself is small: a POST to /v1/dreams with the memory store ID, the session IDs, a model (the docs show claude-opus-5-5), and optional instructions that steer what the dream focuses on, such as "focus on coding-style preferences; ignore one-off debugging notes." For teams that want more control, Anthropic's Claude Cookbook includes a recipe for building a custom dream with your own prompts and models, where you decide when it runs, which transcripts it reads, and what it does with them. Source

The problem statement in the docs will be familiar to anyone running agents for more than a few days: agents write to their memory stores as they work, but those writes are local and incremental. Over many sessions a store accumulates duplicates, contradictions, and stale entries. Dreaming is the cleanup pass. Source

The memory hierarchy underneath

The research post is the more interesting read, because it explains the structure dreaming operates on. Anthropic describes a memory hierarchy between one session and the next: transcripts at the bottom (a searchable event log), then memory notes written by Claude, then memory representations such as wikis, and at the top a small set of injected context loaded into every session. Dreaming connects the layers: it pushes corrections from transcripts up to notes, builds representations from notes, and promotes or demotes items between the layers. Source

One framing in the post is worth quoting in substance: memory is a prediction about what the future will need. When an agent writes down a rule, it is predicting the pattern will be relevant again. A wrong or stale note is therefore not just clutter; it is a bad prediction that gets carried into every future session that loads it. Anthropic's own documentation warns that longer instruction files reduce adherence, which is why the top layer of the hierarchy has to stay small, and why much of dreaming's work is moving detail down the hierarchy while leaving links behind. Source

What the evaluations show

Anthropic backed the post with several evaluations, and the numbers are concrete enough to repeat carefully, with attribution. On a Continual Learning Bench (CL-Bench 1.0) database task, where Claude answered questions, was told the correct solution, and could write memories for future questions, a memory store lifted every model tested over its stateless baseline. Opus 5.5 went from 0.655 to 0.838 mean reward, Sonnet 5.5 from 0.644 to 0.833, and Opus 5 from 0.564 to 0.828. The weakest memory user in the chart, Sonnet 4.6, barely moved, from 0.330 to 0.364; Anthropic says it got as far as listing untested theories rather than closing the learning loop. Source

A Pokemon Red evaluation tested judgment about what to save. Anthropic compared memory folders partway through one run each of Claude Sonnet 3.7 and Claude Fable 5. Sonnet 3.7 wrote to memory indiscriminately: 413 files across 225 folders, covering nearly every battle, item, and character, and earned one badge. Fable 5 wrote nine files in two folders plus one top-level global.md, and earned four badges. Salience judgment, not volume, tracked progress. Source

The dreaming-specific test is the cleanest demo. In a Pokemon run using Managed Agents, Claude's memory contained a wrong note about the location of a PokeCenter, which sent it heading the wrong way out of Mt. Moon. Anthropic ran dreaming on the memory folder; Claude checked the note against the session transcript, caught the error, and rewrote it. With the corrected note, the run went back into the cave and reached Cerulean City at action 1,935. The run with the uncorrected note never got past the mountain, and neither did a run with no memory at all. Source

The largest test used a corpus of internal documents from Stainless, a software company Anthropic says it acquired in May: about 350,000 files, roughly 420 million tokens. Anthropic had Claude build a wiki from the corpus using dreaming over 128 sessions, with agents exploring files, writing and correcting linked pages, merging duplicates, and checking claims against sources. As dreaming scaled from 2 sessions to 128, answers graded on 25 questions rose from 13% to 48% of criteria using the wiki alone. With a search tool plus the growing wiki, scores rose from 54% to 61%, compared with 53% for search alone, and the wiki plus search combination saved about 20,000 tokens per question. Source

Our read

This section is our assessment, not Anthropic's claims. The shipment that matters here is not the API endpoint; it is the admission, backed by evals, that agent memory is an operations problem rather than a storage problem. Every team running agents in production already has the failure modes the docs describe: duplicated notes, contradicted facts, stale entries nobody prunes. Anthropic is the first major lab to ship the maintenance pass as a first-class primitive, with the transcript as ground truth and the input store left untouched so the cleanup is reviewable.

Two cautions fit naturally with what we have written before. First, a memory store an agent rewrites offline is also an attack surface: our piece on AI agent memory poisoning covers what happens when bad content reaches memory, and an offline consolidation pass raises the stakes on getting provenance right, because a poisoned note can now be promoted, not just stored. Second, the governance question (who reviews the output store, what gets promoted into every session's context, how you roll back) is the same class of problem as memory governance in MongoDB's Atlas agent engine: the tooling is arriving faster than the operating discipline around it.

For teams building agents that own ongoing work, like the pattern we covered in perplexity teammates, dreaming closes a real gap. An agent that runs for weeks accumulates exactly the kind of memory drift this feature targets. Our practical advice: treat the output store like a pull request. Review it, diff it against the input, promote it deliberately, and keep the raw transcripts as the ground truth you can always rebuild from.