Memory Management

[green echo]

Hi, how does OpenClaw manage memory? What makes it stick so that you'll always remember what we discuss about? I see a few people taking advantage of Obsidian for this purpose. Can you talk more in depth how this works? Thanks

[inland hatch]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[limpid elm]

OpenClaw doesn’t have “magical” persistent memory inside the model. The model only remembers what it’s given in the prompt each run, so what makes things “stick” is: OpenClaw writes memory to disk in your agent workspace (plain Markdown), then later reloads/searches it.

1) The source of truth: Markdown files in the workspace

OpenClaw’s memory is intentionally boring and inspectable:

• Daily log: memory/YYYY-MM-DD.md
  Append-only “what happened today”. By default the agent reads today + yesterday on session start.

• Curated long‑term memory: MEMORY.md (sometimes also memory.md depending on your template)
  This is where durable facts go: preferences, decisions, important context.

Docs: https://docs.openclaw.ai/concepts/memory
Workspace layout: https://docs.openclaw.ai/concepts/agent-workspace

Important privacy behavior (why it won’t leak your private stuff)

By default, curated long-term memory is intended to load only in the main private session, and not in shared/group contexts. That’s on purpose: you don’t want a bot pulling in personal notes while you’re talking in a public Discord channel.

2) Recall: how it finds relevant old info later

There are two main mechanisms:

• Bootstrap injection: some workspace files are automatically loaded into context (AGENTS/SOUL/USER/TOOLS/etc, plus MEMORY.md/memory.md when present).
• On-demand retrieval tools: the agent can call:
  • memory_search (semantic search over indexed snippets)
  • memory_get (read a specific file + line range)

memory_search typically uses embeddings (local or remote) to build a small derived index over MEMORY.md + memory/*.md, so it can find things even if you don’t remember the exact wording.

3) “Always remember what we discuss” — what you should do in practice

If you want something to persist across new sessions, the reliable move is to tell the agent explicitly to write it to memory (e.g. “remember this…”). Since it’s Markdown on disk, you can verify it actually got stored by opening the file.

OpenClaw also has an automatic pre-compaction “memory flush”: when a session is nearing compaction (context getting too big), it can trigger a silent internal turn prompting the agent to store durable notes before older context gets summarized/trimmed. That helps prevent “we talked about this earlier but it got compacted away.”

4) Where Obsidian fits in

Obsidian works well with OpenClaw because it’s all Markdown anyway. Common setups:

• Use an Obsidian vault as the workspace (or put the workspace inside your vault) so you can browse/edit MEMORY.md + daily logs in a nice UI.
• Keep workspace separate, but index your vault for recall by adding extra paths to memory search (so the agent can retrieve from your notes without making them part of the always-injected boot prompt).

The docs cover “additional memory paths” for indexing external Markdown (great for Obsidian vaults): https://docs.openclaw.ai/concepts/memory

5) Optional: “auto memory” plugins

Default is the core memory plugin (memory-core) which provides the memory tools + indexing over Markdown. There’s also a bundled memory-lancedb option that can do auto-capture / auto-recall (more automatic “long-term memory” behavior), but it’s opt-in via the memory plugin slot.

If you tell me how you want memory to behave (private-only vs allowed in groups, manual vs automatic capture, one vault vs multiple), I can suggest a clean setup pattern.

[glad nymph]

which embeddings does it OpenClaw use right now out of the box?

[limpid elm]

For the default memory plugin (memory-core), OpenClaw’s embeddings are basically “auto”:

• If you configured local embeddings (agents.defaults.memorySearch.local.modelPath exists), it’ll try local first.
• Otherwise it tries remote providers in this order based on which API key it can resolve:
  OpenAI → Gemini → Voyage → Mistral
• If it can’t find any embedding API key (and you didn’t set up local), it degrades to FTS-only (lexical search) — meaning no embeddings at all, but memory_search can still work.

Current default embedding models (if you don’t override agents.defaults.memorySearch.model) are:

• OpenAI: text-embedding-3-small
• Gemini: gemini-embedding-001
• Voyage: voyage-4-large
• Mistral: mistral-embed

To see what your install is actually using right now, run:

openclaw memory status --deep

Docs: https://docs.openclaw.ai/concepts/memory

[green echo]

Besides Markdown, does OpenClaw inherently support SQLite memory? Wondering how does memory fetch from Markdown vs SQLite compares with each other? Do you know what are the pros and cons of each? I'm talking about local query, not local Markdown fetch versus querying from remote sqlite database like Turso.

[limpid elm]

Yes — OpenClaw ships with a local SQLite-backed memory index out of the box, but it’s important to separate canonical memory vs search/index:

What’s “real” memory vs what’s SQLite?

• Source of truth (canonical memory): Markdown files in the workspace (MEMORY.md, memory/YYYY-MM-DD.md, etc.). That’s what “sticks” because it’s what persists on disk and is human-editable.
• SQLite (builtin): a derived local index that powers memory_search (FTS/BM25-style text search + optional vector search via sqlite-vec + embeddings). You can delete/rebuild it; it’s not intended to be the authoritative store.

By default, the SQLite index lives at:

• agents.defaults.memorySearch.store.path → default ~/.openclaw/memory/{agentId}.sqlite (per the config schema help text)

Docs: https://docs.openclaw.ai/concepts/memory

“Markdown fetch” vs “SQLite query” (local)

1) Markdown fetch (memory_get / plain file reads)

Pros

• Exact + deterministic (you see the literal text on disk)
• Human-auditable/editable (Obsidian/git-friendly)
• No embedding provider required

Cons

• Not a search engine: you need to know where to look, or you end up scanning lots of text (token-expensive / slower)
• Hard to do “find the most relevant 5 snippets about X” without an index

2) SQLite query (memory_search via the index)

Pros

• Fast local retrieval (good “recall” UX: “what did we decide about X?”)
• Can do lexical search even with no embeddings (FTS-only mode)
• With embeddings enabled, semantic matches work even if wording differs

Cons

• It’s an index: can be stale briefly (file watchers/debounce), and chunking can miss nuance
• Adds moving parts (embedding provider availability; sqlite-vec availability if vector search is enabled)
• Not meant for you to manually edit as “the memory” (you edit Markdown, then it reindexes)

Does OpenClaw “support SQLite memory” as the primary store?

Not in the sense of “store memories in SQLite instead of Markdown” as a first-class canonical workflow. The built-in design is: Markdown is truth; SQLite is the recall index.