Knowledge

knowledge is a bundled plugin that gives each agent an evidence-backed knowledge vault. Agents save pages, claims, and typed relationships as Markdown files with retained source evidence. The Control UI has a read-only explorer for them. Knowledge is also a memory provider: when it owns the memory slot, the agent's memory prompt, recall, and pre-compaction flush use the vault.

Knowledge ships with OpenClaw but stays off until you select it as the memory provider.

How it relates to other memory plugins

Knowledge is a kind: "memory" plugin. Only one plugin owns plugins.slots.memory at a time, so selecting Knowledge replaces memory-core (or another memory plugin) as the active memory provider.

Knowledge does not use embeddings. Retrieval is keyword (SQLite FTS5) plus exact identity lookup and structured date queries. Selecting Knowledge does not migrate, change, or delete memory-core data. Switching back leaves the vault intact.

Enable Knowledge

Select Knowledge for the memory slot:

{  plugins: {    slots: {      memory: "knowledge",    },  },}

Selecting the memory slot is enough. A bundled memory plugin selected by plugins.slots.memory is enabled even without a plugins.entries.knowledge entry, and even when plugins.allow does not list it. It stays off if plugins are globally disabled, if knowledge is in plugins.deny, or if plugins.entries.knowledge.enabled is false. When the slot points elsewhere, the memory-slot gate keeps Knowledge disabled.

Slot changes reload the plugin runtime without a Gateway restart. Verify the runtime registration and the live service:

openclaw plugins inspect knowledge --runtime --jsonopenclaw gateway call plugins.sessionAction --params '{"pluginId":"knowledge","actionId":"status","payload":{}}' --json

Open Knowledge in the Control UI sidebar. Native UI from enabled bundled plugins does not need the Custom plugin UI Labs setting. The knowledge_* tools appear after the tool catalog refreshes.

See Apply changes and inspect and Hot reload.

Configuration

All settings live under plugins.entries.knowledge.config. Every key is optional.

{  plugins: {    slots: {      memory: "knowledge",    },    entries: {      knowledge: {        config: {          operatorRead: true,          writesEnabled: true,          stores: {            personal: { label: "Personal", agents: ["main", "research"] },          },          maintenance: {            enabled: true,            schedule: "30 3 * * *",            timezone: "America/Los_Angeles",          },        },      },    },  },}

operatorRead and writesEnabled are plugin-wide gates. Changes to plugins.entries.knowledge.config.stores do not reload the plugin; Knowledge applies membership changes in place.

Stores and agent membership

Every agent has an effective knowledge store. By default each agent gets its own isolated store. A named entry under stores assigns several agents to one shared store. An agent can belong to at most one named store; an agent listed twice is unavailable until the duplicate is removed, and is never resolved by first match.

• Stores are created lazily on an agent's first authorized use. Inspecting a store in the Control UI never creates it.
• Tools take no store, agent, path, or scope argument. The store comes from the calling agent's host-resolved memory audience on every call.
• Removing a named store from configuration does not delete its data. The store stays in the inventory as unassigned.
• Shared stores record which agent published each revision, so authorship survives sharing.

Inside each store, owner-direct turns read and write the store's private partition. Group and other conversation turns are confined to their own conversation partition. Operators can manage membership from Settings → Stores & sharing in the Knowledge page (requires operator.admin).

See Stores and access for the storage layout, authority table, and limits.

Where Knowledge keeps data

Knowledge keeps all state under the Gateway state directory (~/.openclaw by default, or $OPENCLAW_STATE_DIR):

<state dir>/knowledge/  registry.sqlite       # store identities, agent bindings, maintenance schedule  registry.id           # registry sentinel  stores/<vaultId>/    state.sqlite        # journal, history, search index, Git queue    vault/              # Markdown records, retained evidence, local .git

The location does not depend on how the plugin was installed. Back up the registry, each store's state.sqlite, and its vault/ directory together. A Markdown-only or Git-only copy is not a complete backup.

