The problem is not forgetting
Anyone working with an agent system every day soon arrives at the same idea: it should remember things. Preferences, decisions, technical peculiarities, unfinished work. Individual notes soon become a long-term memory.
That is where the harder problem begins. Facts age. Two observations contradict each other. A one-off exception later looks like a rule. And the same statement ends up in three files, worded slightly differently. A larger memory is not automatically a better one. It is merely more convincing when it is wrong.
Three separate jobs
My workflow is called Dream. The name is playful; the process is deliberately sober. First, the system examines new conversations for knowledge that may remain useful beyond a single session. It then compares those candidates with the existing memory: are there duplicates, contradictions, outdated rules, or knowledge stored in the wrong place?
The result is not yet a change. It is a review with reasoned proposals. I accept or reject each one. Only a later run applies the accepted items and records what was actually changed.
Anthropic already lets Managed Agents dream
The term is not just my metaphor. Anthropic offers Dreams for Claude Managed Agents as a research preview. A dream reads an existing memory store together with up to 100 previous sessions. The asynchronous job merges duplicates, replaces stale or contradicted entries, and surfaces new connections.
By default, Anthropic writes the result to a new memory store. The original remains untouched, and the new version can be reviewed or discarded. That reversibility is the interesting part — not the human-sounding name.
The underlying memory feature for Managed Agents is in public beta. It is designed for enterprise operation, with scoped permissions, audit logs, exports, rollbacks, and stores shared across agents. Dreams itself has narrower availability: it is a research preview requiring separate access. It is therefore not a general toggle in Claude Enterprise, nor is it the same as personal chat memory.
The same problem, a different control point
My local Dream workflow grew out of a file-based knowledge base. It is strikingly similar to the product: conversations and existing memory are examined together, contradictions and duplicates become visible, and the result remains traceable.
The main difference is the hand-off. Anthropic's default creates a new consolidated store for subsequent review. My process first produces only a list of proposals. Changes to the actual knowledge base follow after I have accepted individual items. That is slower, but it fits a personal system in which one exception may carry more context than a hundred regular cases.
Why approval sits in the middle
A language model is good at finding similarities and contradictions. It does not automatically understand what an exception means. Perhaps an instruction applied to one specific task. Perhaps the newer statement is less precise than the older one. If the system stored its analysis directly as truth, a plausible mistake could rewrite its own foundation.
That is why analysis, decision, and application are separate phases. The agent prepares the thinking; authority over the memory remains with the human. This adds one step. It avoids the much more expensive search for an error that has already established itself as a memory.
What Dream is not
Dream is not overnight model training, nor an attempt to pretend a machine has consciousness. The model remains unchanged. What is maintained is a transparent knowledge layer made of files that can be read, compared, and versioned.
The workflow sends nothing without permission, deletes nothing without an accepted proposal, and keeps local conversation extracts separate from the versioned knowledge base. An interrupted run must not record success. Memory maintenance needs transactions too.
The goal is not for the agent to retain everything. The goal is for it to know what it can rely on — and to make visible where it cannot.