OpenClaw Memory Wiki: What It Is and Why Your Agent Just Got Smarter

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 how to enable it.

Quick answer: OpenClaw memory-wiki is a structured, persistent knowledge base introduced in version 2026.4.7. Unlike MEMORY.md (raw text notes), memory-wiki stores claims with evidence, timestamps, and freshness tracking. Agents search, write, and maintain wiki entries across sessions using five wiki tools (wiki_status, wiki_search, wiki_get, wiki_apply, wiki_lint).

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. Five wiki tools (wiki_status, 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.

MEMORY.md vs memory-wiki at a glance

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.

The minimal config

Once you're on 2026.4.7 or newer, enable the plugin under plugins.entries.memory-wiki in your OpenClaw config (JSON5 syntax is supported, so unquoted keys are fine):

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "managed",
          vault: {
            renderMode: "obsidian",   // set to "plain" to skip Obsidian formatting
          },
          search: {
            backend: "auto",
            corpus: "all",
          },
        },
      },
    },
  },
}

The default wiki vault lives at ~/.openclaw/wiki/main/ with subdirectories for entities/, concepts/, syntheses/, sources/, and reports/. Setting vault.renderMode: "obsidian" generates Obsidian-compatible Markdown so you can point Obsidian at the vault folder and browse the agent's knowledge base in a graph view — this is core 4.7 functionality, not a separate feature.

The five wiki tools

The plugin adds these tools to your agent:

• wiki_status — reports vault mode, plugin health, and Obsidian-CLI availability. No params.
• wiki_search — finds claims by topic. Supports mode (auto, find-person, route-question, source-evidence, raw-claim) and corpus (wiki, memory, all).
• wiki_get — reads a specific wiki page by ID or path; falls back to the shared memory corpus.
• wiki_apply — narrow synthesis or metadata mutations on existing claims. Not for freeform page rewrites.
• wiki_lint — structural and provenance validation. Flags stale claims and contradictions. No params.

What a wiki page actually looks like

Memory-wiki pages are Markdown with structured YAML frontmatter. A typical person-entity page:

---
pageType: entity
entityType: person
id: alice-chen
canonicalId: alice-chen
aliases: [Alice, A. Chen]
privacyTier: team
lastRefreshedAt: 2026-05-12T14:23:00Z
bestUsedFor: [auth-permissions, security-reviews]
personCard:
  emails: [alice@example.com]
  timezone: America/Los_Angeles
  askForHints: [permission changes, SSO config]
claims:
  - id: c1
    text: Alice manages the auth team.
    status: active
    confidence: 0.92
    evidence:
      - source: chat:2026-05-08-standup
        kind: stated
  - id: c2
    text: Alice handles all permission changes for prod.
    status: active
    confidence: 0.88
    evidence:
      - source: doc:auth-runbook
        kind: written
relationships:
  - targetId: auth-team
    kind: manages
    confidence: 0.95
    evidenceKind: stated
---

The claims[] array is what makes wiki search precise: each statement has its own ID, confidence score, and evidence trail. relationships[] lets the agent traverse the graph (who reports to whom, which project owns which service).

Practical setup tips

Tell the agent to check the wiki first. Add a line to your SOUL.md like "For questions about people, projects, or policies, check the wiki before answering from general knowledge." This ensures the agent uses the structured knowledge base instead of guessing from session context.

Run wiki_lint regularly. Schedule it as a cron job to flag stale claims. The agent can then confirm, update, or remove outdated entries — keeping the knowledge base accurate instead of accumulating quietly-wrong facts.

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. $19/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.

Dreaming shipped in OpenClaw 2026.4.5 (April 6, 2026), two days before memory-wiki, as a three-phase background memory consolidation system integrated into the memory-core plugin. The three phases:

• Light — sort and stage recent short-term material. No permanent writes.
• Deep — score and promote durable candidates to MEMORY.md. This is the phase that actually writes.
• REM — reflect on themes and recurring ideas; surfaces patterns without permanent writes.

The Deep-phase ranking uses six weighted signals: Relevance (0.30), Frequency (0.24), Query diversity (0.15), Recency (0.15), Consolidation (0.10), and Conceptual richness (0.06). Tuning these — or watching what Dreaming chooses to promote — is what separates a wiki that grows accurate from one that grows noisy.

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. Memory-wiki is the foundation. Dreaming is the process that keeps it current.

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.

What's new since launch (4.9–4.12)

Memory-wiki has evolved across the four releases since 4.7:

• 2026.4.9 added Dreaming enhancements that work directly with the wiki: a grounded REM-backfill lane (memory rem-backfill --path <dir>), diary commit/reset flows, a structured diary view in the Control UI with timeline navigation, and live short-term promotion integration.
• 2026.4.11 introduced Memory Palace and Imported Insights as diary subtabs in the Control UI. Both let Dreaming inspect compiled wiki pages and imported chats (ChatGPT export ingestion landed in the same release) directly from the interface.
• 2026.4.12 preserved Unicode letters, digits, and combining marks in wiki slugs (capping segments to safe byte lengths), and shipped documentation for the recommended QMD + bridge-mode hybrid recipe plus a zero-artifact troubleshooting guide for memory-wiki bridge setups.

If you're upgrading from 4.7 directly to 4.12, the slug change is the only one that can affect existing pages — non-ASCII filenames generated under earlier versions will be re-canonicalized.

Why this matters

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 action layer (web search, file ops, code execution) has always been OpenClaw's strength; the memory layer was the weak spot, and structured claims with provenance close that gap.

If you're running OpenClaw, update to 2026.4.7 (or newer) 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. $19/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 introduced in OpenClaw 2026.4.7 (April 8, 2026). Unlike MEMORY.md (raw text notes), it stores claims with evidence, timestamps, and freshness tracking. Agents search, write, and maintain wiki entries across sessions using tools like wiki_search and wiki_apply.

How does memory-wiki differ from MEMORY.md?

MEMORY.md stores raw text notes; memory-wiki stores structured claims with provenance (source, timestamp, confidence, freshness). Memory-wiki supports claim-level search, staleness detection, and contradiction clustering. MEMORY.md is for quick notes. Memory-wiki is for durable facts that need accuracy tracking over time.

What's the difference between Dreaming and memory-wiki?

They solve different problems. Memory-wiki is the storage layer — a structured knowledge base of claims. Dreaming is the consolidation process that scores short-term signals and promotes qualified items into MEMORY.md (and optionally into the wiki). Memory-wiki holds the knowledge; Dreaming decides what becomes long-term memory.

How do I enable memory-wiki in OpenClaw?

Update to OpenClaw 2026.4.7 or newer, then enable the bundled memory-wiki plugin in your config and restart the gateway. The plugin adds wiki_search, wiki_get, wiki_apply, and wiki_lint to your agent. Add a SOUL.md instruction telling the agent to check the wiki before answering recurring questions.

Does memory-wiki cost extra?

The plugin is free and bundled with OpenClaw 2026.4.7+. Wiki operations use your existing model provider, so they add marginal API costs comparable to regular memory search. On managed platforms like BetterClaw ($19/month per agent), memory-wiki support ships automatically with the OpenClaw version updates.

Does memory-wiki work with other memory plugins like QMD and Mem0?

Yes. Memory-wiki doesn't replace the active memory plugin. QMD still handles hybrid search across raw memory files. Mem0 still handles automatic fact extraction. Memory-wiki adds structured knowledge alongside them. Recommended power-user stack: QMD for retrieval, memory-wiki for structured claims, optionally Mem0 for automatic capture.

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