Summary
Dreaming (Light → Deep → REM consolidation) is a powerful feature, but it is currently tightly coupled to memory-core. Users who run alternative memory plugins (e.g. memory-lancedb-pro) cannot use dreaming even when the plugin is otherwise feature-complete.
The problem
Dreaming depends on memory-core internal state formats:
short-term-recall.json- Daily memory files (
memory/YYYY-MM-DD.md)
phase-signals.json- Managed cron with hardcoded internal paths
None of these are exposed as a plugin protocol. A memory plugin cannot "opt in" to dreaming — it must either be memory-core or nothing.
Proposed solution
Expose dreaming as a memory plugin protocol consisting of:
- Config schema:
dreaming config block that any plugin can declare (e.g. enabled, frequency, model)
- Required capabilities: a set of interface methods the plugin must implement to participate in the dreaming lifecycle:
- Query recent memories (for light phase candidate collection)
- Promote candidates (for deep phase durable writes)
- Report state (for REFLECTION/REM phase)
- Dreaming runtime: OpenClaw manages the cron scheduling and phase orchestration; the plugin implements the storage backend
This mirrors the pattern where OpenClaw already supports pluggable memory backends — dreaming should be part of that contract.
Related
Benefit
Any memory plugin could implement the dreaming protocol, enabling:
- memory-lancedb-pro users to get automatic memory consolidation
- Future memory plugins to ship with dreaming support from day one
- Reduced maintenance burden on OpenClaw core (protocol vs. monolith)
Summary
Dreaming (Light → Deep → REM consolidation) is a powerful feature, but it is currently tightly coupled to
memory-core. Users who run alternative memory plugins (e.g.memory-lancedb-pro) cannot use dreaming even when the plugin is otherwise feature-complete.The problem
Dreaming depends on memory-core internal state formats:
short-term-recall.jsonmemory/YYYY-MM-DD.md)phase-signals.jsonNone of these are exposed as a plugin protocol. A memory plugin cannot "opt in" to dreaming — it must either be
memory-coreor nothing.Proposed solution
Expose dreaming as a memory plugin protocol consisting of:
dreamingconfig block that any plugin can declare (e.g.enabled,frequency,model)This mirrors the pattern where OpenClaw already supports pluggable memory backends — dreaming should be part of that contract.
Related
normalized recall artifactssilently deletes daily memory files (memory/YYYY-MM-DD.md) #84882//dreamingslash command and Dreams UI currently hardcode memory-core assumptionsBenefit
Any memory plugin could implement the dreaming protocol, enabling: