[Feature]: Dream Mode — Periodic Memory Consolidation & Reflective Learning

[Svtter]

[Feature]: Dream Mode — Periodic Memory Consolidation & Reflective Learning

Summary

Enable ZeroClaw to enter a Dream Mode during idle periods — a lightweight background process that consolidates daily memories, reflects on recent interactions, and updates long-term knowledge structures without requiring active user engagement.

Motivation

Current memory systems rely on explicit capture during active conversations. Important context, patterns, and lessons are often lost between sessions. A periodic "dream" process would:

• Consolidate daily notes (memory/YYYY-MM-DD.md) into MEMORY.md
• Identify patterns across interactions (recurring topics, unresolved loops, user preference shifts)
• Prune stale or contradictory memories
• Pre-compute context so the agent wakes up smarter each session

Proposed Behavior

Trigger Conditions

• Idle timeout (configurable, default: 30 min no interaction)
• Cron schedule (e.g., nightly at 03:00 UTC)
• Manual trigger via command: /dream

Dream Cycle

1. Gather — Collect recent daily notes, open loops, and conversation summaries
2. Reflect — LLM pass to identify patterns, lessons, and preference changes
3. Consolidate — Update MEMORY.md with distilled insights
4. Prune — Remove resolved loops, outdated facts, and redundant entries
5. Report — Optional summary sent to user on next interaction ("While you were away…")

Safety

• Read-only by default (dream writes only to designated memory files)
• User can review all changes before they persist (opt-in audit mode)
• No external actions during dream (no API calls, messages, etc.)

Design Considerations

• Token cost — Dream cycles should use a lightweight/cheap model
• Concurrency — Must not interfere with active sessions
• State recovery — If dream is interrupted, it should resume cleanly
• Configurable depth — Users should control how aggressive consolidation is

Open Questions

• Should dream mode support multi-day consolidation (catching up after weekends)?
• Should it generate a "dream log" for transparency, or just update MEMORY.md silently?
• How to handle conflicts between user-edited MEMORY.md and auto-consolidated content?

Cross-References

OpenClaw — Issues

• #64756 — [Bug] Dreaming page text on top of the dreaming page dashboard
• #67413 — Feature Request: Per-agent dreaming configuration
• #65630 — Decouple dreaming from memory slot
• #67397 — [Bug] Dreaming cron skipped by heartbeat activeHours
• #67562 — Dreaming narrative push fails on Feishu due to hardcoded "default" target
• #66358 — [Bug] Dreaming creates redundant sessions after sweep
• #65963 — Dreaming: session sprawl, missing model override, no auto-cleanup
• #66947 — Dreaming system pollutes daily memory files
• #67912 — [Bug] Dreaming overwrites daily memory files instead of only writing to memory/.dreams/
• #67058 — [Feature] Add session list filter to hide dreaming/system sessions
• #67868 — Memory status reports "Dreaming: off" when only light phase is enabled
• #67611 — [Feature] Automatic Cleanup of Dreaming sessions
• #66185 — [Bug] Dreaming cron reports success but produces no artifacts
• #67016 — Dreaming UI lacks status information
• #63372 — [Feature] Allow dreaming to use a configurable model override
• #65367 — [Bug] Dreaming iterates all agent workspaces serially with no config to scope

OpenClaw — PRs

• #67846 — Memory: validate dreaming cron frequency
• #67420 — feat(memory): per-agent dreaming control
• #67882 — fix(memory-core): report active dreaming phases in memory status
• #67833 — fix(memory-core): run managed dreaming cron in isolated agent turns
• #67073 — fix(dreaming): use isolated sessionTarget instead of main
• #66583 — feat(memory-core): add dreaming.model config field
• #67023 — fix(memory-core): prevent dreaming-narrative session leaks
• #67601 — fix(memory-core): stop dreaming from promoting transport metadata
• #65589 — feat(memory-core): dreaming circuit breaker
• #67697 — feat(memory-core): persist session trigger, exclude cron/heartbeat from dreaming
• #66152 — fix(memory-core): add dreaming config to plugin schema

