How to Make OpenClaw Memory Better
OpenClaw's default memory frustrates most people within a few days
OpenClaw's default memory frustrates most people within a few days. The agent felt sharp last session, then a new one starts and the context is gone. The good news: the file-based design that causes this is also what makes it tunable. You can make OpenClaw memory significantly more reliable — up to a point worth understanding.
Why is OpenClaw memory unreliable by default?
Because the agent decides what to remember, and models are inconsistent at it. OpenClaw stores memory as Markdown files, and saving is a choice the model makes — not an automatic process. Mention something important mid-session and it may never get written down.
On top of that, only today's and yesterday's daily notes auto-load, files truncate at 20,000 characters, and compaction can compress older context mid-session. The result: memory that works sometimes, and fails quietly the rest of the time.
(For the full architecture, see How Does OpenClaw Memory Work?.)
How do you improve OpenClaw's built-in memory?
Start with curation — it's free and fixes most problems.
Keep MEMORY.md lean and curated. Treat it as a maintained knowledge base, not an append-only log. Durable facts and decisions go here; everything else lives in daily notes and gets retrieved by search. A bloated MEMORY.md hits the 20,000-character truncation cap and silently loses its tail.
Put user context in the right files. USER.md and IDENTITY.md auto-load every session and are the correct home for who you are, your role, and your preferences. Critical knowledge in a custom-named file (notes.md, profile.md) never gets injected — only the eight bootstrap filenames load automatically.
Promote daily notes upward. The agent is meant to distill useful material from daily notes into MEMORY.md over time. A weekly cron job that promotes durable rules keeps long-term memory current without manual editing.
Should you enable semantic search?
Yes — it's the highest-value built-in upgrade. Semantic search lets the agent retrieve older notes by meaning, not just the auto-loaded two-day window.
Enable it via agents.defaults.memorySearch. (Config keys and flags like these change between OpenClaw versions — treat the names as illustrative and verify them against your installed version.) The agent gains memory_search and memory_get tools and can pull relevant context from your full history on demand.
One cost to know: semantic search uses an embedding provider (OpenAI by default, with Gemini, Voyage, Mistral, and local options available). That means API costs and a dependency on the provider being configured correctly — misconfigured embeddings are a common source of failures. Local embeddings avoid the cost and the external dependency.
What is dreaming and should you use it?
Dreaming is OpenClaw's background promotion of short-term recall into long-term memory. It runs on a schedule, ranks candidates from daily notes using signals like frequency and relevance, and promotes the strongest into MEMORY.md.
It's opt-in and disabled by default. Turn it on with /dreaming on. It's useful if you want long-term memory to maintain itself rather than relying on manual curation — but it adds background processing, and like everything else here, it still operates on the same file-based foundation.
When should you use external context instead?
Here's the limit no amount of tuning removes: OpenClaw is built to use context, not to gather it.
Your real context isn't in OpenClaw. It's in your Gmail, your Notion, your calendar, your GitHub. You can connect those to OpenClaw through MCP — but that creates two problems:
- OpenClaw isn't an extraction engine. It can read from connected sources, but it wasn't designed to pull structured context out of a dozen tools, cross-reference it, and keep it current. You're asking a gateway to do a job it wasn't built for.
- It costs. Every connected source, every retrieval, every embedding call adds latency and API spend. Wiring your whole digital life through OpenClaw to reconstruct who you are is expensive and brittle.
The alternative: extract your context once, from all your sources, into a structured layer — then deliver exactly the context needed to OpenClaw (or any other tool) through a single MCP connection. That's what a personal context layer like Unabyss does. Connect your sources to it, and it serves clean, current context to whatever agent needs it — without turning OpenClaw into a half-built extraction pipeline.
OpenClaw's job is to act on your behalf. Giving it accurate context to act with is a separate job, and a separate tool does it better.
→ How context delivery works: How to Deliver Personal Context to AI Tools
→ Set up your context vault with Unabyss →
