An agent remembers that a project uses one deployment method. Several sessions later, the project has changed. The old fact remains easy to retrieve, the new fact is scattered across conversation fragments, and both sound authoritative when placed in a prompt.
AutoDream attempts to turn that accumulation into maintained memory. It reviews sessions and vector memories, proposes durable Markdown changes, builds an index, and synchronizes active files back into Agent Zero's built-in memory store. The compelling part is not the sleep metaphor. It is the set of rules governing what a generated maintenance plan may replace or delete. AutoDream overview
Research basis: We reviewed AutoDream 1.0.7 by Alessandro Frau (
3clyp50) ate2c22dd9c78e. We ran its coverage, safety, and statistics scripts with the Agent Zero framework runtime in an isolated container. They passed with mocked model/database calls and temporary data. We did not run a dream over personal chats or measure retrieval quality before and after consolidation.
The short version
- Reflection sits above storage. AutoDream maintains Markdown artifacts and synchronizes them with built-in memory.
- Generated changes pass host validation. Unseen files, stale sources and unsupported deletion plans are rejected.
- Recovery has a precise limit. File writes are atomic; an entire dream is not one transaction.
| Artifact | Role |
|---|---|
MEMORY.md |
Compact index |
memories/*.md |
Active durable content |
archive/ |
Retained originals outside active retrieval |
| Processing checkpoint | Coverage boundary advanced after a successful run |
Reflection is layered on storage
AutoDream depends on _memory for vector storage, similarity search, and memory-scope resolution. It owns the reflective pass and its Markdown artifacts. These responsibilities are separate: _memory can retrieve stored material; AutoDream tries to reorganize selected material into something more durable and coherent. Dependency model Dream runner
This distinction also limits a tempting claim in the README's introduction: the built-in memory system has its own consolidation code in the reviewed Agent Zero checkout. AutoDream should not be explained on the premise that core has no memory-maintenance behavior at all. Its particular contribution is the reflective, file-backed workflow and its explicit provenance and mutation checks. Core memory consolidation
The durable files live inside the resolved memory scope, rather than one assumed global repository folder. MEMORY.md is an index. The actual memory content lives under autodream/memories/. This makes a small navigational file compatible with a larger collection of inspectable records.
Coverage requires more than a recent slice
The reviewed runner processes pending material in batches of up to eight sessions and sixteen recent vector memories. It refreshes files and the index between learning batches, then performs consolidation according to configuration. A successful processing checkpoint advances to the run's start time only after the batches and vector synchronization succeed. Batching and checkpoint logic
That ordering protects two boundaries. A backlog should not disappear merely because it exceeded one model call's input budget. Activity arriving while the dream runs should remain eligible for the next run. Vector timestamps have only second precision, so the boundary second is replayed rather than excluded too aggressively.
A failed run leaves the previous checkpoint in place. This improves coverage but also means already applied batches may be revisited. Do not confuse “checkpoint did not advance” with “nothing changed.” The README explicitly documents that distinction.
The model proposes; the host validates
Selected existing memories are supplied as complete files with metadata, up to 24 files within a 60,000-character JSON budget. A file that does not fit is deferred rather than truncated and then offered for replacement. Input selection
That is an important editorial constraint. A model shown only the beginning and end of a long record cannot reliably preserve a critical fact in its middle. Whole-file input does not guarantee good judgment, but it removes one avoidable reason for destructive rewriting.
Before mutation, the host validates the complete plan. It rejects unknown fields and actions, duplicate targets, invalid paths, unseen replacement targets, invented source identifiers, stale source checksums, and symlink targets. Deleting a memory requires a replacement upsert in the same plan that identifies the original among its source files. Plan validation and application
These checks turn a model's request into a constrained edit proposal. The model cannot make an arbitrary Markdown file authoritative merely by naming it. Nor can it safely delete an unseen file on the theory that it is probably redundant.
Provenance is necessary and still insufficient
Merges inherit source chat identifiers, vector identifiers, first-prompt references, and file lineage. An inferred source remains inferred through a merge; combining it with another record does not automatically promote it to grounded knowledge. Metadata inheritance
This provides an answer to “where did this record come from?” It does not prove that the generated sentence faithfully represents those sources. The README says so directly. A model can cite a real session and still misunderstand it.
Treat consequential inferred memories as review candidates. A useful review checks the underlying source, whether a fact remains current, and whether the record is descriptive or instructive. AutoDream recognizes a .promptinclude.md suffix as a classification, but does not itself load such files into system instructions or authorize inferred instructions. Safety contract
Recovery has a precise granularity
Before replacement or deletion, the plugin saves the original bytes into a content-addressed archive. Replacements are written before their source files are removed. Writes use Agent Zero's atomic stream helper. These choices help preserve recoverability across interrupted writes. Archive and write order
Atomicity is per file, however. A multi-file merge or a whole dream is not one transaction, and an I/O failure can leave an applied subset. There is no automatic rollback across the entire operation. Recovery means reviewing active files, restoring selected archived originals, and removing an unwanted replacement where appropriate.
The archive is excluded from active discovery, indexing, and AutoDream's vector synchronization. It is still retained data. A memory disappearing from active recall does not mean its original bytes have been erased. A request to forget information needs a separate examination of active files, vectors, archives, and other copies. Recovery and retention limits
Measure useful recall, not fewer files
A lower memory-file count can mean successful consolidation, lost distinctions, or both. A longer index can look informative while overloading the next prompt. Neither is a sufficient quality metric.
A practical evaluation would preserve a fixed set of project questions before a dream: an old decision that should remain, a superseded fact that should be corrected, and a paraphrased query whose relevant evidence must still be found. Compare the recalled evidence and final answers afterward. Keep the underlying source judgments separate from the model's self-assessment. This is our proposed experiment, not a result of the safety tests.
The Dream journal supplies completed/failed attempts, estimated text tokens, utility calls, duration, and file counts. Those figures can help relate benefit to maintenance effort. They exclude provider-specific billing details, embeddings, hidden reasoning, and some retry effects, so they are not a complete cost statement. Statistics design Statistics implementation
What we actually verified
The three repository scripts passed. The safety script specifically exercised whole-file input, twenty rejected mutation plans, stale snapshots, symlinks, archive and partial-write failures, provenance across rewrites, and valid no-op plans. Coverage tests exercised backlog batching and failed-checkpoint behavior. Statistics tests checked bookkeeping separately from memory success. Safety tests Coverage tests Statistics tests
These are useful results about the machinery around reflection. They do not establish that the utility model's summaries are accurate or that a particular project will answer questions better afterward.
AutoDream is best understood as a maintained memory pipeline with recoverable edits. Its strongest feature is the way it limits and records change, leaving the harder question—whether the new memory is better—open to evidence and review.
Sources
AutoDream 1.0.7, Alessandro Frau /
3clyp50, reviewed ate2c22dd9c78e.Built-in memory, core
ff2a5b9c9c4e.All motion illustrations are original and derived from the reviewed sources. Illustrative data is labeled.