責任者が誰もいない状態で、大規模なプロジェクトを計画するとどうなるでしょうか？ほとんどのソフトウェアスタックは、単一のオーケストレーターが存在することを前提としています。一つのプロセスが状態を保持し、ジョブをキューに入れ、タスクを割り当てます。そのコーディネーターが再起動すると、ワークフロー全体が停滞してしまいます。新しいプロジェクトは、その前提を完全に覆します。それは、AIエージェントの群れが、「日本への2週間の旅行を計画する」といった目標を、どの単一のノードも常に完全な計画を保持することなく、どのように完全なタスクツリーへと分解できるかを示しています。

なぜリーダーレスなシステムを構築するのか？

中央集権型のプランナーは、推論が容易です。サーバーにリクエストを送信すると、サーバーが作業を分割し、ワーカーが報告を返します。問題は、サーバーが認知的および物理的なボトルネックになることです。サーバーが「真実」を所有してしまうのです。

分散型のセットアップでは、真実は、ネットワークがゴシップ（gossip）を通じて収束していく共有されたイメージへと変わります。この特定のPython実装は、2つの異なる概念を組み合わせています。第一は、反復的な洗練ループです。あるエージェントが提案を書き、別のエージェントがそれをスコアリングし、第三のエージェントがそれを磨き上げます。第二は、libp2p上に構築されたピア・ツー・ピア（P2P）ネットワーク層であり、これによりエージェントはレジストリやロードバランサーなしで、互いを自動的に発見できます。その結果、誰も指揮者として振る舞うことなく、ピアが参加し、提案し、投票し、実行するクラスターが実現します。

4つの役割

システムは、すべての参加者に4つの役割（パーソナリティ）のうちの1つを割り当てます。4台の物理マシンを用意する必要はありません。1台のノートPC上で共存させることも、ホームネットワーク全体に分散させることも可能です。役割は以下の通りです。

  • Decomposer（分解者）。このエージェントは、最上位の目標を受け取り、それをサブゴールへと分割することを提案します。システムは複数のDecomposerを並列で実行するため、同じ日本旅行に対しても3つの異なるプランが得られる可能性があります。一つは地理（東京、京都、大阪）に基づいて旅程を分解し、もう一つはアクティビティ（移動、宿泊、食事、観光）によって分割し、三つ目は日ごとに順序立てるかもしれません。ネットワークはそれらすべてを検討します。

  • Scorer（スコアラー）。これらのエージェントは編集委員会として機能します。提案された分割を検査し、評価します。スコアは、サブゴールが十分に具体的か、重複がないか、そして全体として網羅されているかを反映します。さらに重要なことに、Scorerは提案が受け入れられるのに十分かどうかを決定します。Scorerの承認がなければ、分割案は宙ぶらりんのままとなります。

  • Executor（実行者）。ツリーが実行可能なほど小さなリーフノードに達すると、Executorたちがそれらを確保しようと競い合います。彼らは中央のキューからの許可を待ちません。代わりに、タイムスタンププロトコルを使用して、誰がタスクを確保するかを決定します。勝者はローカルのLLM呼び出しを通じてジョブを実行し、その結果をブロードキャストします。

  • Observer（オブザーバー）。これは、あらゆるネットワークに必要な「壁の花」です。ゴシップを静かに聞き、やり取りからプランツリーを再構築し、読みやすいスナップショットを表示します。Observerは決して発言しないため、重要なことを証明します。つまり、後から参加した誰でも、聞き耳を立てるだけでプラン全体を把握できるということです。

真実のソースとしてのゴシップ

libp2p層が発見とメッセージングを処理します。エージェントはプロトコルに組み込まれたピア発見機能を通じて互いを見つけ、共有トピックにメッセージをブロードキャストします。記録用のデータベースも、正規のプランを保持するRedisキャッシュも存在しません。

各ピアはプランツリーの自身のコピーを保持し、耳にしたゴシップに基づいてそれを更新します。Decomposerが提案をブロードキャストすると、他のすべてのノードがそれを受信し、フォーマットを検証して、ローカルのツリーにそのブランチを追加します。Scorerが投票を行う際も、集計は同様に伝播します。もし2つのExecutorが同じタスクに対して矛盾する主張を公開した場合、タイムスタンププロトコルが衝突を解決します。ネットワークはより早い主張を採用し、遅れた方の主張を破棄します。

時間の経過とともに、ツリーは元の目標から、承認されたサブゴールの層を経て、一口サイズのタスクに達するまで下方へと成長していきます。このプロセスは、ブロックチェーンがコンセンサスに達する様子に似ていますが、ペイロードはコインの台帳ではなく、旅行の旅程やソフトウェアの仕様書です。

投票と実行へのレース

民主主義にはコストがかかり、このシステムはその代償をレイテンシとして支払います。分割案が承認されるには、十分な数のScorerが同意する必要があります。その閾値は、クラスターの設定に応じて、単純な過半数、あるいはより厳格な定足数（クォーラム）になる可能性があります。Decomposerは提案を止めないため、ネットワークはしばしば複数の競合するツリーを同時に評価します。最終的に、あるツリーが必要な票数に達し、そのサブゴールはドラフトから承認済みへと昇格します。

エグゼキューターは、さらなる調整レイヤーを追加します。タスクはgossip channel上で公開されているため、複数のエグゼキューターが同じ魅力的なリーフノードを奪い合おうとする可能性があります。タイムスタンププロトコルがタイブレーカーとして機能します。各クレームには単調増加するタイムスタンプが付与されており、ネットワークは最も早いものを優先します。敗れた方は、単に次の利用可能なタスクへと移るだけです。これは粗削りな手法ではありますが、データベースの行をロックするような中央集権的なスケジューラを必要とせずに済みます。

設計によるレジリエンス

このアーキテクチャの真価は、障害が発生した際に発揮されます。デコンポーザーがサブゴールの半分を提案した後にクラッシュしても、生存しているデコンポーザーが分割の提案を続けます。プランは再起動を待って停滞することはありません。スコアラーがネットワークから離脱しても、クラスタのサイズを適切に設定していれば、残りの投票者でクォーラムに達することが可能です。

最大の利点は、遅延参加（late joins）です。途中で起動した新しいエージェントは、スナップショットや...