Don’t Build Multi-Agents は、Devin を手がける企業である Cognition のブログに掲載された記事であり、当時広く行われていた AI エージェントの構築方法、すなわちタスクを並列に動く複数のサブエージェントに分割し、その結果を統合するというやり方に反対している。記事の出発点は、エージェントの構築には、React が Web 開発にもたらしたような共通の哲学がいまだに欠けており、一部のライブラリ（記事は OpenAI の Swarm と Microsoft の AutoGen を名指ししている）がマルチエージェントアーキテクチャを積極的に推し進めているが、著者はそれをエージェントの誤った構築方法だと考えている、というものである。
記事は長時間稼働するエージェントの信頼性を中心に据え、その核心として コンテキストエンジニアリング を挙げる。記事はこれを、プロンプトエンジニアリングの次の段階であり、動的なシステムにおいてモデルに適切なコンテキストを自動的に与える作業であって、AI エージェントを構築するエンジニアにとって事実上最も重要な仕事だと説明している。記事は具体例から 2 つの原則を導き出し、それらに反するアーキテクチャはデフォルトで除外すべきだと主張して、シングルスレッドの線形エージェントを推奨する。非常に長いタスクに対しては、行動と会話の履歴を圧縮するモデルで任意に拡張することもできるとしている。
要点
- 記事の例は、背景のサブタスクと鳥のサブタスクに分割された「Flappy Bird のクローン」である。一方のサブエージェントは自分のサブタスクを誤解して別のゲームのスタイルの背景を作り、もう一方は背景と合わない鳥を作ってしまい、最終的なエージェントには 2 つの誤解を組み合わせる仕事が残される。
- 元のタスクを各サブエージェントにコピーするだけでは十分ではない。本番システムでは会話はマルチターンであり、それ以前のツール呼び出しや細部のすべてが、タスクをどう解釈すべきかに関わりうるからである。
- 原則 1：コンテキストを共有すること。そして個々のメッセージだけでなく、エージェントのトレース全体を共有すること。
- コンテキストを共有しても、互いの作業を見ることのできない並列のサブエージェントは、矛盾する前提に基づいて選択を行い、一貫しない結果を生む。記事はこれを原則 2 として述べている。行動には暗黙の決定が伴い、矛盾する決定は悪い結果をもたらす。
- 両方の原則に従う最も単純なアーキテクチャは、コンテキストが連続しているシングルスレッドの線形エージェントである。その限界は、非常に大きなタスクでのコンテキストウィンドウのあふれである。
- 本当に長いタスクに対して記事が示す選択肢は 1 つである。行動と会話の履歴を主要な詳細・出来事・決定へと圧縮することを目的とした別の LLM を用いるというもので、記事はこれを正しく実装するのは難しいとし、Cognition がこのためにより小さなモデルをファインチューニングしていることに触れている。
- 記事は 2025 年 6 月時点の Claude Code について、サブタスクを生成するものの決してメインエージェントと並列には実行せず、通常はコードを書かせるのではなく答えるべき質問だけを与えることで、サブエージェントの調査作業をメインエージェントの履歴から切り離していると説明している。
- 記事は 2024 年の Edit apply モデル パターンを、モデル間の誤解に悩まされたもう 1 つの設計として挙げ、現在では編集の決定とその適用は 1 つのモデルが 1 回の行動で行うことが多くなっていると指摘している。
- 記事は、2025 年の時点ではエージェント同士が長いコンテキストでの対話を通じて意見の相違を解決することは、単一のエージェントより格段に信頼性が高いとはまだ言えないと判断しており、そのため協働するエージェントは、決定があまりに分散し、コンテキストの共有が十分に徹底されない脆いシステムを生むとしている。著者は、シングルスレッドのエージェントが人間とのコミュニケーションに長けていくにつれて、この状況は改善すると予想している。
背景
この記事は、自社のエージェント製品を構築している企業の視点から書かれており、その原則を、Cognition のチームが何度も学び直し、社内のツールやフレームワークの基盤としているものとして示している。記事は測定結果を報告しておらず、著者はこの分野の標準は変わっていくと予想して、ある程度の柔軟さと謙虚さを求めている。