h t t p s : / / p l a t f o r m . c l a u d e . c o m / c o o k b o o k / m a n a g e d - a g e n t s - c m a - d r e a m i n g - w i t h - a - d y n a m i c - w o r k f l o w

Ingest: Dreaming with a dynamic workflow

Type: types/ingest-report.md ยท Tags: agent-memory, trace-learning

Classification

This is a vendor cookbook: an executable notebook recipe with its full agent prompts, a nightly cron script, one worked example run on eleven synthetic transcripts, and summary cost figures for a larger run. It reports what the authors built and ran, not a controlled study, so it is a practitioner report. The quality claim rests on an undisclosed fixed-fact recall check. Author: Anthropic (Claude Cookbook, dated 2026-11-02). The authors are authoritative about the platform mechanics: Managed Agents memory stores, workflow runs, mount limits and permissions. They are vendor-positioned on cost and quality and present no comparison with other memory designs.

Summary

The recipe builds a "dream": an offline background pass that turns an agent's finished session transcripts into a wiki-style memory store that later sessions mount read-only. A Sonnet lead agent receives a plain-language request and writes a Managed Agents dynamic workflow. In the first phase, one Haiku analyzer per transcript, running in groups of about 20, reads the transcript in full. It then checks existing memory claims against that transcript (Verify), adds exact identifiers, commands, dated staleness notes and process lessons (Enrich), and maintains small linked Markdown files with frontmatter, [[slug]] links and a shared _index.md (Organize). In the second phase, a single organizer runs after every analyzer has finished. It merges duplicates, retires files with MOVED TO stubs, records dated supersessions or CONFLICT: lines, and completes the index. The prompts carry an explicit concurrency discipline and a prompt-injection posture: transcripts and memory files are treated as data, tools are file-only, the network allowlist is empty and consumers mount the store read-only. A cron script repeats the pass nightly on newly finished sessions. Reported costs are $0.36 and 2.5 minutes for the eleven-file example, and about $8 and ten minutes for fifty long transcripts. The cost-reducing settings are reported to keep "about the same share of a fixed list of facts"; that comparison is made within one fixed pipeline. The recipe states plainly that there is no review by default and that raw records default to a temporary directory.

Quotes

No source quotes have been retained yet.

Connections Found

The source's main role is an operational counterpart to The components of agent memory, which compares with it on what is evaluated versus what is shipped. That report gives bounded experiments on offline correction and wiki building. This recipe gives the executable Verify/Enrich/Organize prompts but no outcome evaluation. A reader judging either one needs the other.

The recipe is bounding evidence for retaining episode evidence keeps a distilled rule open to re-examination. The analyzer prompt calls transcripts "the source of truth", but only as a precedence rule inside one pass: transcript evidence outranks what the memory files already say. Nothing keeps that evidence beside the claims afterwards. By default the exported transcript files sit in a temporary records folder that the system clears, the notebook deletes the dreaming session and its uploads, and later nights do not look back at earlier sessions; the agent's original sessions stay on the platform under its own retention, but no step consults them again. Consolidated claims therefore normally outlive the evidence that produced them, and a later pass can re-check a claim only if a new transcript touches it, unless the operator opts into permanent records. The recipe is also evidence for trace-extracted memory earns authority per operation, not at capture. Its Verify step automates one rung with a weak oracle: a small model compares memory against one transcript's text. The authority this grants is not recorded per fact, and no human review sits between the nightly write and the consuming agent.

Three mechanisms supply concrete cases for existing theory. The parallel-analyzer and single-organizer split is evidence for coordination guarantees, not just coordination channels. Its guarantee against inconsistency is explicit: re-read before editing, make only targeted index edits, read back after every write, link rather than merge during the parallel phase, and defer every merge and rename to a phase in which no other agent writes. The lifecycle operations are evidence for retire, redact, supersede, and relax memory: dated supersession, CONFLICT: marking when the later correction is unclear, MOVED TO retirement stubs, and version redaction for leaked secrets. The injection posture is evidence for one-medium interpretation of instructions and content: it enforces the role boundary architecturally rather than by prompt alone, and it names the residual risk when _index.md is loaded into a session's instructions.

For comparison on the model-authored orchestrator axis, see the Claude Code dynamic workflows review. This recipe runs the same pattern on Managed Agents predefined_agents and checks the lead agent's report against the platform's thread records rather than trusting it. The Karpathy LLM wiki compares on artifact shape: both are agent-maintained linked Markdown pages with an index. Karpathy keeps a raw-source layer and an interactive maintainer, while this recipe keeps no raw-transcript layer beside the store by default and maintains the store with an unattended batch. Language models need sleep compares on representational form: both use an offline consolidation schedule, but that paper writes to weights and this recipe writes to editable, versioned files.

Learning Claims (our opinion)

On its own terms, the mechanism is cross-session adaptation through an external file store. Agents leave transcripts. A nightly batch extracts dated facts, commands and process lessons, then checks them against stored memory. Later sessions read the result. No weights change, and the consuming agent never writes to the store.

