Busabase × AgentsRoom
Knowledge Base for AgentsRoom
Shared facts across CLIs, separate from skill injection
AgentsRoom brings multiple coding CLIs and projects into one workspace. Native memory, instructions and skills can guide how a task runs; Busabase stores the evidence-backed decisions those tasks share. Read the current record at handoff rather than assuming an injected baseline is still the latest fact.
Busabase product interface (English).
Instructions guide the task; shared records carry accepted facts
Project instructions, native memory and skills guide execution in each CLI. Busabase records preserve compatibility decisions and evidence needed across projects. A skill can tell an agent to check a decision register; the record it retrieves still needs a scope and acceptance state of its own.
Execution context
Keep working files, instructions and temporary observations with the task.
Evidence references
Preserve the source, observation time and exact scope that support a claim.
Accepted team record
Carry reviewed values and unresolved questions into the next task through a current record reference.
A dependency upgrade needs one accepted compatibility decision
Illustrative upgrade: Claude Code tests one repository while Codex checks a second project. One reports compatibility; the other finds an unsupported environment. Preserve both scopes and evidence. A shared record can accept the supported case while keeping the unsupported one open, without rewriting either agent’s native memory.
Illustrative example, not a real customer result or test.
Example proposal ledger
| Field | Illustrative value | Evidence / decision |
|---|---|---|
| scope.A | repository A / runtime A | verified scope |
| scope.B | repository B / runtime B | open question |
| acceptance_status | separate by project and environment | bounded |
| next_session | read current head before reuse | required |
- 01project A: supported scope
- 02project B: unresolved environment
- 03proposal: separate acceptance states
- 04next CLI: reread canonical head
Accept compatibility by environment, not by majority
Record the repository, dependency version, runtime and check output for each project. A passing result in project A does not resolve a failure in project B. Keep accepted and unresolved scopes side by side, with the next test assigned to the failing environment. This lets a later CLI reuse verified evidence without erasing the exception.
What the next agent should receive
Suggested record fields
source_repo, commit, environment, scope, observed_at, evidence, acceptance_status
A resumed session may not replay the initial prompt; switching CLIs also changes the runtime context. Check server availability per agent: Aider has no MCP client, and team-step settings do not imply an MCP grant. Secret placeholders and resolved project configuration are credentials handling, not approval of record values.
Source + observation time
Link the exact file, row, commit or URL and state when it was inspected.
Scope + acceptance state
Name the environment or delivery affected; keep unsupported fields unresolved.
Owner + next check
Assign who maintains the conclusion and what evidence would require revisiting it.
From a finding to an accepted record
- 01Read the existing record and verify Space, Base and head.
- 02Propose only supported fields; include evidence and unresolved questions.
- 03Use changeRequest permission when review must precede acceptance. A write grant is broader authority, not a mandatory human gate.
- 04After authorized review and merge, read the canonical record back. Carry its version and open questions into the next task.
Resume with a fresh read, not a stale baseline
Before a resumed session makes a recommendation, read the current compatibility record and compare its version with the previous handoff. Confirm that the selected CLI can access the server. Where MCP is unavailable, route the evidence check through a supported task instead of interpreting workspace configuration as access approval.
Practical questions
Should a resumed session trust its old baseline?
Read the current canonical record first. Compare the head and scope with the baseline; preserve any unanswered question. A resumed prompt or injected skill can guide procedure, but does not establish that a fact is still current.
Does this replace native memory?
No. Keep native instructions and session memory for execution. Store reviewed facts and their sources here, and read their current version when needed.
How do concurrent updates work?
Read the current head before proposing. If it changes, inspect competing edits and revise the proposal rather than overwriting new evidence.