マルチエージェントループの失敗はプロンプトの失敗ではなく、組織設計の失敗である

ほとんどのマルチエージェント設定は、やがて同じ壁にぶつかります。エージェント同士が応答し合い、レビュアーが延々と修正を要求し、リサーチワーカーが無制限にサブトピックを生成し、ツール呼び出しが再帰制限に達するまで続きます。フレームワークのドキュメントではこれらを「ループ」と呼び、最大反復回数の設定を提供しています。注目を集めている仮説の一つは、その設定は症状を治療しているに過ぎず、本当の問題はエージェントの組織化の仕方にあるというものです。

繰り返し現れるパターン：エージェントが同僚として設計されている場合（リサーチャーがアナリストと話し、アナリストがライターと話し、ライターがレビュアーに戻す）、誰も明確に結果を所有しません。どのエージェントも他のエージェントにさらに作業を依頼できます。グラフ上では停止条件がありますが、単一のエージェントが「これで完了、実行を停止」と宣言する権限を持ちません。その権限は暗黙的であり、同僚ネットワーク全体に希釈されます。

解決策は、エージェントネットワークを同僚のチャットルームではなく、明確な報告ラインを持つ組織図として扱うことです。提案される階層：

• 議長（最上位の権限、終了可能）
• 戦略室
• 部門長
• チームリーダー
• 専門ワーカー
• QAとポリシーは別のスタッフ部門として、却下やエスカレーションはできるが、無制限の新規作業は発生させられない

主要なメカニズム：

• 実行ごとに一人の責任あるミッションオーナー
• ワークストリームごとに一人のオーナー
• 有限の委任深度
• ワーカーごとの型付き返却契約：ステータス、証拠、出力、ブロッカー、次のアクション
• マネージャーのみ再開または終了の権限
• メモリは権限層に存在し、専門家はスコープ限定のコンテキストのみ

特にレビューア再帰の失敗モードは、検証者が構造的に一回の却下パスのみ許可され、その後エスカレーションしなければならない場合に解消されます。

既存のフレームワークにはすでにプリミティブがあります：

• CrewAI — マネージャーがワーカーの出力を検証する階層プロセス
• LangGraph — スーパーバイザー、サブエージェント、明示的な再帰制限
• OpenAI Agents SDK — ピアハンドオフとは異なるマネージャースタイルのオーケストレーション
• AutoGen — GroupChatManager
• Anthropic — オーケストレーター・ワーカー研究システム

あまり活用されていないアイデア：マネージャーをオープングループチャットのモデレーターではなく、終了権限を持つ正式な報告ラインとして扱うこと。

二つの未解決の懸念：

1. 階層はそれ自体がボトルネックになり得る — すべての決定が上位にルーティングされると、議長が遅延と障害の単一障害点になる。
2. エスカレーションが機能として成り立つのは、トップが本当の停止権限を持つ場合のみ。議長がさらにLLMを呼び出し、それがさらにLLMを呼び出すだけなら、ループは単に一階層上がっただけになる。

提案された組織図階層を含むリポジトリ： github.com/jeongmk522-netizen/agentlas_org_chart