OpenClaw Memory: How the System Remembers

OpenClaw’s memory layer is the difference between a forgetful agent and one that wakes up ready to work. This post walks through how OpenClaw structures long-term knowledge so every agent—human or autonomous—can recall orchestrator details, blog workflows, and personal preferences without digging through old chats.

Fast Summary

• Primary keyword: OpenClaw memory
• Audience: OpenClaw operators and agent developers who need reliable recall
• Stack: Markdown notes backed by main.sqlite for vector + FTS lookup
• Core idea: Write in Markdown, index via SQLite, promote important context to MEMORY.md

Why OpenClaw Memory Matters

OpenClaw agents boot fresh each session, so they need a reliable source of truth. Instead of relying on fragile chat logs, Jessie keeps:

1. Markdown files describing systems and workflows.
2. A SQLite index (main.sqlite) that chunks and embeds those files.
3. A clear promotion path from daily notes → long-term memory.

This approach lets agents answer “How do we manage tmux orchestrator sessions?” or “Where does the Hexo blog live?” without pinging Jessie.

Memory Layers at a Glance

Layer	Path	Purpose	Update cadence
MEMORY.md	~/.openclaw/workspace/MEMORY.md	Curated long-term facts (orchestrator structure, init project playbook, blog workflow).	Update when something becomes canonical.
Daily logs	~/.openclaw/workspace/memory/YYYY-MM-DD.md	Raw observations, decisions, to-dos.	Append throughout the day.
SQLite index	~/.openclaw/memory/main.sqlite	Search + embeddings over every Markdown source.	Auto-regenerated as files change.

Markdown Sources

• Markdown drives everything. Each file is a source of embeddings and searchable text.
• Posts like this one (under source/_posts/) document public-facing context.
• Internal references (Obsidian vault, templates, workflows) also live as Markdown so agents can ingest them safely.

Daily Memory Files (memory/YYYY-MM-DD.md)

• Location: ~/.openclaw/workspace/memory/
• Use case: Capture stream-of-consciousness notes, meeting logs, observations.
• Promotion rule: When a note becomes system knowledge, summarize it into MEMORY.md.
• Tip: Keep timestamps or bullet prefixes ([task], [decision]) to make promotion easier.

MEMORY.md (Long-Term Recall)

• Location: ~/.openclaw/workspace/MEMORY.md
• Purpose: Give every agent a compact briefing—Orchestrator Structure, init_project steps, Hexo blog workflow, etc.
• Guidelines:
  • Keep entries concise and evergreen.
  • Prefer headings + bullet lists for quick parsing.
  • Link to deeper Markdown docs when needed (Obsidian vault, repo READMEs).

memory/main.sqlite Index

• Path: ~/.openclaw/memory/main.sqlite
• Tables of interest:
  • chunks: stores text slices (≈400 tokens with ~80-token overlap) plus embeddings.
  • chunks_fts*: SQLite FTS tables for keyword search.
  • embedding_cache: avoids recomputing embeddings when files only change slightly.
  • files: maps chunk IDs back to absolute paths.
  • meta: schema + version info.
• Rebuild logic: Delete the DB and OpenClaw will re-chunk every Markdown file automatically; it just takes time proportional to file count.

Workflow Example: Documenting the Hexo Blog

1. Update memory/2026-03-03.md with the day’s work (reviving Hexo scaffolding).
2. Once the workflow stabilizes, summarize the commands in MEMORY.md under “Personal Blog (Hexo Workflow).”
3. Agents now know:
   • Path: Jarxi.github.io
   • Commands: npx hexo clean, npx hexo generate, npx hexo deploy
   • Where posts live: source/_posts/

Maintenance Best Practices

• Back up Markdown first. The DB is ephemeral; Markdown is canonical.
• Use Obsidian for human review. Jessie mirrors key docs into /Users/caoxinyi/Obsidian so both humans and agents stay aligned.
• Automate promotions. Periodically review daily logs, highlight decisions, and move them into MEMORY.md so they survive.

Conclusion

OpenClaw memory is simple on purpose: Markdown for clarity, SQLite for recall, and disciplined promotion rules. Maintain that rhythm and your agents boot with the same context Jessie has—ready to spin up tmux orchestrators, deploy Hexo, or revisit any historical decision without missing a beat.

---

• ← Previous Post
• Next Post →