Busabase × Agentastic
Knowledge Base for Agentastic
Launch configuration and recorded facts have different lifetimes
Agentastic runs coding CLIs in separate worktrees and execution environments. Its plugin and launch controls decide which tools an agent receives. Busabase gives investigated facts their own version history, with every change attributed to the agent that made it, so an approved launch configuration is not mistaken for approval of the agent’s conclusion.
The Assets library in Busabase: every file in the workspace in one place.
Configuration controls execution; records preserve decisions
A workspace manifest and plugin settings determine the launch environment. Repository files describe the code under investigation. A shared incident record preserves what the team has accepted about that incident. Keep configuration versions and knowledge versions distinct so a new plugin setup cannot silently change the meaning of an earlier finding.
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.
Shared team record
Hand the current values, their change history and the open questions to the next task through a record reference.
Two worktrees disagree about the same incident
Illustrative incident: two agents inspect different commits and propose conflicting causes. Store commit, environment and observation time with each claim. The reviewer checks whether the evidence even describes the same deployment before accepting a shared conclusion. A later launch reads the accepted version, not a copied diagnosis.
Illustrative example, not a real customer result or test.
Example proposal ledger
| Field | Illustrative value | Evidence / decision |
|---|---|---|
| source.A | commit A / staging | scope A |
| source.B | commit B / production | scope B |
| review_check | compare deployed commit and observation time | required |
| accepted_head | no shared cause before environment match | not accepted |
- 01worktree A: commit and claim
- 02worktree B: different commit and claim
- 03review: align deployment and time
- 04accepted head: bounded conclusion
Compare the deployment before comparing the answer
For each worktree, capture the commit, deployment target, observed time and evidence. If two observations describe different releases, split their scope rather than voting on the diagnosis. The reviewer can accept an explanation for one release and request a fresh check for the other. Link fixes to their own PRs.
What the next agent should receive
Suggested record fields
incident_id, repo, commit, environment, observed_at, source, claim, next_check
Plugin changes apply to new launches, not automatically to existing sessions. Agentastic documents a limited set of compatible MCP providers; do not assume every hosted CLI gets the same tools. Workspace manifest approval and credential storage govern execution configuration, while Busabase Change Requests record how the shared knowledge changed and who changed it.
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 a shared 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.
- 04Once the change merges (at once with a write key, or after someone approves it in the Inbox), read the record back. Carry its version and open questions into the next task.
New launches should reread the current decision
At launch, verify which provider and MCP configuration are active, then read the current incident record. If the commit or environment differs, check applicability before reusing the diagnosis. A change to the accepted cause should preserve the previous value and identify the new evidence that justifies the update.
Practical questions
Does accepting a workspace plugin approve its findings?
No. Plugin approval governs execution configuration. A diagnosis still needs the correct repository revision, environment, evidence and a separate acceptance decision. New plugin defaults also do not prove an already-running task has those tools.
Does this replace native memory?
No. Keep native instructions and session memory for execution. Store shared facts here with their sources and change history, 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.
Connect one bounded task
Connection guideHow MCP updates and optional approval workHow Change Requests work