Writes and authority

• Agents publish through journaled operations with revision/hash preconditions and exact-retry semantics. A published receipt means files were written.
• Claims and relationships require retained, hash-verified evidence. Pages may omit it.
• Saved records are immediately available. There is no approval or acceptance step.
• Corrections, withdrawals, and identity merges are explicit agent operations that preserve history. See Corrections and merges.
• The Control UI is read-only. It hands change requests to chat instead of editing records.
• Operators cannot save knowledge through operator read access. Changing store assignments needs operator.admin.

Tools

Knowledge registers 35 knowledge_* agent tools. Each tool acts only on the caller's authorized store and partition.

See Tools for inputs, limits, and pagination.

Bundled skills

Knowledge ships nine skills. They are agent workflows over the tools above, not an autonomous ingestion engine.

See Ingestion workflows.

Control UI

The Knowledge page has Recent and Browse views, keyword Search, entity pages with linked claims and evidence, typed connections, retained originals, and file history. Settings holds Stores & sharing, Vocabulary, Vault status, and Maintenance. A Knowledge chat side panel lists the records an agent found, read, or changed in the current conversation.

See Control UI.

Local Git history

When writes are enabled and the git executable is available, Knowledge keeps a local Git repository inside each store's vault. It commits each publication with its retained evidence and checkpoints observed external edits. No remote, GitHub account, or opt-in is needed. A failed Git step never undoes a saved record.

See Local history.

Scheduled maintenance

A daily pass (03:30 Gateway host time by default) links claims that knowledge_remember saved without a subject to the one entity page they name. It never calls a model or creates pages. It runs only while writesEnabled is true. It uses the plugin service scheduler, not OpenClaw automations.

See Maintenance.

Capabilities and limits

Knowledge does not replace workspace bootstrap files, dreaming, standing intents, memory-core tools and CLI, or the file-oriented Memory UI.

Moving from a linked or path install

Earlier releases shipped Knowledge as a separate package installed with openclaw plugins install or loaded from a checkout. That copy can still take precedence over the bundled one:

• A path in plugins.load.paths always wins over a bundled plugin. openclaw plugins install --link adds such a path and also creates an install record.
• A tracked global install from openclaw plugins install wins over a packaged bundled copy. A bundled copy compiled inside a source checkout wins over a tracked install.

If Knowledge is only listed in plugins.load.paths with no install record, remove that path. The slot and plugins.entries.knowledge settings stay as they are.

If Knowledge has an install record, uninstalling it also clears its settings. openclaw plugins uninstall removes plugins.entries.knowledge.config, resets plugins.slots.memory to memory-core, and leaves an plugins.entries.knowledge.enabled: false marker that also blocks the bundled copy. Restore those settings afterwards:

1. Copy your plugins.entries.knowledge.config (including stores) somewhere safe.

2. Preview and run the uninstall. It also removes a linked install's plugins.load.paths entry, but does not delete the linked checkout.

   openclaw plugins uninstall knowledge --dry-runopenclaw plugins uninstall knowledge

3. Re-enable the plugin to replace the marker, then set plugins.slots.memory back to "knowledge" and restore plugins.entries.knowledge.config.

   openclaw plugins enable knowledge

4. Confirm that the bundled copy is loaded:

   openclaw plugins inspect knowledge --runtime --json

Vault data and plugin state live under <state dir>/knowledge/, not in the install directory, so switching copies does not move or reset them. Store membership is read from configuration, so restore stores before agents use Knowledge again. Until then, agents from a named store use their own isolated store, and a new empty one is created if none exists. The named store's data is kept. See Discovery precedence and Uninstall.

Related

• Stores and access
• Memory provider
• Tools
• Records and ontology
• Retrieval and dates
• Evidence files
• Ingestion workflows
• Corrections and merges
• Local history
• Maintenance
• Control UI
• Memory overview