Busabase × Jan
Knowledge Base for Jan
Keep local inference and shared business knowledge distinct
Jan can work with local models, project files and MCP tools. Busabase adds shared Docs and structured business records when colleagues need to use and maintain the same knowledge. Choose which material can leave the device before connecting a remote service.
Connection guide →
Decide what stays local and what becomes shared
Classify material by purpose, not file format. Personal reasoning, unauthorized contracts and offline references can stay on the device. Product guidance, service policies and accepted conclusions used by colleagues belong in shared knowledge. A project can use both layers without uploading its entire local folder.
For each class, identify readers, editors and the sources an answer must show. Use a Doc for the full explanation and a Base for facts that change. Query the selected Space when team information is needed and return its record links. Personal tasks can continue using local context.
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.
Model location, tool use and remote data are separate choices
A local model selects where inference runs; remote MCP selects a service to contact; Busabase authorization determines accessible data and changes. Check all three. Start with a known nonsensitive record, verify that the model can call tools and authentication returns the intended Space, then expand the allowed material.
Update shared knowledge without re-uploading a project
When product guidance is outdated, locate its shared record and source. Propose only fields or paragraphs supported by new evidence. Reviewers see the old value, new value and reason; later Jan tasks read the formal version after acceptance. Preserve references between local material and shared records without exposing the local files.
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
Jan supports remote HTTP/SSE MCP and OAuth with PKCE. Its tool permission setting can approve tool calls, including a global allow-all setting. That does not set Busabase record permissions. Local inference also does not mean remote MCP requests stay on the device: selected queries and results travel to the connected service.
An instruction to adapt
Use only the team policy Doc and approved product records in the connected Space. Answer with record links. Do not upload my local project files. If a shared fact is outdated, propose a sourced correction and show the resulting ChangeRequest.
Questions before you connect
Does using a local model keep remote MCP requests offline?
No. Model execution and remote tool traffic are separate. Choose permitted material before connecting and keep private local files outside the requested tool scope.
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.