What Is Agent Dreaming, and When Should You Use It?

An agent that keeps memory between tasks writes notes as it works. Over many sessions, those notes collect duplicates, contradictions, and stale entries. The next customer task loads them anyway. Anthropic's research team describes the risk as a note that is wrong from the start or drifts as the environment changes, and that "can be read, and trusted, by Claude in a later session."

Agent dreaming is one response. It is a separate process that reviews an agent's past experience and improves its saved memory between live tasks. Anthropic now offers a hosted version called Dreams in research preview, though the idea predates it.

Our recommendation: keep search over the original record as your default. Adopt dreaming after you have watched a repeat task fail because of a saved note, and after a reviewed candidate memory beats your current setup on your own fixed task set. A good memory benchmark score does not show that your customers' tasks get done better.

TL;DR

• Agent dreaming is offline upkeep of saved memory. A separate pass checks notes against past sessions and writes a cleaner set. Model weights stay the same.
• Searching original transcripts can be enough. Anthropic calls transcript search a reasonable foundation for Claude's memory.
• Anthropic's published gains come from its own evaluations, with small question sets. They do not predict results on your customer tasks.
• Adopt when a repeat task fails because of a saved note, a named person owns review, and you can test on a fixed task set.
• Keep the original memory, write the candidate to a separate store, review it, repeat the task, then promote or reject.

What agent dreaming means

In the generic sense, dreaming is any process that runs between live tasks, reads what the agent did before, and rewrites its saved memory. Anthropic's article describes Claude reflecting on logs to fix mistakes, and adds that this process is often called dreaming.

Dreams, with a capital D, is a hosted feature in Claude Managed Agents. According to the Dreams docs, a dream reads a memory store alongside past session transcripts. It then produces a new store with duplicates merged and stale or contradicted entries replaced. Letta has its own version: its memory docs describe background subagents that review recent conversations, configured with /sleeptime. Below, "dreaming" means the general idea and "Dreams" means Anthropic's product.

A short chronology

• April 2023: the Generative Agents paper (Park et al.) describes agents that "synthesize those memories over time into higher-level reflections."
• April 2025: the sleep-time compute paper (Lin et al., Letta and UC Berkeley) studies letting a model work on its context before the next query arrives.
• May 19, 2026: Anthropic launches dreaming in Claude Managed Agents as a research preview.
• November 6, 2026: Anthropic publishes the research article "The components of agent memory."

So the pattern is several years old, and Anthropic's November article prompted fresh discussion of it. In the Hacker News thread on that article, one commenter pointed out that background memory reconciliation has been discussed since at least 2023.

Four kinds of memory, and when search is enough

• Notes: short facts the agent writes during a task, kept in a memory store.
• Original transcripts: the full record of past sessions, which the agent can search.
• Derived representations: wiki pages or consolidated notes built from the first two. Dreaming produces these.
• Injected context: what actually loads into the next session.

A stale note does damage only when it reaches injected context. Claude Code shows how direct that path can be: its auto memory loads the first 200 lines of MEMORY.md, or the first 25KB, at the start of every session.

Anthropic writes that "It's also reasonable to consider transcript search as the foundation of Claude's memory." Practitioners say similar things. One Hacker News commenter found transcripts of older sessions to be the most useful memory so far.

Search is enough when the answer lives in one place in the original record. A legal-brief task from the Harvey LAB benchmark, which Anthropic tested, shows this. The brief criteria could often be found with a text search in a single document, and Anthropic reports that the wiki showed no clear gain over search. On another LAB task, the wiki grew larger than the documents it summarized.

What dreaming is not

Only dreaming targets what the next session will read. The categories overlap in two places. Letta can trigger dreaming when the context window is compacted, and hosted Dreams run as asynchronous jobs that typically take minutes to a few hours.

What the published evaluations show

Every number below is the vendor's or the researchers' own measurement, on their tasks. We found no independent reproduction of any of them, and we have not run them ourselves.

Anthropic also gives a Pokémon example from its own testing. It describes one run with a wrong note about where a building was, which never reached Cerulean City, and one run with the corrected note, which did.

Two of Anthropic's tasks point the same way, though the article does not name the cause. Derived memory helped on the merger questions that needed information from several documents. It showed no clear gain on a task where the criteria could often be found in a single document. The sleep-time paper reports a related limit: the approach is less effective when queries are hard to predict or unrelated to the context. Anthropic is open about the limits too, writing that it still has a lot to learn about designing memory systems.

The strongest case for upkeep now

A saved note can go stale and still be read and trusted in a later session. When you first observe a failure, a customer may already have received a wrong answer. Anthropic's Pokémon example shows this happening. The launch post also notes that dreaming can update memory automatically, or let you review changes before they land. On this view, regular upkeep is a safeguard worth paying for.

The vendor evaluations support this view, but none of them tested your tasks. Anthropic itself says that "Directing Claude to continuously check all its memories might not be practical." Unreviewed upkeep can also add the problems it was meant to remove. One commenter warned that dreaming leads to memory bloat and outdated entries. After a one-week trial of OpenClaw Dreaming, Solomon Neas concluded it is "not trustworthy enough yet to be the primary curation mechanism."

A low-cost safeguard is to keep originals and sample notes against transcripts on a schedule. That audit finds decay without rewriting anything, and it tells you whether your current memory works. If you cannot staff review of another background process, defer dreaming.

Illustrative example: correcting one stale note

(opens the full-size image in a new tab)

