My OpenClaw Agent Was Getting Dumber — Here’s the Memory System That Fixed It

---

I run OpenClaw 24/7 as my entire business operations layer — 12 cron jobs, 5 browser profiles, automated content workflows, the works. Three weeks in, my agent started forgetting things, contradicting itself, and ignoring recent decisions.

It wasn’t broken. Its memory was bloated.

By day fourteen I had 28 memory files totaling nearly 2,000 lines. Every session loaded all of it, burning through context before I’d even asked a question. The agent was spending its intelligence parsing noise instead of doing work.

I’ve seen this pattern everywhere — Reddit threads with dozens of people trying Mem0, Obsidian plugins, custom SQLite solutions. Someone pruned their MEMORY.md from 25,000 characters to 6,200 and said their agent became “sharper and more reactive.”

The problem isn’t the tool. It’s that nobody teaches you how memory actually works under the hood.

The Four Layers Most People Don’t Know Exist

OpenClaw doesn’t have “a memory system.” It has four separate layers, and they fail in different ways.

Layer 1: Bootstrap files. SOUL.md, AGENTS.md, MEMORY.md, USER.md, TOOLS.md — loaded from disk at every session start. They survive compaction, session resets, everything. Your most durable layer.

Layer 2: Session transcript. Conversation history saved as JSONL. When the context window fills, this gets compacted into a lossy summary. Details, nuance, mid-conversation instructions — gone.

Layer 3: The context window. The fixed-size container where everything competes for space — system prompt, workspace files, conversation history, tool results. All in one 200K token bucket. When it fills, compaction fires.

Layer 4: The retrieval index. Semantic search over memory files via memory_search. Lets you keep files small while finding old context on demand. Only works if information was written to files first.

When your agent “forgets,” it’s always one of three things: the information was never written to a file (most common), compaction summarized it away, or session pruning trimmed a tool result.

An OpenClaw codebase maintainer put it best: if it’s not written to a file, it doesn’t exist.

What I Built (And What I Was Missing)

After reading VelvetShark’s memory masterclass (written by an actual OpenClaw codebase maintainer), the official OpenClaw permanent memory guide, and a deep dev.to guide on memorySearch, I rebuilt everything. Some of what I had was right. The gaps were worse than I expected.

The file architecture

Seven file types, under 500 lines total:

• Core memory (facts, procedures, lessons, knowledge) — updated in place. When something changes, the old line gets replaced. Nothing accumulates.
• Daily notes — one file per day, max 20 lines, auto-deleted after seven days. Recent context only.
• MEMORY.md — curated long-term narrative at the workspace root. Under 3,000 tokens. Relationships, key decisions, patterns. A bootstrap file, so it survives everything.
• Operational files — a reply log and a blocklist. Tiny, purpose-specific, bounded.

I’d originally killed MEMORY.md during my consolidation, thinking structured files covered everything. They didn’t. Narrative context — warm leads, the emotional arc of decisions, relationship history — had nowhere to live. The official OpenClaw guide confirmed this was a mistake.

The config layer (this is what most people miss)

Pre-compaction memory flush. A built-in OpenClaw feature most people don’t know exists. Before compaction fires, it triggers a silent turn reminding the agent to save important context to disk. Without it, your agent just loses whatever was in conversation when context overflows. I had the headroom configured but never enabled the flush itself. One config change, massive difference.

Context pruning. Old tool outputs (file reads, browser results, API responses) pile up in context and eat tokens. OpenClaw’s cache-ttl mode trims these per-request without touching your conversation history. Pruning reduces bloat; compaction destroys context. You want pruning doing the heavy lifting so compaction fires less often.

Semantic search. memory_search was enabled in my config but I’d never wired it into my procedures. This is the retrieval layer that makes small files viable — you don’t need everything in context if the agent can search for what it needs.

The maintenance stack

Nightly distillation (11 PM): reviews the day’s notes, promotes lasting context to permanent files, trims the daily note to essentials.

Weekly cleanup (Monday): enforces size limits, deletes expired daily notes, removes rogue files that cron jobs sometimes create.

Midnight failsafe: verifies the nightly process actually ran. If it didn’t, runs a full maintenance cycle. This has saved me twice.

Three layers means the system self-heals. I haven’t manually touched my memory files in over a week.

A Gotcha Nobody Talks About

While testing the retrieval layer, I found something that isn’t in any guide: memory_search with the local provider doesn’t auto-purge deleted files from its index.

I consolidated from 28 files to 7. The filesystem was clean. But search queries still returned results from files that no longer existed — ghost entries pointing to deleted content.

If you reorganize your memory files, your retrieval layer silently serves stale context. The agent thinks it found something relevant, but the source is gone. Rebuild the index after any major file cleanup.

The Results

My agent went from drowning in 2,000 lines of accumulated context to operating on ~400 focused lines with a pre-compaction safety net, automatic pruning, and on-demand retrieval. It references recent decisions accurately from the first message. The maintenance runs itself.

The agent isn’t smarter. It just has less garbage to think through.

Start Here

If you take one thing from this post: enable the pre-compaction memory flush. It’s the single highest-impact config change you can make, and most OpenClaw users don’t know it exists.

After that, keep MEMORY.md small and curated, use the retrieval layer instead of loading everything, and automate maintenance from day one.

You probably don’t need Mem0 or a vector database. OpenClaw already has a built-in retrieval layer, a pre-compaction flush, and a pruning system. Most people just never configure them.