Anthropic published an account of its agent-memory experiments on November 6, describing how background review can correct mistakes that would otherwise persist across sessions. For developers building agents that remember earlier work, the practical question is whether a saved note remains trustworthy when the agent uses it again.
The company calls this review process dreaming. Here, memory means saved context that Claude can read later, rather than changes to model weights. The examples below are Anthropic's reported results; we haven't reproduced them.
A saved mistake can steer the next session
In one Pokémon experiment, Claude recorded a landmark on the wrong side of a mountain. That mistaken note helped send it back over a ledge instead of through the cave. Checking the note against the session transcript exposed the error and prompted a correction. In the corrected run, Claude reached Cerulean City. The run retaining the bad note never did.
That example suggests a concrete evaluation for agent builders: deliberately save an incorrect fact, retain the evidence needed to correct it, and check whether a later session repairs the note before acting on it. A successful retrieval alone wouldn't answer that question.
The underlying idea predates this report. An April 2025 paper on sleep-time compute proposed processing context before a user asks a question, and found that query predictability correlated with the method's effectiveness. Anthropic's post applies background processing to memory maintenance; it doesn't establish the invention of offline reasoning.
Review the replacement before attaching it
The current Dreams documentation describes a job that reads an existing memory store and past session transcripts, then builds a reorganized store. The input memory store is left unchanged. Developers can inspect the output and attach it to future sessions or discard it. Dreams are in research preview on select models. These are documented capabilities, not a launch date established by the November 6 post.
That separation gives an application somewhere to put a review step. For a trial, compare the original and proposed stores against the same transcripts, then test whether corrected notes change subsequent answers. We haven't run that trial or verified the API's behavior ourselves.
Background processing also has a bill. Dreams use standard API token rates for the selected model. The documentation says cost scales roughly with the number and length of input sessions and recommends starting with a small batch. The next useful evidence is whether repeated reviews prevent enough downstream errors to justify that extra processing, especially when the stored facts keep changing.