agent-fungibility

エージェントの互換性 — エージェントスウォームをスケーラブルにする鍵

核心となる原則：「互換性があれば、コンピューターシステムに多くの優れた特性が自動的に備わります。」

ボトルネックはあなた自身です。エージェントスウォームにとってのぜんまい仕掛けの神となりましょう。美しく精巧な機械を設計し、動かし始めたら、次のプロジェクトに移りましょう。

---

議論：専門化エージェントか、互換性のあるエージェントか

ソフトウェアプロジェクトで作業するエージェントの数を増やす最適な方法をめぐり、議論が盛んになっています。

アプローチ	説明
専門化された役割	テスターエージェント、バックエンドエージェント、コミッターエージェントなど、個別の役割を割り当てます
互換性のあるエージェント	すべてのエージェントが同一で、どのタスクでも実行できます

ソフトウェア開発における答えは、互換性のあるエージェントです。

---

互換性が有効な理由

専門化エージェントの問題点

エージェントに特定のタスクを割り当てた複雑で異種混在のシステムを構築する代わりに、そうしたシステムは脆弱で、エージェントがクラッシュしたり、記憶を失ったり、あるいはコンテキストの劣化に陥って終了させる必要が生じたりしたときに問題が起こります。その場合、次のことに対処しなければなりません。

1. どの種類のエージェントが停止したのかを把握する
2. 停止したときに何をしていたのかを確認する
3. 関連するコンテキストを使って、機能的にどう置き換えるかを考える
4. その専門化エージェントに依存していたほかのエージェントに何が起きるかを考える

互換性による解決策

どんな種類の bead でも実行できる、互換性のあるエージェントを複数用意するほうが適切です。

エージェントには、どのようなものでも利用できます。

• Claude Code
• Codex
• Antigravity CLI（agy、「Gemini 3.1 Pro (High)」に固定。提供終了予定の Gemini CLI の後継）
• Amp
• Cursor
• など

ただし、どれもあらゆる役割を担え、取り組んでいる bead のタスクに応じて柔軟に役割を引き受けられるという意味で、互換性があります。

---

大きなブレークスルー 2 つ

1. BV を使って最適な次の bead を選ぶ

各エージェントは bv --robot-triage または bv --robot-next を使って、影響度が最も高い着手可能な bead を見つけます。中央で割り当てる必要はありません。

2. すべてを計画 → Beads に入れる

実行したいことをすべて、bead に変換する元の Markdown 計画に記載すれば、ほかのすべてを「追加の手間なく」実現でき、エージェントに何か問題が起きても堅牢です。

---

堅牢性

エージェントは停止します。たとえば、次のようなことが起こります。

• クラッシュする
• 誤ってタブを閉じてしまう
• コンテキストが劣化する（何をしているのか分からなくなる）
• ループから抜け出せなくなる
• 「終了」して再起動する必要が生じる

互換性のあるエージェントなら、こうしたことを心配する必要はありません。

エージェントが停止した場合：

1. 作業中だった bead は進行中のまま残ります
2. ほかのエージェントが引き継げます
3. 特別な置き換えロジックは不要です
4. 特定のエージェントに依存しません

---

スケーリングの特性

作業を速めたい場合：

• いつでもエージェントを追加で起動するだけです
• 各エージェントの役割数に偏りがあるか考える必要はありません
• エージェントが 3 体から 10 体、20 体になっても、同じことをするエージェントを追加するだけです

エージェントの互換性によって作業を大幅に速められ、特に次のような場合にスケーラビリティが向上します。

• プロジェクトが大きく複雑になる
• 同じプロジェクトに同時に取り組むエージェントが 10 体を超える

---

たとえ：フォウンテンコード

私はファイル保存に使われるフォウンテンコード（RaptorQ など）が大好きですが、その理由はここにあります。

ファイルを、オーバーヘッドがごくわずかな互換性のあるブロブの無限ストリームに変換すると、ユーザーは任意の順番でどのブロブでも受け取ることができ、新しいブロブを受け取るたびにファイルの復元に役立ちます。BitTorrent のような「最も希少なチャンク」はありません。

