誰もがAIエージェントのチームを構築したいと考えています。デモは抗いがたいほど魅力的です。あるエージェントが調査を行い、別のエージェントがコードを書き、3番目のエージェントがテストを実行する。しかし、こうしたシステムの多くには、ある「不都合な真実」があります。それは、それらが脆弱であるということです。5分間のデモでは見事に機能しますが、実際の調査では崩壊してしまいます。失敗の原因は、言語モデルの推論能力やスウォーム内のエージェント数であることは稀です。真の原因はその「間」にあります。マルチエージェント・システムは、コラボレーション・プレーン（協調レイヤー）において破綻するのです。
スーパーバイザーの罠
デフォルトのアーキテクチャは、抗いがたいほどシンプルです。スーパーバイザー・エージェントが目標を受け取り、それをサブタスクに分割して、ワーカー・エージェントに委任します。ワーカーは実行して結果を返し、スーパーバイザーはそれらすべてをまとめて最終的な回答を作成します。このパターンは、10個の記事を要約したり、音声ファイルを文字起こししたり、100個の均一なウェブページからデータを抽出したりする場合なら問題ありません。タスクは独立しており、互いにやり取りを必要としないからです。
複雑な調査は異なります。あるエージェントが驚くべき発見をしたとき、作業の方向性全体を転換する必要があるかもしれません。もしシステムにその変化を周知するための構造化された方法がなければ、他のエージェントは誤った方向に進み続けてしまいます。結果として、対話ではなく、並行した独白の集まりになってしまいます。スーパーバイザーは調整役（コーディネーター）ではなく、ボトルネックになってしまうのです。
協調が失敗したときに失われるもの
調査が深まると、最終的な回答以上の情報を知る必要があります。誰が、いつ、何を知っていたのかを知る必要があります。どの発見が作業の方向性を決定づけたのかを追跡する必要があります。なぜエージェントが2時間前に計画を変更したのかを理解する必要があります。コラボレーション・プレーンがなければ、これらは一切可視化されません。手元にあるのはログだけです。ログは時系列的なノイズに過ぎません。ログは「エージェントCがAPIコールではなく、突然データベースのトランザクションの分析を開始した」ことは記録しますが、その理由は説明しません。何が起きているかを眺め、推測することしかできないのです。
セキュリティインシデント対応を例に考えてみましょう。エージェントAがサーバーログを精査し、侵害はそこからは始まっていないと結論付けます。エージェントAはその出力をスーパーバイザーに返します。ネットワークトラフィックの分析を割り当てられたエージェントBは、その結論が「却下された仮説」として提示されていることを知りません。エージェントBの元のタスク記述では、依然としてサーバーが主要な容疑者として扱われているため、エージェントBは同じログの中に指紋を探すという無駄なサイクルを繰り返します。システムは同じ作業に二度コストを払い、最初の実行から何も学ばないのです。
コラボレーション・プレーンはメモリではない
コラボレーション・プレーンは、単なる事実を格納するためのメモリのバケツではありません。メモリは情報を保存します。コラボレーション・ステートは、進行中の作業を保存します。ドキュメントでいっぱいのベクトルデータベースは、エージェントに参照資料を与えます。しかし、それは「エージェントXが現在、エージェントYの現在のタスクを不要にするような仮説をテストしている」ということをエージェントに伝えるものではありません。メモリは静的なコンテキストです。コラボレーション・ステートは、オペレーションのライブマップ（動的な地図）なのです。
この二つを混同すると、会社のハンドブックのあらゆる段落を検索することはできても、別のエージェントがあなたの現在のタスクを無意味なものだと証明したかどうかを教えてくれないようなシステムを構築することになります。
共有ステートの5つのバケツ
真のコラボレーション・プレーンには、5つの特定のバケツが必要です。
Claims（主張）。 これらはエージェントがテストしているアクティブな仮説です。不正調査において、主張とは「異常は週末のバッチジョブと相関している」といったものかもしれません。すべてのエージェントは、どの主張が未解決か、どの主張がテスト中か、そして誰がその主張を所有しているかを確認できる必要があります。これがないと