Busabase × nanobot
Knowledge Base for nanobot
Promote useful memory into team-owned knowledge
nanobot already has persistent memory and history. Busabase provides shared Docs and Bases when an accepted business fact must outlive one assistant and become accessible to colleagues. Preserve personal preferences in native memory while giving team knowledge a clear source and owner.
Connection guide →
Persistent memory still needs team acceptance
Session messages continue a conversation, history supports recall, durable memory retains preferences and context, and GitStore supplies version history. Team knowledge also needs a source, owner, audience and acceptance decision. Longer retention does not replace those responsibilities or make native memory less useful.
Promote the conclusion that needs sharing, not the entirety of SOUL, USER and MEMORY. Put complete business rules in Docs and specific facts in Bases, linked to sources, owners and acceptance state. Keep personal habits and private background in their native layer while colleagues maintain the shared record.
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.
When memory and policy disagree, retain both sources
Read the shared policy before changing a record from memory. Locate the difference in a field or paragraph and identify the remembered source and current policy version. Propose a change when new evidence supports it; otherwise keep the question open. A previous conversation is not a team approval record.
Reuse team knowledge without exporting private memory
Hand over the record link, scope, source and open questions. The receiving task rereads it under its own identity. Different permissions or expired sources should be reported to the owner. Continue from the current formal record after an update; old personal context does not replace checking that version.
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
The official configuration documents remote HTTP MCP and OAuth. Follow the current connection guide for authentication and available routes. A remembered instruction does not grant write access, and a Git history entry does not mean a team accepted the business fact. Re-read the shared record before the next task uses it.
An instruction to adapt
Find the shared policy that supports this remembered conclusion. Keep personal notes private. If the conclusion differs from the accepted policy, show both sources and propose a correction; do not silently overwrite the policy or treat memory as approval.
Questions before you connect
Is a GitStore change already a team approval?
History records change. Team acceptance also needs an authorized decision tied to the fact and its evidence. Preserve both histories without treating them as the same event.
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.