ソフトウェア開発では：

• 各 bead が「ブロブ」です
• どのエージェントも、どの bead にも取り組めます
• ボトルネックになる「重要な専門家」はいません
• システムは部分的な障害にも耐えられます

---

特化した役割が有効な場合

エージェントに特定の役割を割り当てるほうが効果的な状況もあります。例：自動化された科学的探究（BrennerBot など）。

有効な理由：

• 異なる種類のエージェント間のやり取りそのものが、真実を明らかにする中核的な仕組みです
• 議論の構造こそが目的です

ソフトウェア開発では有効でない理由：

• ソフトウェア開発では、動作する優れたコードがあれば十分です
• 目的は成果物であり、議論ではありません
• 交換可能性によってボトルネックや単一障害点がなくなります

---

時計仕掛けの神の哲学

私のエージェント向けツールやワークフローの多くは、私を工程から取り除くためのものです。私自身は一人しかいませんが、エージェントの数は事実上無制限にできるからです。

実現する方法：

1. 計画段階ですべての入力を前もって与える — Extended Reasoning を備えた GPT Pro を使い、複数回反復し、すべての最先端モデルからのフィードバックを組み合わせます
2. タスクの構造化を委任する — 計画を、完全な依存関係グラフを持つ beads に変換します
3. 直接のコミュニケーションを可能にする — Agent Mail により、エージェントはあなたを介さずに連携できます
4. 実行を開始して、次に進む — 戻ってくる頃には、作業の大部分が完了しています

これが機能する理由

最終的にすべてがうまくいくのは、次の理由によります：

• 最良のモデル（GPT Pro）を最大限に活用する
• すべての最先端モデルからのフィードバックを組み合わせながら、何度も反復する
• 最終判断には最高のモデルを使う
• 「計画空間」ではすべてがコンテキストウィンドウに余裕をもって収まる
• モデルは、狭い視野からではなく、システム全体を一度に把握できる

---

実践的な実装

交換可能なスウォームの開始

# Spawn agents (any mix of types)
ntm spawn myproject --cc=3 --cod=2 --agy=1

# Give them all the SAME initial prompt
ntm send myproject --all "$(cat initial_prompt.txt)"

最初のプロンプト（すべてのエージェントに共通）

First read ALL of the AGENTS dot md file and README dot md file super carefully and understand ALL of both! Then use your code investigation agent mode to fully understand the code, and technical architecture and purpose of the project. Then register with MCP Agent Mail and introduce yourself to the other agents.

Be sure to check your agent mail and to promptly respond if needed to any messages; then proceed meticulously with your next assigned beads, working on the tasks systematically and meticulously and tracking your progress via beads and agent mail messages.

Don't get stuck in "communication purgatory" where nothing is getting done; be proactive about starting tasks that need to be done, but inform your fellow agents via messages when you do so and mark beads appropriately.

When you're not sure what to do next, use the bv tool mentioned in AGENTS dot md to prioritize the best beads to work on next; pick the next one that you can usefully work on and get started. Make sure to acknowledge all communication requests from other agents and that you are aware of all active agents and their names.  Use ultrathink.

エージェントが失敗した場合

1. 慌てない
2. 代わりに新しいセッションを開始する
3. 同じ最初のプロンプトを与える
4. エージェントは次のように動作します：
   • AGENTS.md を読む
   • bv で bead の状態を確認する
   • 進行中または停滞中の作業を確認する
   • 再開するか、新しい bead を選ぶ

特別なロジックは不要です。役割の割り当ても不要です。ただ交換可能であればよいのです。

---

まとめ

特性	特化型エージェント	交換可能なエージェント
障害への対処	複雑	シンプル
スケーリング	役割のバランス調整が必要	追加するだけ
置き換え	同じ専門分野のエージェントが必要	どのエージェントでも対応可能
単一障害点	あり（役割ごと）	なし
連携のオーバーヘッド	高い	低い（beads ＋ mail を利用）
人間の関与	継続的	計画時に前倒し

要点： エージェントの交換可能性があれば、機械を一度構築して実行を開始し、次に進めます。あとはスウォームが対応します。