OpenClaw Memory Curator

A session-first memory system for OpenClaw.

It exists for one reason: important knowledge must survive session compaction without bloating the context window.

TL;DR (for humans)

• Session memory = temporary (RAM)
• Disk = source of truth
• Decisions & preferences → MEMORY.md
• Daily work → memory/YYYY-MM-DD.md
• This skill saves durable knowledge before compaction
• Retrieval always happens via memory_search → memory_get

If something matters later, write it to disk.

⚠️ CRITICAL REQUIREMENT

Session memory indexing must be enabled.

Enable Session Memory

CLI

clawdbot config set agents.defaults.memorySearch.experimental.sessionMemory true

JSON

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "experimental": { "sessionMemory": true },
        "sources": ["memory", "sessions"]
      }
    }
  }
}

Mental Model (read this once)

OpenClaw memory has three layers. Confusion usually comes from mixing them up.

1. Session Memory (RAM)

• Lives in the current conversation
• Automatically compacted
• Indexed for retrieval
• Never reliable long-term

👉 Treat as short-term thinking space.

2. Daily Logs (memory/YYYY-MM-DD.md)

• Append-only
• What happened today
• Commands, edits, short-lived issues

👉 Treat as a work log, not a knowledge base.

3. Long-Term Memory (MEMORY.md)

• Curated
• Small
• High-signal only
• Indexed and retrievable

👉 Treat as facts the agent must not forget.

When to Write Memory (simple rules)

Write to MEMORY.md if it would still be true next week.

Examples:

• Decisions
• Preferences
• Invariants
• Policies

Write to daily logs if it helps understand today.

Examples:

• Refactors
• Experiments
• Temporary blockers

If unsure: write to daily log first, promote later.

Pre-Compaction Flush (why this exists)

Before OpenClaw compacts the session, it triggers a silent reminder.

This skill uses that moment as a Save Game checkpoint.

What happens:

1. Durable knowledge is extracted
2. Daily notes are written to today’s log
3. Durable items are promoted to MEMORY.md
4. Agent replies NO_REPLY (user never sees this)

This prevents knowledge loss without interrupting you.

Durable Memory Format (MEMORY.md)

Use IDs and tags so search works reliably.

## DEC-2026-02-04-01
type: decision
area: memory

Decision:
Session memory is retrieval-only. Disk is the source of truth.

Reason:
Session compaction is lossy. Disk memory is stable.

ID prefixes

• DEC – Decisions
• PREF – Preferences
• FACT – Durable facts
• POLICY – Rules / invariants

Retrieval Strategy (how agents should recall)

1. Use memory_search (max ~6 results)
2. Pick the best 1–2 hits
3. Use memory_get with line ranges
4. Inject the minimum text required

This keeps context small and precise.

Agent Playbook (rules for agents)

• Prefer disk over RAM
• Prefer MEMORY.md over daily logs for facts
• Use search before asking the user again
• Never copy raw chat into memory
• Write memory explicitly, do not assume it sticks

Anti-Patterns (do not do these)

• ❌ Copy chat transcripts into memory
• ❌ Store secrets or credentials
• ❌ Treat daily logs as long-term memory
• ❌ Overwrite memory files instead of appending
• ❌ Store speculation as fact

Privacy Rules

• Never store secrets (API keys, tokens, passwords)
• Ignore anything inside <private>...</private>
• If sensitive info exists: store only that it exists, not the value

Retention & Cleanup

Default: no deletion

• Disk is cheap
• Recall quality is expensive

Optional:

• Move old daily logs to memory/archive/YYYY-MM/
• Only prune after durable knowledge is verified

Usage (human-friendly)

Examples that work well:

• “Store this as a durable decision.”
• “This is a preference, remember it.”
• “Write this to today’s log.”

Design Philosophy

• Disk is truth
• RAM is convenience
• Retrieval beats retention
• Fewer tokens > more tokens
• Memory should earn its place