Busabase × ZeroClaw
Knowledge Base for ZeroClaw
Shared knowledge across sessions and channels
Busabase gives ZeroClaw shared Docs and structured Bases for knowledge that more than one conversation needs to use. Keep local context for the current task; read shared policies and business records from their current accepted version.
Connection guide →
How one policy serves different channels
Keep channel conversations, tool capabilities and business knowledge as separate layers. A conversation explains the request, tool configuration determines available actions, and a shared policy supplies the answer’s basis. Later tasks read the same record after a policy changes, rather than maintaining a separate policy copy for each channel.
Put the policy, its audience and exceptions in a Doc. Track its source, owner and validity in a Base. ZeroClaw should return the specific record link with an answer. Link an uncovered case to that policy instead of silently extending the rule in chat, so the owner can distinguish a missing fact from a missing policy or execution permission.
What belongs where
Policy Doc
The complete policy, audience, exceptions and source. Its owner maintains the explanation.
Knowledge Base
One record per maintained fact: stable key, value, source URL, owner, scope and state. Link it to the policy Doc.
Update Skill
The reading, evidence and proposal procedure. It guides the agent without granting data access.
Result record
Link the task to its output, the decision and unresolved checks. The next run reads the actual result.
Verify the tools that actually loaded
Check that the agent alias declares the required mcp_bundles, then restart the session. A configured server is not automatically granted to every alias, and a server grant does not bypass tool approval. Verify identity and Space read-only, read a known Doc, and only then attempt a narrowly scoped change.
Return missing policy evidence to its owner
When channels disagree, compare the policy version, audience and source behind each answer. An old reply can help investigate, while the current formal record remains the next task’s entry point. Keep unresolved conflicts and the next check explicit rather than marking the whole record confirmed.
Leave a checkable handoff
A useful handoff identifies the exact record that was read, the source that supported the answer, and the applicable scope. For a proposed edit, return the ChangeRequest link and the fields it would change. When a change is accepted, return the canonical record and verify the resulting value. Keep these outcomes distinct so the next agent can tell what it can rely on.
Start with one fact you already maintain
- 01
Select an existing policy or fact with a known source. Assign its owner before asking the agent to change it.
- 02
Read the current record and have the agent return the source, applicable scope and version. Check those before allowing a write.
- 03
Propose a bounded update with old and new values, the reason and evidence. When review is required, keep it as a proposal until an authorized decision.
- 04
Read the accepted record again from a fresh task. Check the value and source, and keep rejected or unresolved changes out of the answer.
Connection and permission boundaries
ZeroClaw MCP bundles and per-tool capabilities govern which tools are available. Configure and restart according to the official MCP guide, then verify the tools that actually loaded. A server connection, permission to call a tool and acceptance of the proposed business change are separate checks. Keep secrets in the supported credential configuration.
An instruction to adapt
Read the current service policy before answering in a second channel. Return its source and scope. If the policy needs changing, propose the exact paragraph and reason; keep using the accepted record until the change is accepted.
Questions before you connect
Why does a configured server not appear for my agent?
Check the alias’s bundle grant and restart the session, then inspect available tools. A configured endpoint and a per-alias grant are separate.
Will this replace native memory?
Keep native context for execution and private preferences. Share only the knowledge that another person needs to read, verify or maintain.
How do I check one useful cycle?
Read one existing record and return its link and source. Propose one supported correction, inspect the change, then read the accepted record again. A proposal link is not proof that the record changed.