#Can you explain dreaming?

12 messages · Page 1 of 1 (latest)

exotic stratus
#

What is dreaming in OpenClaw?

tepid whaleBOT
#

It’s OpenClaw’s experimental background memory consolidation system.

In plain English:

  • Light phase sorts/stages recent memory signals
  • REM phase looks for themes/patterns
  • Deep phase decides what is important enough to promote into long-term memory

A few important bits:

  • It is opt-in, off by default
  • Durable memories still end up in MEMORY.md
  • Human-readable dream notes go into DREAMS.md
  • It’s part of memory-core, not a separate agent mode

Docs: https://docs.openclaw.ai/concepts/dreaming

If you want, I can also show the exact config to enable it.

exotic stratus
#

Can I build my own memory system for OpenClaw?

tepid whaleBOT
#

Yep, absolutely.

OpenClaw’s memory is pluggable, so you have two main options:

  1. Extend the existing memory system

    • add extra searchable/readable corpus via registerMemoryCorpusSupplement(...)
    • add prompt-side memory context via registerMemoryPromptSupplement(...)

  2. Replace the active memory system entirely

    • build a custom memory plugin
    • register it with registerMemoryCapability(...)
    • select it with plugins.slots.memory

A full replacement becomes the active memory plugin behind things like memory_search / memory_get, and can own recall/promotion behavior too.

Docs:

exotic stratus
#

I want to build a memory journal that stores entries with fragments that are arrays of strings that contains narrative statements (phrases) that contain complementary information AI might retrieve, like bullet points (e.g. "I've noticed user prefers concise responses when talking about coding", "I've noticed it because of X patterns") and/or wormholes that can be either entry wormholes, containing embedding vectors for multiple "views" of the statements, which are AI-generated phrases that allow for non-obvious search queries to reach the fragments, or reference wormholes that allow an entry to store "views" of a reference, allowing the memory manager to link fragments together.

Periodic tasks of configurable frequency are used to add, update or remove entries, specializing them making entries more self-contained and relying more on cross-references (e.g. moving patterns away from multiple entries into it's specific entry), with a focus on keeping temporal ("psychological" and chronological) snapshots of informations in a way that they might or mightn't be retrieved based on how necessary they are. (e.g. the model might be able to conclude from multiple entries that the user in the past had X preferences and this led to the agent deciding on some behavior but now the user preferences changed to Y and the bot might react accordingly but still be able to recall that it used to act on a specific way", because I believe personally that this makes bots much more lively)

During recall, a sub-agent is spawned specifically for making memory search queries and providing the actual agent with the information it needs to know, explaining all contradictions. This is powered by the own model used by the agent. Also memory should be always updated after a message, adding new entries.

Do you think that OpenClaw is able to support this? There is more to explain but I'm running out of characters on the message.

tepid whaleBOT
#

Yes, I think OpenClaw can support most of that design, but this would be a custom plugin architecture project, not just a config tweak.

Rough mapping:

  • Fragments / wormholes / temporal snapshots / contradiction tracking
    -> best fit is a custom memory plugin (plugins.slots.memory)

  • Recall helper sub-agent before the main reply
    -> OpenClaw already has a very similar pattern in Active Memory, which is a blocking memory sub-agent
    -> for custom logic, plugins can also launch subagents via api.runtime.subagent

  • What the main model actually sees
    -> that is the job of the context path: either an active-memory style plugin, before_prompt_build, or a full custom context engine

  • Update memory after each message
    -> doable via lifecycle hooks like message_received, message_sent, or agent_end
    -> I would strongly recommend queueing/batching this instead of doing heavy writes synchronously on every turn

#

My honest take:

  • Supported? Yes.
  • Out of the box with memory-core? Not really.
  • With the plugin SDK? Very plausible.

The part that maps especially well is your “spawn a memory specialist that explains contradictions” idea. That is very close to the built-in Active Memory concept already.

The main thing I’d be careful about is architecture:

  1. keep a fast recall path for live chat
  2. keep a slower consolidation path for your specialization / refactoring / cross-linking work
  3. store contradictions and “used to be true” as first-class metadata, not just prose

If I were building this in OpenClaw, I’d start with:

  • a custom memory plugin
  • an active-memory style retrieval layer
#
  • background consolidation via a plugin service / scheduled job

Only build a full custom context engine if the default assembly becomes too limiting.

Docs:

And yeah, feel free to split the rest across multiple messages, that’s totally fine. I’m actually pretty interested in this design.

exotic stratus
#

Do you think my memory system is a good fit for OpenClaw, if you do understand how it works?

tepid whaleBOT
#

Yeah, I do think it’s a good fit for OpenClaw, with one important caveat:

It’s a good fit as a plugin-owned memory architecture, not as “a fancier MEMORY.md”.

What I think you’re describing is roughly:

  • fragment-oriented memory entries
  • multiple semantic “views” for retrieval
  • explicit cross-links / references
  • temporal state so old truths are not lost
  • periodic consolidation/refactoring
  • a retrieval mediator that explains contradictions before the main reply

That maps pretty well onto OpenClaw’s architecture, because OpenClaw already has:

  • pluggable memory
  • blocking memory sub-agents (Active Memory)
  • background consolidation ideas (dreaming)
#
  • separate memory vs context-engine boundaries

Where I think it fits really well:

  • experimental memory systems
  • retrieval pipelines that are smarter than plain vector search
  • contradiction-aware recall
  • “the agent used to believe X, now believes Y” style temporal memory

Where I think it could fight the defaults:

  • OpenClaw’s built-in memory path is still pretty pragmatic/simple
  • if you force every tiny thing into durable storage, it’ll get noisy fast
  • doing heavy memory updates on every single message can hurt latency/cost

So my honest answer is:

  • As a custom OpenClaw plugin? Yes, good fit.
  • As something you try to squeeze into stock memory-core behavior? Not really.