Hermes Agent — Issues

• #5533 — feat(dreaming): introduce stable Dreaming reflection mode
• #10771 — Feature Request: Automatic Memory Consolidation (Auto Dream)
• #7896 — [Feature] CerebroCortex memory provider with dream consolidation
• #8457 — Persistent Session Memory with Cross-Session Search & Auto-Compression

Hermes Agent — PRs

• #9225 — Add local-first memory recall and dreaming MVP

[singlerider]

@Svtter I wonder if the functionality you're describing could be done with the HEARTBEAT.md system without patches to the project?

[theonlyhennygod]

Triage Summary

Type: Feature request
Priority: Low
Area: memory, cron
Risk: Medium

Summary: Proposes a "Dream Mode" — a periodic background process that consolidates daily memories, reflects on interaction patterns, prunes stale data, and pre-computes context during idle periods. The feature would run via cron or idle timeout and update MEMORY.md with distilled insights.

Duplicates/Related: None found in ZeroClaw. The author provides extensive cross-references to OpenClaw's dreaming system (issues and PRs) and Hermes Agent's memory consolidation features, demonstrating prior art.

Actionability: Ready for maintainer evaluation. The proposal is well-specified with trigger conditions, cycle steps, safety constraints, and open questions. However, a collaborator (@singlerider) has already commented suggesting this might be achievable with the existing HEARTBEAT.md system without core patches — that trade-off should be evaluated before committing to a new subsystem.

Notes: This is a significant feature with architectural implications. The proposal involves LLM calls during idle time (token cost), concurrent access to memory files, and a new execution mode. Fits within trait-driven architecture if implemented as a memory backend extension. The "zero external infra" constraint is satisfied since it uses local files, but the token cost concern is real for edge deployments.

[Svtter]

@Svtter I wonder if the functionality you're describing could be done with the HEARTBEAT.md system without patches to the project?

@singlerider HEARTBEAT.md alone isn't enough — new code would still be needed.

HEARTBEAT.md handles the scheduling layer (periodic triggers, idle-time detection, two-phase LLM decision), which is exactly what Dream Mode needs for its cron/timeout triggers. So it's the right foundation for when to run.

But Dream Mode's core value is the memory consolidation pipeline — and that doesn't exist yet:

• ZeroClaw has consolidate_turn() for per-turn fact extraction (real-time, single conversation turn), but Dream Mode needs batch consolidation across days/sessions — a fundamentally different granularity. [Bug] memory-core dreaming cron reports success but produces no artifacts and exits in ~6-8ms openclaw/openclaw#66185
• No pruning logic to detect and remove stale/contradictory memories. The current consolidation module only adds facts; it never removes them. Dreaming system pollutes daily memory files, causing heartbeat agents to skip memory logging openclaw/openclaw#66947
• No reflective analysis (pattern detection across interactions, preference shift tracking, recurring topic identification).
• No "while you were away" reporting. memory-core: dreaming narrative push fails on Feishu due to hardcoded "default" target openclaw/openclaw#67562

The users could add a manual task like - [high] Review recent notes and update MEMORY.md to HEARTBEAT.md, but that's just "ask the agent to think about it" — there's no structured gather→reflect→consolidate→prune pipeline, no scoring thresholds, and no safety boundary restricting writes to memory files only. openclaw/openclaw#67912

TL;DR: HEARTBEAT.md = right scheduler, but the consolidation engine itself needs to be built. The OpenClaw project has the most mature Dreaming implementation to date (three-phase: light sleep / deep sleep / REM) with extensive battle scars documented in their issue tracker — great reference for what works and what doesn't.

[singlerider]

@Svtter Can you open a PR for this? I'm not quite sold on the usefulness of this as a feature. Memory consolidation has not been necessary so far in my experience. We have some high-priority stability items I'm going through this sprint and I wouldn't be able to get to scoping this for quite some time.