OpenClaw 2026.4.7 shipped memory-wiki on April 8. Your agent can now build its own knowledge base. Here's what that means and why it matters more than any update since launch.
I asked my agent yesterday who manages our auth permissions. It checked the wiki, found the entry, and responded in under two seconds: "Alice manages the auth team. She handles all permission changes. Last updated three days ago."
Two weeks ago, the same question would have triggered a semantic search across hundreds of memory chunks, returned six vaguely related results, and the agent would have guessed based on partial matches. Sometimes it got Alice right. Sometimes it didn't.
The difference is memory-wiki, the biggest feature in OpenClaw's April 8 release (version 2026.4.7). And it changes how persistent knowledge works for every agent running on the framework.
What memory-wiki actually is (in plain English)
OpenClaw's memory system has always had two layers. The session context (the active conversation buffer that resets when you use /new) and the persistent memory (MEMORY.md and daily log files that survive between sessions).
Memory-wiki adds a third layer: a structured, durable knowledge base that the agent can read, write, update, and search across sessions. Think of it as the agent building its own internal wiki, organized with claims, evidence, and provenance.
The key difference from MEMORY.md: memory-wiki entries are structured. They're not just text notes. They have claims (factual statements the agent believes), evidence (where the claim came from), timestamps (when it was learned or updated), and health status (whether the claim is fresh or potentially stale).
When your agent writes "Alice manages the auth team" to memory-wiki, it stores not just the fact but when it learned this, from which conversation, and how confident it is. When you ask about auth permissions weeks later, the wiki search returns the structured claim with its provenance, not a random text chunk that might or might not contain the answer.
Memory-wiki is a knowledge base, not a notebook. MEMORY.md is raw notes. Memory-wiki is structured facts with sources, timestamps, and health tracking. Your agent knows what it knows and when it learned it.
How memory-wiki fits alongside the existing memory system
This is where most people get confused. Memory-wiki doesn't replace MEMORY.md. It doesn't replace daily logs. It doesn't replace the session context. It adds a layer on top.
Here's how the three layers work together:
Session context handles the current conversation. It's the active buffer of messages that gets sent with every API request. It's managed by LCM (compaction) and resets when you use /new.
MEMORY.md and daily logs handle raw persistent notes. The agent writes facts it wants to remember. Memory search retrieves them using hybrid keyword plus vector search. This is the layer that's been available since OpenClaw launched.
Memory-wiki handles structured persistent knowledge. The agent compiles important facts from conversations and memory files into wiki-style entries with claims, evidence, and provenance. Wiki tools (wiki_search, wiki_get, wiki_apply, wiki_lint) let the agent query and maintain this knowledge base.
The active memory plugin still owns recall, promotion, and the new "dreaming" consolidation process. Memory-wiki adds a provenance-rich knowledge layer beside it.
For the complete overview of how OpenClaw's memory architecture works, our memory guide covers the session context and compaction layers that memory-wiki builds on top of.
What memory-wiki can do that raw notes can't
Here's what nobody tells you about the difference between notes and structured knowledge.
Claim-level search instead of chunk-level search
When you search MEMORY.md, the system splits your notes into ~400-token chunks and returns the most similar chunks. If the answer spans two chunks or the wording doesn't match, you might get irrelevant results. Community benchmarks show default SQLite search hitting roughly 45% recall accuracy on complex queries.
When you search memory-wiki, the system returns structured claims. "Alice manages the auth team" is a single claim with a single source. The search finds the claim directly, not a chunk that might contain it. Structured knowledge is inherently more precise than full-text search over raw notes.
Freshness tracking and staleness detection
Memory-wiki tracks when each claim was created and last confirmed. Over time, facts go stale. Alice might move to a different team. Your API key might expire. A project deadline might change.
The wiki_lint tool checks claims for staleness and flags entries that haven't been confirmed recently. This means your agent can tell you "Alice manages the auth team, but this hasn't been confirmed in 30 days" instead of confidently stating a potentially outdated fact.
Contradiction detection
If two wiki entries contradict each other ("project deadline is March 15" and "project deadline is April 1"), the system can identify and flag the contradiction. Raw MEMORY.md notes have no way to detect that two entries conflict. Memory-wiki's structured format makes contradiction clustering possible.
How to set up memory-wiki (self-hosted)
Memory-wiki shipped as a bundled plugin in OpenClaw 2026.4.7. If you're running an earlier version, update first. For the safe update process including backup and rollback, our update guide covers how to upgrade without breaking your setup.
Once you're on 2026.4.7 or newer, enable the memory-wiki plugin in your OpenClaw config. The plugin adds wiki tools to your agent's tool surface: wiki_search (find claims by topic), wiki_get (read a specific wiki page), wiki_apply (write or update a claim), and wiki_lint (check claims for staleness and contradictions).
The practical setup tip: Teach your agent to check the wiki before answering recurring questions. Add a line to your SOUL.md like "For questions about people, projects, or policies, check the wiki first before answering from general knowledge." This ensures the agent uses the structured knowledge base instead of guessing from session context.
For ongoing maintenance, run wiki_lint periodically (or set it as a cron job) to flag stale claims. The agent can then confirm, update, or remove outdated entries. This keeps the knowledge base accurate over time instead of accumulating facts that quietly become wrong.
What to store in memory-wiki (and what to leave in MEMORY.md)
Not everything belongs in memory-wiki. Here's the practical split.
Put in memory-wiki: Facts about people (who manages what, who prefers what communication style). Project details (deadlines, tech stacks, current status). Business policies (return windows, pricing tiers, escalation procedures). Recurring reference information that the agent needs to look up accurately and frequently.
Leave in MEMORY.md and daily logs: Personal preferences that don't need provenance tracking. Quick notes from individual conversations. Temporary context that's relevant now but not permanently. Anything that's more "note to self" than "durable fact."
The rule of thumb: if getting this wrong would cause a problem (wrong deadline, wrong policy, wrong person), put it in memory-wiki where it has provenance and freshness tracking. If it's helpful but not critical ("user prefers dark mode"), MEMORY.md is fine.
If managing memory plugins, wiki configuration, and staleness maintenance feels like more infrastructure work than you want, Better Claw includes persistent memory with hybrid search built into the platform. $29/month per agent, BYOK with 28+ providers. Memory-wiki support lands with OpenClaw updates as they ship. The memory layer is managed alongside everything else.
Memory-wiki plus Dreaming: the compound effect
Here's where it gets interesting.
OpenClaw 2026.4.9 (released April 9, one day after memory-wiki) added "Dreaming," a three-phase background memory consolidation system. Dreaming automatically processes short-term signals, scores candidates, and promotes qualified items into MEMORY.md.
When memory-wiki and Dreaming work together, the consolidation pipeline can feed structured claims into the wiki alongside raw MEMORY.md entries. The agent's knowledge doesn't just accumulate. It gets organized, verified, and maintained automatically.
This is the direction OpenClaw's memory architecture is heading: from "the agent writes notes" to "the agent builds and maintains a knowledge base." Memory-wiki is the foundation. Dreaming is the process that keeps it current. The combination means your agent gets smarter over time instead of just accumulating more text.
For the broader comparison of memory plugins and how they complement memory-wiki, our plugins guide covers the memory stack including QMD, Mem0, Cognee, and now memory-wiki.
Why this matters beyond the technical details
Here's the honest takeaway.
OpenClaw has always been impressive at doing things. Web searches, file operations, calendar management, code execution. The action layer is strong. The memory layer has been the weak spot. Agents that forget what you told them yesterday. Agents that can't connect related facts. Agents that confidently state outdated information.
Memory-wiki is the first time OpenClaw's memory system moved from "store and search text" to "maintain structured knowledge." It's the difference between an assistant with a pile of sticky notes and an assistant with a well-organized reference manual.
The feature is new (five days old as of this writing). It will evolve. The Dreaming integration is just starting. The QMD and bridge-mode hybrid recipes are being documented. The Obsidian-friendly workflows are emerging. This is the beginning of something that will define how OpenClaw agents work six months from now.
If you're running OpenClaw, update to 2026.4.7 and enable memory-wiki. If you're evaluating OpenClaw, this is the feature that addresses the biggest complaint the community has had since launch.
If you want memory-wiki managed alongside your entire OpenClaw deployment, give Better Claw a try. $29/month per agent, BYOK with 28+ providers. Updates land automatically. Memory persistence is built in. Your agent builds its knowledge base while you focus on what the knowledge is about, not how it's stored.
Frequently Asked Questions
What is OpenClaw memory-wiki?
Memory-wiki is a structured, persistent knowledge base that OpenClaw agents can read, write, and search across sessions. Introduced in version 2026.4.7 (April 8, 2026), it adds a third memory layer alongside session context and MEMORY.md. Unlike raw notes, memory-wiki entries have structured claims with evidence, sources, timestamps, and staleness tracking. The agent knows what it knows and when it learned it.
How does memory-wiki differ from MEMORY.md?
MEMORY.md stores raw text notes. Memory-wiki stores structured claims with provenance (source conversation, timestamp, confidence level, freshness status). Memory-wiki supports claim-level search (more precise than chunk-based search), staleness detection (flags outdated facts), and contradiction clustering (identifies conflicting claims). MEMORY.md is for quick notes. Memory-wiki is for durable facts that need accuracy tracking.
How do I enable memory-wiki in OpenClaw?
Update to OpenClaw 2026.4.7 or newer. Memory-wiki ships as a bundled plugin. Enable it in your config file. The plugin adds wiki tools to your agent (wiki_search, wiki_get, wiki_apply, wiki_lint). Add a SOUL.md instruction to check the wiki before answering recurring questions. Run wiki_lint periodically to flag stale or contradictory claims. The whole setup takes about 10 minutes after updating.
Does memory-wiki cost extra?
The plugin itself is free and bundled with OpenClaw 2026.4.7+. Wiki operations use your existing model provider for search and claim processing, so they add marginal API costs (comparable to regular memory search). On managed platforms like BetterClaw ($29/month per agent), memory-wiki support is included as part of the OpenClaw version updates that ship automatically.
Does memory-wiki work with other memory plugins like QMD and Mem0?
Yes. Memory-wiki doesn't replace the active memory plugin. QMD can still handle hybrid search across raw memory files. Mem0 can still handle automatic fact extraction from conversations. Memory-wiki adds structured knowledge alongside these systems. The recommended stack for power users: QMD for text retrieval, memory-wiki for structured claims, and optionally Mem0 for automatic capture. They complement each other because they operate on different layers.
Related Reading
- OpenClaw Memory Plugins Compared — How memory-wiki fits alongside QMD, Mem0, and Cognee
- OpenClaw Memory Compaction Explained — The session context layer that memory-wiki builds on top of
- OpenClaw Memory Fix Guide — Other memory issues memory-wiki doesn't solve
- How to Update OpenClaw Without Breaking Your Setup — Safely upgrade to 2026.4.7 to enable memory-wiki
- The OpenClaw SOUL.md Guide — How to instruct your agent to use memory-wiki effectively
