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
bash
clawdbot config set agents.defaults.memorySearch.experimental.sessionMemory true
JSON
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:
- Durable knowledge is extracted
- Daily notes are written to today’s log
- Durable items are promoted to
MEMORY.md - 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– DecisionsPREF– PreferencesFACT– Durable factsPOLICY– Rules / invariants
Retrieval Strategy (how agents should recall)
- Use
memory_search(max ~6 results) - Pick the best 1–2 hits
- Use
memory_getwith line ranges - Inject the minimum text required
This keeps context small and precise.
Agent Playbook (rules for agents)
- Prefer disk over RAM
- Prefer
MEMORY.mdover 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