Busabase × Agentastic
Agentastic のナレッジベース
起動時の設定と承認済みの事実を分ける
Agentastic は worktree や実行環境を分けて CLI を動かします。プラグインと起動設定は使えるツールを決め、Busabase は調査結果の版と承認履歴を保持します。設定への同意を結論への承認と混同しません。
Busabase の製品画面（英語）。
設定は実行を管理し、レコードは判断を残す
manifest とプラグイン設定は起動環境、リポジトリは調査対象のコード、共有障害レコードは承認された判断を扱います。設定の版と知識の版を分け、設定変更で過去の結論の意味が変わらないようにします。
実行の文脈
作業ファイル、指示、一時的な観測は実行環境に残します。
根拠への参照
主張を支える出典、観測時刻、適用範囲を保存します。
承認済みのチーム記録
現行レコードへの参照を通じて承認済みの値と未解決の問いを渡します。
同じ障害に二つの worktree が異なる説明を出す
架空の障害調査で、異なるコミットを見た Agent が反対の原因を提案します。コミット、環境、観測時刻を添え、同じデプロイを調べているか確認してから結論を承認します。次の起動では正式な版を読みます。
架空の例です。実際の顧客データや実測結果ではありません。
提案レコードの例
| 項目 | 例の値 | 証拠・判断 |
|---|---|---|
| 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：コミットと仮説
- 02worktree B：別コミットと仮説
- 03レビュー：環境と時刻を照合
- 04正式 head：適用範囲付きの結論
答えを比べる前にデプロイを照合する
worktree ごとにコミット、デプロイ先、時刻、根拠を保存します。異なるリリースの観測なら適用範囲を分けます。一方の説明を承認し、もう一方には再検証を求められます。修正はそれぞれの PR に紐付けます。
次の Agent に残す情報
レコード項目の例
incident_id、repo、commit、environment、observed_at、source、claim、next_check
プラグインの変更は新しく起動する Agent に適用され、既存セッションには自動反映されません。MCP 対応 provider は文書で確認します。manifest への同意や認証情報の管理は実行設定の話で、知識の承認とは別です。
出典＋観測時刻
ファイル、行、コミット、URL と実際の確認時刻を紐付けます。
適用範囲＋承認状態
対象の環境や成果を明示し、根拠のない項目は未解決にします。
責任者＋次の確認
判断の管理担当と再検証が必要になる条件を指定します。
調査から正式レコードへ
- 01既存レコードを読み、Space、Base、head を確認します。
- 02根拠のあるフィールドだけを提案し、出典と不明点を残します。
- 03承認前の提案には changeRequest 権限を選びます。write は広い権限で、人の承認を必須にする設定ではありません。
- 04権限のあるレビューとマージの後、正式レコードを読み返し、次のタスクに版と不明点を渡します。
新しい起動で現行の判断を読み直す
起動時に provider と MCP 設定を確認して正式レコードを読みます。コミットや環境が違えば適用可能性を確認します。原因を更新するときは旧値と変更を裏付ける新しい証拠を残します。
よくある質問
プラグインへの同意で調査結果も承認されますか？
いいえ。設定への同意と事実の承認は別です。診断には正しい版、環境、根拠と受け入れ判断が必要です。新しい既定設定が既存タスクに反映済みとも限りません。
元のメモリーを置き換えますか？
いいえ。元の指示やセッションの記憶は実行に使い、共有する確認済みの事実と出典をここに残します。使うときに最新版を読みます。
同時更新はどう扱いますか？
提案前に現在の head を読みます。変更されていたら差分を確認し、新しい証拠を上書きせず提案を修正します。