Knowledge Base for OpenClaw
OpenClaw gives an Agent durable local continuity through workspace files, daily memory, long-term memory, Skills, and routed sessions. Busabase is the promotion boundary for facts that must become reviewable, team-owned, and reusable outside one Agent's memory lifecycle.
Four memory files
Personal continuity and organizational authority are different retention problems.
OpenClaw documents explicit file-backed memory rather than hidden state. Each file has a different startup and maintenance role; none automatically becomes a team-approved record.
| File | Intended lifetime | Keep there |
|---|---|---|
| USER.md | Stable user model | Preferences, communication style, active profile directives |
| MEMORY.md | Curated long-term continuity | Durable non-profile facts and standing decisions |
| memory/YYYY-MM-DD.md | Working layer | Daily observations, session summaries, raw context |
| DREAMS.md | Review surface | Consolidation and backfill summaries for human inspection |
Workspace is not execution cwd
Keep identity and memory stable even when tools work in another repository.
OpenClaw can separate the managed Agent workspace from the execution working directory. Bootstrap files and memory remain under the Agent workspace while deliverables go to the selected cwd or managed worktree. A Busabase record should reference both when they affect provenance.
Sessions and channels
The same Agent can hear many conversations without turning every message into shared truth.
Session keys, channel bindings, group context, and multi-agent routing determine who said what and where the Agent acted. Preserve the source session as provenance, then promote only the state that needs a stable owner.
Inbound request and sender context
Conversation, tool trajectory, attachments
Continuity selected for future turns
Reviewed state shared beyond the session
Promotion ladder
Move from observation to canonical record through explicit lossless checkpoints.
Daily notes can be noisy; long-term memory is curated; organizational knowledge needs stronger admission criteria. Promotion should reduce volume while increasing evidence and accountability.
Action-sensitive memory
A remembered approval context is guidance, not a policy enforcement mechanism.
OpenClaw recommends recording timing, expiry, owner authority, safe-to-act conditions, and prohibited actions when a memory could change future behavior. Hard controls still belong in approval settings, sandboxing, scheduled tasks, credentials, and reviewed system state.
Why work is blocked
Who owns a decision
What unlocks action
When a constraint expires
Tool permission
Credential scope
Sandbox boundary
Change Request approval
Skill ownership and revisions
A Skill teaches execution; it should reference current knowledge instead of embedding changing facts.
OpenClaw Skills are versioned instruction bundles selected by workspace, project, personal, managed, Workshop, bundled, or extra-directory precedence. Keep reusable procedures and tool guidance in Skills. Let them query reviewed records for changing operational facts.
SKILL.md
When and how to perform a task
Skill revision
Immutable instruction bundle selected by a session
Busabase record
Current reviewed inputs, decisions, and status
MCP handoff
Connection, execution permission, and knowledge acceptance remain separate decisions.
OpenClaw can register, authenticate, probe, and project saved MCP servers into eligible runtimes. A successful probe confirms connectivity; an executed tool confirms an action occurred; only record review decides whether the resulting state becomes canonical.
Operational knowledge contract
Store the claim with enough lineage to survive session pruning and memory consolidation.
The record should remain understandable after local memory changes or the originating channel is no longer available.
knowledge_keyStable identity across sessions and AgentsclaimConcise statement proposed as currentsource_sessionOriginating session or channel referenceworkspace_refAgent workspace and relevant memory fileexecution_refRun, command, artifact, or external responseevidenceImmutable supporting materialownerPerson responsible for acceptance and upkeepfreshnessObserved, effective, and next-review timesdecisionAccepted, conditional, rejected, or supersededRetention and freshness
Do not let a durable memory silently outlive the fact it describes.
Use explicit review dates and supersession links for knowledge that changes. Memory search can retrieve old notes because they remain useful provenance; downstream workflows should prefer the current merged record.
Review the memory lifecyclePractical questions
OpenClaw knowledge base FAQ
Does Busabase replace MEMORY.md?
No. MEMORY.md gives one Agent curated continuity. Busabase stores reviewed facts that teams, workflows, and multiple Agents may rely on.
Should every daily note be promoted?
No. Most notes remain working context. Promote only durable claims with evidence, an owner, and a reuse need.
Can memory enforce approval policy?
No. Memory can preserve constraints and approval context, but hard controls require permissions, sandboxing, credentials, or review gates.
Should a Skill contain current customer or operational status?
Usually not. Keep the procedure in the Skill and query reviewed records for changing facts.
What happens when the original session is pruned?
The reviewed record retains the claim and bounded provenance links; raw session content remains subject to OpenClaw's own retention policy.
Start with one promoted fact
Let OpenClaw remember broadly and let shared truth pass through a narrower review gate.
Choose one action-sensitive memory that another Agent or team needs. Attach its source, execution evidence, owner, and freshness rule, then review it before reuse.