Against the theory-builder definition, the conditions have different support:

  • Localized content is met by design. Memory is small named files with one-sentence index entries and dated fact lines. A wrong fact can be pointed at and revised without rewriting the store, so the store is moderately addressable.
  • Consumption is specified but not demonstrated. The store is mounted, and _index.md may be loaded into the system prompt, but the source shows no session whose decision changed because of a stored fact.
  • Criticism is content-directed but narrow. Verify compares stated claims with one transcript, downgrades overconfident claims and fixes or notes contradictions. The organizer marks unresolved conflicts rather than guessing. The worked run shows one such act: the organizer resolved a make test conflict as version-dependent and marked that resolution as inference. The only criticism available, however, is comparison of transcript testimony with memory text. Analyzers have file tools only and cannot run a command to test whether a stored fact still holds. A stale fact is detected only if a later transcript happens to contradict it.
  • Iteration is supported by the mechanism. Downgrades, staleness notes and conflict marks persist in the same store and are what the next night's Verify reads. No multi-night run is shown.

Results persist across runs and sessions, which is the high end of the persistence grade. The method texts, however, are outside the loop. The analyzer and organizer prompts are operator-edited files that no part of the dream criticizes or revises, so the system is not reflective in our sense. Under learning inside a fixed decomposition, the effective update space is the store's text. One transcript per analyzer, transcript-only evidence, the wiki file form and the model assignments are fixed outside it. The reported tuning, which kept a similar share of a fixed fact list at lower cost, is improvement inside that decomposition. It is not evidence that per-transcript fan-out, the wiki form or discarding transcripts is the right choice.

Learning, meaning improved capacity for future action, is not established. The only quality measure is recall of a fixed fact list, which shows retention, not changed behavior. The source therefore supports the plausibility of the mechanism and the existence of specific criticism acts. It neither supports nor puts in question Commonplace's account of when stored theory improves later work. It does add one distinction worth keeping: a dream that discards its episodes can criticize only claims that a new episode happens to touch.

Extractable Value

  1. The default configuration does not retain the oracle that Verify depends on. The recipe gives transcripts authority during extraction, then leaves the exported copies in a temporary records folder and never consults them again; the original sessions survive on the platform but outside the loop. This is a concrete vendor case for the retaining-episode-evidence note: without retained episodes, criticism of a stored claim waits for a new episode to touch it. It is also a candidate for comparing offline consolidation designs, alongside the Mt. Moon correction and Letta-style retained history. [quick-win]
  2. A layered concurrency guarantee for parallel writers to one memory store. The guarantee has four parts: re-read before edit, targeted index edits, read-back verification because "a write that reports success can still be replaced", and link-not-merge during the parallel phase, with merges deferred to a single-writer phase. This is a reusable pattern for any Commonplace workflow in which several workers update shared indexes, and it names the guarantee rather than the channel. [experiment]
  3. Architecture-enforced data/instruction separation for consolidation workers. The pattern combines several measures. Transcript text never enters a prompt and is opened by a read tool; workers hold only file tools; the network allowlist is empty; prompts state that inputs are data; and output is mounted read-only. The recipe also names the residual risk: loading store text into a system prompt lets injected text "steer every session". This bounds when an always-loaded index is safe. [just-a-reference]
  4. Concrete lifecycle markers for conflicting facts. A plain later correction keeps both dates and sources. An unresolved disagreement gets a CONFLICT: line. A single session's passing remark never overrides a recorded project decision. MOVED TO stubs serve as non-destructive retirement where no delete tool exists. These are precise operating rules for the retire/supersede requirement. [just-a-reference]
  5. The orchestrator's report is checked against platform records. The notebook counts analyzed transcripts from thread records, prints the workflow the lead agent wrote, and reports "where the run differed from what the message asked". This is a small, cheap check on a model-authored orchestrator. [just-a-reference]

Limitations (our opinion)

The quality evidence is thin and self-referential. "About the same share of a fixed list of facts" names neither the list, the scoring method nor the variance, and it compares only cost-saving variants of one pipeline. It does not show that the store improves later sessions; per evaluate memory by effects, not by existence, recall of planted facts is a retention measure, not an effect measure. The worked example uses eleven synthetic transcripts written for the cookbook. Their difficulties, a staleness change, buried details and overlapping topics, were designed to be ones the prompts handle, so they show survivorship of the intended path rather than real failure modes.

The Verify step's authority is weaker than its name suggests. A Haiku model compares memory with one transcript and has no way to run a command against the project. "Verified" in the store therefore means "consistent with something an agent saw once", and the store does not distinguish this from stronger verification. Combined with no default review and no retained transcript evidence beside the store, an error introduced one night can be re-checked only if a later session happens to contradict it. The recipe partly acknowledges this: "Agents should re-check any fact that matters."

The capture is the full cookbook page, but the helper module, the notebook cells and the scoring for the fact list are not in it. Platform limits such as 64 concurrent threads, 500 mounted files and a 4,096-character instructions cap are point-in-time research-preview facts that later releases may change. The recipe also positions itself against Anthropic's own Dreams preview; vendor interest favors showing the platform's flexibility over comparing it with simpler designs, such as a single sequential analyzer or appending raw transcripts with search.

Update Retaining episode evidence keeps a distilled rule open to re-examination with this recipe as the contrasting configuration to the already-cited Mt. Moon case. The recipe makes transcripts the Verify oracle during extraction, does not retain them as evidence beside the stored claims by default, and therefore can re-examine a consolidated claim only when a new transcript touches it. That note is currently modified in the working tree, so coordinate with that edit.