Cross-conversation Memory

In a nutshell: MyClaws stores long-term memory under three owner scopes (user / claw / project) and navigates retrieval via a clue tree. A background dream service periodically governs and deduplicates.

Why you need cross-conversation memory

• Open new conversations in the same project without re-explaining the context each time.
• Inherit user preferences across devices and Claws.
• Have the Agent proactively record important decisions, constraints, and external resources.

Writing and reading back a single memory item

1. In any conversation, ask the Agent to call memory_write to record facts worth keeping.
2. The next time you open a new conversation, the Agent sees an owner / clue tree index overview (≤ 5k tokens) before executing.
3. The Agent navigates to specific clues / items / full-text search via memory_recall.

Four memory types

• user: user profile (your role, preferences, knowledge background)
• feedback: behavioral corrections / confirmations ("don't do this again", "this approach is correct")
• project: project background facts (architecture, constraints, decisions, history)
• reference: pointers to external information (links, documents, issue numbers)

Three owner scopes

• user_global: shared across all Claws and projects for the user.
• claw_{clawId}: scoped to a single Claw.
• project_{projectSlug}: scoped to a single project.

Built-in memory tools

• memory_recall(): returns the clue tree overview by default.
• memory_recall({ clue }): navigate into a specific clue to view its members.
• memory_recall({ item }): read the full text of a single item.
• memory_recall({ query }): full-text search (supports CJK trigram).
• memory_write({ type, scope, content }): write a new memory entry.
• memory_update({ id, content }): overwrite an existing item.

Automatic sedimentation and _raw material

When a session is silent for 30 minutes or auto-compaction triggers, new content is sedimented into _raw/ as raw material, which the Admin dream service then organizes into formal memory. No manual /new or reset is needed to trigger sedimentation.

Dream governance service

Triggered by cron or threshold in the background:

1. Item-level governance: deduplication, merging, correction, and retirement.
2. Clue-level governance: weaves clue relationships, maintains members, consumes user-provided seeds.

Every dream run produces a log, viewable in the Bernard analysis snapshot.

Memory Management tab (Client / Bernard)

The desktop settings page provides a Memory Management entry:

• Browse the clue tree and formal memory.
• Browse _raw raw material.
• Run read-only memory_recall queries for debugging.

Data is strictly isolated by JWT userId via the Admin user-level REST API.

Pitfalls to avoid when writing memory

Related

• Agent Configuration
• Subagent Orchestration
• Desktop Power