[Discussion] How should Dream diaries be surfaced to users? Lessons from OpenClaw diary UX

[CaralHsi]

Dream CE produces diary entries as human-readable traces of offline memory consolidation. OpenClaw already has a diary-like user experience, so we would like to discuss how Dream diaries should be surfaced in MemOS and agent workflows.

Current idea

A Dream diary is different from functional memory:

• Functional memory is used by the agent for future reasoning or recall.
• A diary is an explainability artifact that helps users understand what the system consolidated.

Currently, diary entries can be queried, but they are not necessarily surfaced proactively.

Design questions

• Should Dream diaries be shown to users at all?
• Should diaries be passive, only visible when queried?
• Should the agent proactively mention a diary entry in the next conversation?
• If proactive, when is it helpful rather than annoying?
• Should we add a surfaced status to avoid repeating the same diary?
• Should users be able to disable diary surfacing?
• Should diary entries be written in a raw technical style or a warmer “nightly journal” style?
• What can we learn from OpenClaw’s diary experience?
• Should diary UX be part of MemOS core, or handled by applications on top of MemOS?

Possible directions

• Passive diary API only.
• Proactive “I reflected on something from last time...” message.
• UI timeline of Dream diary entries.
• Configurable diary surfacing policy.
• App-specific diary rendering, with MemOS only storing structured entries.

Desired outcome

We hope to collect UX expectations and real use cases before implementing diary surfacing. The result may become follow-up issues around:

• human-friendly diary rewriting,
• surfaced status,
• diary API improvements,
• OpenClaw integration examples.

[MaiHHConnect]

💬 我也在做记忆系统相关的工作：CausaMem，可以来看看，说不定有能借鉴的地方 🙂