A clean comparison needs three separate terms. ReAct Memory is operational conversation memory: the rendered timeline, user messages, tool calls/results, files, plans, source pools, workspace state, working summaries, compaction summaries, indexed turn material, and retrieval over prior conversation work. User Memory is standalone durable product state owned by the user: records that can be created, edited, pinned, retired, searched, snapshotted, exported, restored, and reconciled. Curation is the process that reviews memory material and decides what should be merged, confirmed, retired, restored, or made durable.
1. Claude Dreams flow
Claude Dreams is described as an asynchronous job over persistent memory. In Anthropic's flow, the input is input to the dream job, not input to the next live assistant turn. The shape is concrete:
- Input: an existing memory store and selected past sessions.
- Run: an async dream job curates memory from those inputs.
- Output: a separate output memory store; the input memory store is not modified.
- Use: the output store can be attached to future sessions, archived, or deleted.
2. KDCube has two different flows
KDCube does not have one monolithic memory object. It has a live operational flow and a durable user-owned flow:
- Live ReAct flow: every turn receives a rendered operational context: current user request, timeline, summaries, compaction products, source pools, workspace state, tool results, files, and optional User Memory hotset/search tools.
- User Memory flow: durable user records are managed through UI/API operations: create, edit, pin, confirm, retire, search, snapshot, export, restore, and reconcile.
- Curation/reconciliation flow: a job can analyze User Memory records and propose changes. It is not the only place where ReAct Memory is curated; ReAct also produces summaries, indexes, and compaction products continuously as part of normal turns.
- Policy boundary: User Memory can enrich ReAct, but ReAct writes back to User Memory only when policy enables it. Otherwise User Memory remains manually curated by the user.
3. The three memory layers
| Layer | Owner | Role |
|---|---|---|
| Operational conversation memory | Runtime / agent workflow | Live-turn material and conversation recovery material. It is continuously shaped by summaries, compaction, previews, indexed notes, and retrieval. |
| User Memory | User | Durable user-owned store: user-visible records with text, context/reason, tags, keywords, scope, confidence, tier, evidence, lifecycle state, snapshots, export, and restore. |
| Reconciliation | User/apply operation plus configured job policy | Durable-memory curation mechanism: async analysis over User Memory records that produces proposals, exports, and snapshots without silently mutating durable memory. |
| Agent integration | Bundle policy | Optional use path: a bundle may project User Memory into a prompt, search/read it, or write/propose changes. ReAct is one consumer/producer, not the owner of User Memory. |
4. Side by side with Dreams
| Question | Claude Dreams | KDCube |
|---|---|---|
| Comparable object | The async dream job. | The async User Memory reconciliation job. ReAct Memory itself is broader because it also includes live-turn operational context. |
| Input to curation | An existing memory store plus selected past sessions. | For the current User Memory reconciler: existing User Memory records, their evidence counts, scores, tags, keywords, status, and snapshots. ReAct conversation memory is curated separately through summaries, indexes, and compaction as turns run. |
| Input to live turn | The dream output is not automatically a live-turn input unless the output store is attached to a later session. | ReAct receives operational context every turn: current user message, rendered timeline, tool results, source pool, workspace state, summaries, and optionally a User Memory hotset/search tools. |
| Curation output | A separate output memory store. | Reviewable reconciliation proposal artifacts and snapshots. Applying the proposal changes User Memory explicitly; restore can roll back from snapshot payloads. |
| What becomes durable? | The output memory store if attached to future sessions. | User Memory records after explicit create/edit/confirm/retire/apply/restore operations. ReAct timeline products remain operational conversation artifacts unless separately promoted by policy. |
| What protects the user? | The input store is not modified; output can be reviewed, archived, or deleted. | User-visible UI, snapshots, JSON/CSV/Markdown export, proposal review, explicit apply, lifecycle state, and restore from snapshot. |
| Where does ReAct fit? | Not part of the Dreams abstraction. | ReAct is the live agent runtime. It produces operational memory continuously and can consume or write User Memory only through configured integration points. |
5. User Memory is durable state, not the whole memory system
User Memory is where curated facts, preferences, constraints, and long-lived notes should land when they are meant to survive beyond one conversation and be manageable by the user. The memory note should start with the trigger and then state the rule. The context field should explain why the memory exists: provenance, examples, or a short reason. It is not a transcript replacement and not the ReAct timeline.
- Good note: “When preparing reading lists or learning notes, group items by topic first and chronology second unless the user explicitly asks for a timeline.”
- Good context: “Reason: topic-first grouping makes recurring study and review material easier to scan and search later.”
- Tags are categories for filtering. Keywords are search hooks and alternate terms.
- Tier controls how aggressively a memory can enter a model-facing hotset. User-pinned tier 1 memories should outrank ordinary inferred memories.
6. How ReAct can participate
ReAct has its own memory system. It sees a rendered timeline, ANNOUNCE, SOURCES POOL, tool results, plans, workspace state, summaries, compaction summaries, and indexed prior turn material. These are memory products produced during normal work, not only during a later reconciliation job. Separately, if User Memory is enabled for a bundle, ReAct can receive a compact hotset:
[USER MEMORY HOTSET]
enabled: true
policy: read-only; user message overrides memory; use memory.search for more
search_scope: current_bundle
- me:mem_... tier=1 salience=0.94 labels=[learning_preference]
When preparing reading lists or learning notes, group items by topic first and chronology second.That projection is only one integration. ReAct may also search/read User Memory, or write/propose memory changes, when policy enables those tools. Other bundle types can use User Memory without ReAct at all, and ReAct can still operate with its own operational memory even when durable User Memory is disabled.