Illustrative example. The scenario and steps below are a safe design we propose for testing one note. They are not any vendor's implementation.

A support agent's saved note says a customer's API uses an older auth header. The customer moved to a new header and said so in a later session, but repeat tickets still get the old one.

1. Trace the failure. A repeat ticket cites the old header, and you trace that answer to one saved note.
2. Verify against the source. Open the transcript where the note was written and the later session where the customer described the change. Anthropic calls the transcript "a ground truth to validate its memory against."
3. Propose a correction. A dreaming pass or a person drafts the corrected note, with a pointer to its source session.
4. Write it to a separate store. The candidate goes into a new memory store. The original stays as it was.
5. Review it. A named owner compares the two stores and checks each source pointer.
6. Repeat the task. Run the failed ticket again against the candidate, plus nearby tasks that read the same memory.
7. Promote or reject. If the candidate answers correctly and nothing else got worse, attach it to live sessions. If not, delete it; live sessions never saw it.

In this design, rollback means pointing sessions back at the original store, which still exists because nothing wrote to it.

What hosted Dreams does, and what it leaves to you

Hosted Dreams covers step 4. A dream writes to an output store separate from its input, and the docs say "The input store is never modified, so you can review the output and discard it if you don't like the result." You start one through the API (POST /v1/dreams) or the CLI (ant beta:dreams create), passing one memory store and 1 to 100 sessions. An optional instructions field steers the run. The docs describe it as a synthesis pass rather than an editor, so line-level directives generally change nothing.

Review and promotion are yours. The original store stays intact unless you delete it. Every change to a memory creates a version, but the memory docs say past versions might be deleted after 30 days, so export them if you need a longer history.

Other implementations write differently, so check where yours writes. Anthropic's cookbook recipe says its nightly script updates a store in place, with no review by default. Its safer path builds a new store you read before your agent mounts it. Letta's agent-review option does not ask you for approval.

Where hosted Dreams stands

The table reflects the Dreams docs and memory docs as of November 9, 2026. Check both pages again before you plan around them.

The docs advise starting with a small batch of sessions, which also keeps a first trial cheap to review.

Portability is unsettled. LoreKit argues it is "the moment to agree on a shared shape" for agent memory and sketches an illustrative record labeled agent-memory/0.1. That is a call for a standard, and the post names no vendor that supports it.

Adopt or defer: a checklist

Adopt when all seven rows read "adopt." If the observed-failure row is empty, defer, whatever the other rows say. Check four risks before a trial.

Poisoning: the memory docs warn that a successful prompt injection could write malicious content into a store, which later sessions then read as trusted memory. A dreaming pass reads transcripts, so injected text can travel into memory. Review and source pointers are your check.

Sensitive data: given the data-handling entries above, keep regulated data out of hosted Dreams.

Overgeneralization: one commenter observed that models "have a tendency to over-generalize their thoughts when they are creating memories." Advice that fit one customer can become a rule for all of them.

Incorrect consolidation: a merge can keep the wrong value or keep noise. In his trial, Neas found that without strict filtering, dreaming kept surfacing items that were technically recallable and semantically worthless. The repeat-the-task step is meant to catch this before a customer sees it.

How to test a candidate: three arms, one task set

Build a fixed task set from recurring work, including the task that failed and nearby tasks that read the same memory. Keep inputs, model, and grading the same across every run. Then compare three arms.

1. Transcript retrieval: the agent searches original sessions and loads no saved notes.
2. Existing memory: the agent uses the current store as it is.
3. Curated memory: the agent uses the dreamed and reviewed candidate store.

Measure four things per arm. Completed-task correctness counts tasks graded right against a known answer. Harmful memory reuse counts tasks where a loaded note made the answer wrong or carried one customer's guidance into another's task. Track latency per task, and cost as tokens per task plus the dreaming run's share.

This mirrors Anthropic's comparison of search, wiki, and both, run on your own tasks. Promote the curated store only if correctness rises and harmful reuse does not, against both other arms, at a latency and cost you accept. If transcript retrieval matches the curated arm, keep retrieval, because it has fewer components to run and review.

Which path fits your situation

• Mostly one-off tasks: use transcript retrieval and skip dreaming.
• Recurring tasks with no observed failure: keep your current memory and audit a sample of notes against transcripts.
• Recurring tasks with a traced stale-note failure: trial one reviewed candidate with the three-arm test.
• Regulated or sensitive data: keep it out of hosted Dreams for now.

Start with one recurrent failure

Find a repeat task that went wrong because of a saved note. Leave the original store untouched, and export its version history if you need more than 30 days of it. Trial one reviewed candidate in a separate store, then repeat the task before you adopt dreaming broadly. The Dreams docs and the cookbook recipe show two ways to run that trial on Anthropic's platform.

---

Sources

• Anthropic, "The components of agent memory"
• Claude docs, "Dreams"
• Claude blog, "New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration"
• Claude docs, "Using agent memory"
• Claude Cookbook, "Dreaming with a dynamic workflow"
• Lin et al., "Sleep-time Compute: Beyond Inference Scaling at Test-time"
• Park et al., "Generative Agents: Interactive Simulacra of Human Behavior"
• Letta docs, "Memory & dreaming"
• Claude Code docs, "How Claude remembers your project"
• Hacker News, "The Components of Agent Memory" discussion
• LoreKit, "Agent memory needs its OpenTelemetry moment"
• Solomon Neas, "Dreaming Is Useful. Structured Memory Is Better"