Clawdguy
OpenClaw playbook

OpenClaw memory that stays useful after week two

Memory is the difference between a one-off chat and a system that improves over time. The hard part is not “adding memory.” It is preventing memory drift, contradictions, and compaction-induced hallucinations.

TL;DR (the memory rules that prevent 80% of drift)

Treat memory as a system of record. If you cannot review it, you cannot trust it.

Most “OpenClaw forgot” complaints are really: memory was never committed to disk, memory was polluted with transient text, or compaction summarized away key constraints.

  • Store durable decisions and preferences, not raw conversations
  • Keep long-term memory small and curated (edit it like code)
  • Separate “daily log” from “stable rules”
  • Use a commit + verify loop whenever memory changes
  • When compaction happens, preserve the constraints explicitly

What to store (and what to keep out)

Good memory is boring. It is short, stable, and easy to apply. Bad memory is a pile of raw text that looks “thorough” and creates contradictions.

If you only store one category, store operating rules: what to do, what not to do, and when to ask for approval.

Memory is not a database

If something needs to be queried and updated frequently, move it to a structured file (like a table) and keep memory as the index and rules for using it.

  • Store: preferences, invariants, policies, stable facts, runbooks, definitions
  • Avoid: raw web dumps, full email threads, transient ideas, repeated summaries
  • Never store: secrets without an explicit retention policy

A simple memory structure that scales

You want two levels: curated memory (stable) and running memory (append-only). This prevents the most common failure mode: long-term memory turning into a chat transcript.

If multiple workflows share the same OpenClaw instance, keep memory scoped per workflow, or you will cross-contaminate decisions.

  • Curated memory: a single file for “what is true and stable”
  • Daily memory: one file per day with decisions and changes
  • Workflow memory: a short runbook per workflow (inputs, outputs, guardrails)

Workspace layout

workspace/
  MEMORY.md
  memory/
    2026-03-09.md
  runbooks/
    inbox-triage.md
    research-brief.md

Session memory search (fast recall inside long runs)

If your sessions are long, you often want “semantic recall” of what happened earlier in the same session without stuffing the entire transcript into the prompt.

OpenClaw supports an experimental session memory search mode that can query the session and memory sources. Treat this as a precision tool: great for recall, bad as a crutch for unbounded workflows.

  • Use it to find: decisions you already made, names, constraints, earlier outputs
  • Do not use it to justify endless loops (still add budgets and stop rules)
  • Prefer: store durable decisions to memory files; use session search for short-term recall

Enable experimental session memory search (verified keys)

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

Compaction: why it breaks memory (and how to make it safer)

Compaction is a necessary evil when context grows. The risk is that summarization drops constraints, changes meanings, or merges unrelated threads.

Your goal is not “avoid compaction.” Your goal is: make the constraints survive compaction.

Constraint survival test

If you can’t ask the agent to list the top 5 workflow rules and get the right answer after compaction, your memory is too implicit.

  • Before compaction: flush durable decisions to curated memory
  • During compaction: explicitly restate the non-negotiables
  • After compaction: run a verification prompt (“what rules are you following?”)
  • If a workflow is brittle: cap scope so it never needs extreme compaction

The commit + verify loop (make memory changes measurable)

The safest pattern is: write a small memory update, then immediately test that it changes behavior the way you intended.

This prevents “memory drift” where you keep adding more instructions and nothing gets better.

  • Commit: add one rule or preference, written as a clear sentence
  • Verify: ask for a short restatement of the rule plus an example
  • Enforce: require the agent to reference the rule when acting
  • Prune: delete rules that are unused or contradicted

Example memory rule (curated)

# Operating rules

- Never send external messages without approval.
- If browsing is used, cite sources and include publication dates.

Troubleshooting: when memory is “wrong”

When outputs regress, assume the system is doing the rational thing given its inputs. The job is to identify which layer is wrong: inputs, memory, tools, or constraints.

Use this flow before you swap models or rewrite everything.

  • Check: is the right memory file being loaded for this workflow?
  • Check: did compaction recently run and drop constraints?
  • Check: is memory duplicated in two places with contradictions?
  • Fix: prune curated memory to the smallest set of stable rules
  • Fix: move large reference content out of memory into dedicated files

How Clawdguy helps (memory is easier when the runtime is stable)

Memory design gets harder when your runtime is unstable. If the gateway is slow, resets often, or tools hang, you end up blaming memory for infrastructure failures.

Clawdguy gives you a stable OpenClaw runtime so memory improvements are easier to validate and measure.

  • Dedicated infrastructure, predictable performance
  • Managed lifecycle and recovery controls
  • A clean baseline for testing memory changes