Anthropic · Claude Managed Agents
Dreaming: learning while you sleep
By day, agents work and write what they learn into a shared memory. By night, a separate agent reads the transcripts of every session, spots what no single agent could see, and proposes a diff of the memory, which is reviewed before it is applied. The next day's agents start smarter.
Memory: public beta. Dreaming: research preview. note:31
Based on two Anthropic talks: the concept (Lamis Mukta) and the launch and demo (Mahesh).
How did we end up with memory as files?
Four steps of context engineering. Each step gives the agent more autonomy, but leaves one problem unsolved. Step through them.
What happens if two agents edit the same note at the same time?
The memory API uses optimistic concurrency: the agent reads the content hash, drafts its edit, then checks the hash has not changed before writing. If it has, it re-reads and tries again. Make both agents write.
SRE agent #1
Hash read:
Wants to add: "P1 alert tied to the payment service"
SRE agent #2
Hash read:
Wants to add: "pod restart had no effect"
Illustration: the "hash" shown is a simple calculation on the text, not the API's algorithm. The mechanism (read, draft, check, retry) is the one from the talk. note:49
Why can't a single agent see the problem?
In the demo, every alert fires exactly 60 s after an upstream CPU spike. One session sees one alert; only someone reading many sessions sees the pattern. Increase the number of sessions read.
In-band memory (one agent)
Dreaming (out of band)
Illustration: the talk only says the orchestrator keeps the patterns "frequent enough to justify a change". The threshold of 5 occurrences and the share of affected sessions (2 out of 3) are made up for the demo. note:55 note:111
What does dreaming propose, and who decides?
Dreaming does not write directly: it produces a diff, with the transcripts that back each change and how often it occurred. A human, or an automated check, accepts or rejects it. Here is the demo's diff; review it.
SRE memory store, the next day:
The four kinds of change (one addition, five duplicates merged, one stale entry removed, one "verified" mark) come from the demo. The text of the store entries and the justifications are made up for the example. note:111
The two loops side by side
The design lesson: an agent works best with a single objective. Memory quality becomes a separate objective, with its own budget, off the hot path. note:62
| Memory (in band) | Dreaming (out of band) | |
|---|---|---|
| Who | the working agent | an orchestrator and its sub-agents |
| When | during the session | in batch: cron, on demand, end of task |
| Sees | its own session | many sessions and agents |
| Cost | tokens taken from the task, latency | its own budget |
| Good at | quick, local learnings | patterns, duplicates, staleness, verification |
note:80–85
Where to start?
- At the very least: a
CLAUDE.md, skills, and let the agent manage them. - Many agents or a complex domain: add versions, hashes, permissions, a portable API.
- To close the loop: an out-of-band consolidation pass, dreaming.
note:113–116
Results quoted by Anthropic: Rakuten, −90% first-pass mistakes thanks to memory; Harvey, 6× success rate on a legal scenario with dreaming. note:57