Coral AI Labs、複数AIエージェントのリアルタイム協調システム「AgentRadio」を発表
本文の状態
日本語全文を表示中
詳細モードで約18分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
VentureBeat AI
Coral AI Labs などの研究チームが開発した AgentRadio は、複数エージェントがリアルタイムで協調してコード解析を行う仕組みを提供し、単一モデルの性能向上を上回る精度を達成した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月8日 07:16
AI深層分析
キーポイント
リアルタイム協調による課題解決
既存のマルチエージェントシステムはタスク中の中継調整が苦手だが、AgentRadio は非同期メッセージ層により実行ステップ間の通信を実現し、中間修正を可能にする。
ベンチマークにおける性能向上
生産環境のリポジトリを対象とした SWE-Atlas QnA ベンチマークで、独立して動作する 4 つの Claude Code エージェントが AgentRadio を使用することで、タスク精度がほぼ倍増した。
単一エージェントの限界と代替案
コンテキスト拡大に伴う計画修正困難や証拠の伝播不全といった「カバレッジ問題」により単一エージェントは破綻するが、分散型アプローチが有効な解決策となる。
モデル規模より協調構造の重要性
実験結果は、計算資源やモデルスケールの向上よりも、適切な協調構造を設計することが長期的で複雑なコーディングタスクにおいて性能を決定づけることを示している。
依存関係のあるタスクにはリアルタイム協調が必要
コードベースの理解はサブタスクが相互に依存しているため、非同期通信やラウンド同期では不十分で、エージェント間の即時な調整と発見の共有が不可欠である。
重要な引用
most multi-agent systems are not designed for agents to coordinate among themselves mid-task and in real time
a team of agents powered by AgentRadio nearly doubled task accuracy for four Claude Code agents working independently
the right coordination structure can outmatch raw compute and model scale
"If that information waits until both agents finish, the storage investigation may complete along the wrong path,"
編集コメントを表示
編集コメント
複雑なコードベースの解析において、単一の強力なモデルに頼る従来のアプローチの限界を浮き彫りにする結果である。技術的な進歩は計算資源の投入だけでなく、エージェント間の連携メカニズムというアーキテクチャレベルでの革新によってさらに加速すると考えられる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
エンタープライズ規模のコードベースが巨大化する中、それらを分析する AI エージェントは、複数の対話やツール呼び出しを必要とする長期タスクの重みに耐えられなくなっています。作業をエージェントチーム間で分担するのは明らかな解決策のように思えますが、そこには致命的な欠陥があります。現在のマルチエージェントシステムの多くは、タスク実行中やリアルタイムでエージェント同士が協調して動作することを前提として設計されていないのです。
この課題に対処するため、Coral AI Labs と複数の大学からなる研究チームは「AgentRadio」を発表しました。これは、エージェントがメインの作業を中断することなく、実行ステップの間で通信できる非同期メッセージ伝送層です。サブタスク間の依存関係が極めて高い実世界のエンタープライズアプリケーションにおいて、このアーキテクチャにより、エージェントは行き止まりの経路を正式なレビューフェーズまで突き進むのではなく、進行中に軌道修正を行うことが可能になります。
本番環境のレポジトリに対する長期ホライゾンの質問に関するベンチマークでは、AgentRadio を搭載したエージェントチームが、独立して動作する 4 つの Claude Code エージェントのタスク精度をほぼ倍増させました。また、より高度なモデルで単独で動作するエージェントたちをも凌駕しました。AI プラクティショナーにとって、AgentRadio は適切な協調構造が、計算資源やモデル規模そのものよりも優れた成果を生み出すことを示しています。
コードベース理解の課題
LLM ベースのエージェントは、さまざまなツールや環境と相互作用しながら長期にわたるタスクを処理する能力が徐々に高まっています。コードベースの理解はその中でも特に過酷な課題の一つです。AI エージェントには、ソフトウェアの構築から実行、複数ファイルにまたがる実行経路の追跡、そして長期間にわたる証拠の統合までが求められます。
こうした条件下では、「カバレッジ問題」によって単一エージェントシステムは通常機能しなくなります。
「単一のエージェントはリポジトリ内を一つのシリアルパスでしか移動できません」と、Agent Radio 論文の共著者である Xinxing Ren 氏、Caelum Forder 氏、Peter Carroll 氏は VentureBeat に説明しています。コンテキストが膨らむにつれて「初期の計画を見直すのが難しくなり、調査の後半で見つかった発見が必ずしも反映されない」という問題が生じます。モデルは個々のステップを実行することはできますが、「難しいのは、長い調査期間中、すべての義務や依存関係、矛盾する証拠を常にアクティブな状態に保ち続けることです」。
大規模コードベースにおける AI の性能を測定するためのベンチマークの一つに SWE-Atlas QnA があります。これは、実際の運用環境にあるリポジトリに対して、長期にわたる自然言語の質問に答えるタスクで構成されています。単にコードを検索するだけでは解決できず、AI エージェントはソフトウェアを実行し、複数のコマンドを走らせて答えを見つけ出す必要があります。
研究チームの実験によると、Opus 4.6 で動作する単一の Claude Code インスタンスでは、これらのタスクの解決率はわずか 32.3% に留まります。より新しい高度なモデルである Opus 4.8 にアップグレードしても、成功率は 57.2% に過ぎません。
自然な解決策として、作業負荷を複数のエージェントに分散し、それぞれがより小さくクリーンなコンテキストで作業できるようにすることが挙げられます。タスクが明確に分解可能であり、個別に処理した後に結果を統合できる場合、マルチエージェント・ソリューションは大きな性能向上をもたらす可能性があります。
しかし、コードベースの理解というタスクは、通常のように明確に分解できるものではありません。サブタスク同士は高い相互依存性を有しています。あるエージェントが重要な設定ファイルを見つけたりバグを発見したりすれば、それが他のエージェントの探索経路を根本から書き換えたり方向転換させたりする可能性があります。こうした依存関係のため、エージェントたちはリアルタイムで調整し、交渉し、中間的な発見を共有する必要があります。
この必要性にもかかわらず、非同期型のマルチエージェント間通信は依然として稀です。研究者らは、既存のマルチエージェントシステムが一般的に以下の3つの欠陥のあるパターンに分類されると指摘しています。
並列だが孤立している:エージェントたちは同時に動作するものの、全くコミュニケーションを行わない。
並行処理だがラウンド同期型:エージェントは通信可能ですが、厳密に同期されたラウンドの境界でのみ可能です。これにより、各エージェントは次のラウンドで議論したり中間結果を交換したりする前に、互いの完了を待って作業を停止する必要があります。ラウンドベースのシステムでは、「重要な発見は次の通信フェーズまで待てる」という前提が置かれていますが、これは生きているシステムの相互依存部分に取り組んでいる場合、非常にコストの高い仮定です。例えば、API の症状を調査しているエージェントが、ストレージ担当エージェントの現在の仮説を無効にする証拠を発見した場合でも、「その情報が両方のエージェントの完了まで待たれると、ストレージ調査は誤った経路で完了してしまう可能性がある」と研究者らは指摘しています。
隣接する形式における非同期性:これらのシステムには、トップダウンタスクの割り当てなど限定的な非同期機能は備わっていますが、エージェント間のピアツーピアの横方向チャネルや、エージェントが作業を積極的に一時停止して更新を読み取る必要がある共有メモリはありません。
論文で研究者らは、現在のマルチエージェントシステムの主要なボトルネックは「作業中のエージェントは同時に聴くこともできない」という点にあると指摘しています。
「我々の知る限り、既存のシステムには、横方向の自然言語チャネルを通じて、並行して動作するエージェントが相互に受動的に意識できるものは存在しない」と研究者らは記述しています。
AgentRadio の仕組み
研究チームは、作業と待機を両立させるために「AgentRadio」という非同期メッセージ伝送層を開発しました。これは既存のコーディングエージェント用フレームワークに直接組み込めるように設計されています。
AgentRadio はエージェントに 3 つの基本機能(プリミティブ)を提供します。
1つ目は create_thread です。これにより、参加するエージェント間で会話スレッドが開始されます。
2つ目は send_message です。この機能はメッセージをスレッドに追加しますが、送信元の処理をブロックせずに即座に返却します。
3つ目は wait_for_mention です。呼び出し元の名前が含まれるメッセージが届くまでプロセスを待機させます。メッセージの到着と同時に、すべてのスレッドを含む完全なコンテキストのスナップショットが提供されるため、エージェントは瞬時に状況を把握できます。
この 3 つの機能により、エージェントは「受動的な意識」という状態を実現します。つまり、主要なタスクを継続しながら、背景でメッセージの送受信や知識の更新を行えるようになります。
AgentRadio のコードは GitHub で Apache 2.0 ライセンスの下に公開されています。軽量設計となっており、Claude Code や Codex CLI などの基盤となるエージェントフレームワークへの直接修正は一切不要です。
このアーキテクチャは主に以下の 2 つの部分で構成されます。
- メッセージサーバー:グループ内の全エージェントのアクティブなスレッド、メッセージ、メンションを保存する中央ハブとして機能する独立したプロセスです。
- ハーネス側の統合:各プリミティブに対応するシンプルなシェルスクリプト 3 つを用いて、エージェントがサーバーと通信します。
このシステムが動作するための唯一の厳格な要件は、エージェント・ハーネスがシェルコマンドをバックグラウンドタスクとして実行できることです。エージェントにはシステムプロンプトで、ウォッチャーを一つ常駐させ、提供されたスクリプトを通じてメッセージを送信するよう指示されています。
wait_for_mention スクリプトをバックグラウンドで実行することで、エージェントは作業を継続しつつ、非同期に通知を受け取ることができます。
既存のスタックにこれを統合するには、チームは依然として「ワーカーを開始し、アイデンティティを割り当て、共有サーバーに接続し、最終的な合成を管理する『薄いアダプター』」が必要です。研究者たちは、この作業はコーディングエージェントの周囲に位置づけられ、基盤となるモデルの変更を必要としないのだと述べています。
AgentRadio の実働
AgentRadio の実世界での有用性を検証するため、研究者らは SWE-Atlas QnA ベンチマークから 124 のタスクを対象にフレームワークをテストしました。テスト対象にはシステム設計、根本原因分析、セキュリティ、API 統合などのドメインが含まれます。
バックボーンモデルとして Claude Opus 4.6 と DeepSeek V4 Pro を使用し、ハーネスの評価では、単一の Claude Code エージェント(B0)から、古典的な役割分担を行うエージェントチーム(L1)、そして AgentRadio を用いて非同期で協調するエージェントチーム(L3)まで、さまざまな構成を評価しました。
実験結果により、AgentRadio の通信アーキテクチャが、単純なマルチエージェント設定や計算資源の単純な拡張よりも優れていることが示されました。
単体の Claude Code エージェント(Opus 4.6)がタスクを解決できたのは 32.3% に過ぎなかったのに対し、AgentRadio を組み合わせたフルセットではその数値がほぼ倍の 62.1% に達し、単体で動作する Opus 4.8 の 57.2% も上回りました。また、DeepSeek V4 Pro の結果も 29.0% から 50.8% へと大幅に引き上げられています。
これが実務における AI にどう影響するかを理解するために、論文では MinIO システムを扱う実際のタスクが紹介されています。このタスクを解決するにはリクエストごとのサーバーログを確認する必要がありましたが、これはエージェントたちが初期の計画段階で想定していなかった要件でした。
非同期通信を持たない L2 設定では、複数のエージェントが協力しながらも互いに情報を共有できません。あるコマンドを実行している最中に 2 つのエージェントが独立して「このログが必要だ」と気づいたものの、実行中にその発見を共有することができませんでした。結果として一方のエージェントは諦め、もう一方はチームに提案することなく失敗しました。レビュー段階ではチーム全員が誤った回答で一致し、5 つの基準項目を見逃すことになりました。
AgentRadio を有効化すると、エージェントたちは同じく実行中にその発見をしましたが、片方が即座に必要なサーバー側のログ証拠を共有ワークログへブロードキャストしました。他のエージェントは受動的に聴取していたため、この新たな証拠を瞬時に吸収します。こうしたリアルタイムの連携により、失敗するはずだったスコアが満点の 16/16 に劇的に変化したのです。
「決定的な違いはタイミングです」と研究者たちは指摘します。このチームが必要としたのは、別のエージェントや追加のレビューラウンドではありませんでした。必要だったのは、あるエージェントが得た発見を、その実用価値が失われる前に適切な関係者に届けることでした。
研究者らは、同様のパターンが企業のインシデント対応現場でも見られると指摘しています。例えば、API の症状を検査しているエージェントが、ストレージ担当エージェントの現在の仮説を否定する証拠を発見した場合、その情報が両方のエージェントの作業完了まで待たされると、ストレージ側の調査は誤った経路で完了してしまう可能性があります。「受動的な共有(passive awareness)があれば、2 番目のエージェントは進行中のコマンドを中断することなく、次の作業ステップで矛盾点を即座に反映できます」と研究者たちは説明しています。
コーディネーションのコストと複雑さ
AgentRadio は固定されたマルチエージェントチームの予算を必要とし、結果としてトークンコストが本質的に増大します。研究者らはこの「税」は現実のものであると認め、1 つの Opus エージェントの場合のタスクあたりの平均 API 使用料が 2.96 ドルだったものが、AgentRadio のフルスタックでは 19.45 ドルに上昇したと報告しています。
しかし、単なる規模の拡大がそのまま性能向上につながるわけではありません。研究者たちはテストを計算コストでマッチングさせるため、6 回の独立した Opus の実行に合計 17.76 ドルを費やしました。その結果、モデルはタスクの 37.9% しか解決できず、一方 AgentRadio は 62.1% を達成しています。これは、AgentRadio のアーキテクチャが単なる力押しによる勝利ではなく、構造的な優位性を持っていることを示唆しています。
ただし、チームはエージェント間の入れ替わり(churn)にも注意を払う必要があります。「通信はエージェントをより良い証拠へと導く一方で、有効な経路から逸れさせる可能性もある」と研究者たちは警告しています。
固定されたマルチエージェント・チームが、あらゆるエンジニアリングタスクに対するデフォルトの回答になってはいけません。マルチエージェント構成が必要かどうかを判断する上で有用なのは、そのタスクに「責任の分岐点(responsibility breakpoints)」が含まれているかという点です。これは、「有能なエンジニアが別の人の関与が必要だと考える場所」であり、具体的には作業が所有権の境界を跨ぐ場合や、独立した仮説を必要とする場合、あるいは十分なリスクがあるため別々の検証を行う必要がある場合に該当します。
研究者たちは次のように述べています。「タスクが分解可能で、その結果生じる部分が相互依存関係にあり、単一エージェントでの成功率が不安定であり、不完全な回答が重大な下流コストを伴う場合、調整(coordination)は非常に有効です。」具体的な例としては、リポジトリ全体のアーキテクチャに関する質問、見慣れないレガシーシステム、サービス間のインシデント調査、セキュリティ分析、依存関係の移行、そしてマルチモジュールのリファクタリングなどが挙げられます。
逆に、単一のエージェントの方が、「範囲が限定され、局所的で、元に戻せる作業」にはよりクリーンな選択肢となります。具体的には、既知の 1 ファイルの変更や、定型コードの生成などが該当します。
研究者たちはこう述べています。「問題の所有権を明確に保てる限りは、単一のエージェントを使用すべきです。既存のエージェントが証拠を圧縮せざるを得なくなったり、独立した所有権の境界を越えたり、あるいは自らの高影響力のある結論を検証する必要が生じたりする局面で、初めて別の責任(エージェント)を導入すべきでしょう」。
研究から商用化へ:Coral Code
AgentRadio は固定された 4 エージェントチームと 5 フェーズのプロトコルを用いた制御された研究実装ですが、その根底にある原理は「Coral Code」という商用製品へと適応されています。
Coral Code では、すべてのチケットに対して硬直的なマルチエージェント・プロトコルを適用するのではなく、ボトムアップでアプローチします。エンジニアは既存のコーディングエージェントから始め、新たな証拠がそれを正当化する局面においてのみ、リポジトリ全体の調査、専門的な責任分担、およびコミュニケーション機能が Coral によって導入されます。
研究者たちは「Coral は、エンジニアがすでに使用しているツールを取り巻く運用上の課題をパッケージ化します。ハーン(実行基盤)の内部ではなく、その周囲にリポジトリの文脈、スコープ限定の専門家、通信機能、そして証拠層を提供するのです」と説明しています。
この動的なアプローチは、コスト最適化を実現します。つまり、コストがかかるのは「完了し、レビュー可能な成果物」を生成するための単位のみです。
自律型ソフトウェアエンジニアリングの未来
AgentRadio はエージェントのオーケストレーションにおいて大きな進歩をもたらしましたが、依然として克服すべき課題が残っています。研究者らが指摘した主要なボトルネックの一つは「アテンションガバナンスと検証」です。
「パッシブ・アウェアネス(受動的意識)は実行中に通信を可能にしますが、どのエージェントが存在すべきか、どの発見が中断に値するか、誰がその通知を受け取るべきか、あるいは証拠が計画の修正に十分であるかを判断するものではありません」と研究者らは述べています。すべてのエージェントがすべての更新情報を受け取れば、通信層はノイズと化してしまいます。複数のエージェントが同じ誤った前提を共有している場合、より速い通信はそのエラーを広めることになりかねません。
例えば、論文に含まれる Grafana プラットフォームに関するケーススタディの一つでは、9 つの評価基準のうち 4 つで否定的な結論が必要でした。具体的には、「データソースピッカーが自動的に選択されていない」という観察結果です。エージェントは関連するテストを実行しましたが、欠落していた否定的な仮説を形成した者はいませんでした。その結果、両方の構成が 4 つの評価基準に不合格となりました。
「パッシブ・アウェアネスは、誰かが開発したアイデアを広めることはできます。しかし、チームのどこにも現れていない概念を提供することはできません」と研究者らは指摘しています。
タスクの持続時間が長くなるほど、コミュニケーションと調整が重要になります。研究者たちは「次世代のシステムには、適応的な責任分担、証拠に基づくルーティング、競合解決、明確なコスト制限、権限管理、回復機能、そして明確な人間によるエスカレーションポイントが必要だ」と指摘しています。最も重要なのは、永続的な出所情報の維持です。これにより、エンジニアリングリーダーはどのエージェントが主張を行ったか、なぜその行動が承認されたかを検証できるようになります。
「実行時間が長いエージェントほど、コミュニケーションの重要性が高まります。また、責任の所在を偽装することがより困難になる」と研究者たちは述べています。
原文を表示
As enterprise codebases grow, AI agents tasked with analyzing them are buckling under the weight of long-horizon tasks that require multiple interactions and tool calls. Dividing the work among a team of agents seems like the obvious fix, but it introduces a fatal flaw: most multi-agent systems are not designed for agents to coordinate among themselves mid-task and in real time.
To solve this, researchers at Coral AI Labs and multiple universities introduced AgentRadio, an asynchronous message-passing layer that allows agents to communicate between their execution steps without interrupting their main work. In real-world enterprise applications where subtasks are highly interdependent, this architecture enables agents to make mid-course corrections rather than continue on dead-end paths until a formal review phase.
On a benchmark of long-horizon questions over production repositories, a team of agents powered by AgentRadio nearly doubled task accuracy for four Claude Code agents working independently. It also outmatched single agents running on more advanced models. For AI practitioners, AgentRadio shows that the right coordination structure can outmatch raw compute and model scale.
The challenge of codebase understanding
LLM-based agents are increasingly capable of handling long-horizon tasks that require interacting with different tools and environments. Codebase understanding represents an extreme version of this challenge. It requires an AI agent to build the software, execute it, trace execution paths across multiple files, and synthesize evidence over extended periods.
Under these conditions, single-agent systems usually break down because of a “coverage problem.”
"A single agent follows one serial path through the repository," Xinxing Ren, Caelum Forder, and Peter Carroll, co-authors of the AgentRadio paper, explained to VentureBeat. As its context grows, "the initial plan becomes harder to revise and discoveries made late in the investigation do not always propagate." The model can usually execute individual steps, but "the hard part is keeping every obligation, dependency, and piece of contradictory evidence active across a long investigation."
One benchmark that helps measure AI performance on large codebases is SWE-Atlas QnA. This benchmark consists of long-horizon, natural-language questions over live production repositories. The tasks can’t be solved by just exploring the code. AI agents must run the software and execute multiple commands to find the answers.
According to the research team’s experiments, a single Claude Code instance running on Opus 4.6 resolves just 32.3% of these tasks. Upgrading to a newer, more advanced model like Opus 4.8 only yields a 57.2% success rate.
A natural remedy is to distribute the workload across multiple agents, allowing each to work with a smaller, cleaner context. Multi-agent solutions can provide substantial performance gains when tasks are cleanly decomposable, meaning they can be solved separately and merged at the end.
Codebase understanding, however, is rarely cleanly decomposable. The subtasks are highly interdependent. A critical configuration file or a bug uncovered by one agent can completely rewrite or redirect the entire exploration path of another agent. Because of these dependencies, agents must coordinate, negotiate, and share intermediate discoveries in real time.
Despite this need, asynchronous multi-agent communication is rare. The researchers point out that existing multi-agent systems generally fall into three flawed patterns:
Parallel but isolated: Agents operate simultaneously but do not communicate at all.
Parallel but round-synchronized: Agents can communicate, but only at strict, synchronized round boundaries. This forces agents to stop and wait for one another to finish a round before they can debate or exchange intermediate findings. Round-based systems assume that important discoveries can wait until the next communication phase, which is an expensive assumption when agents are working on interdependent parts of a live system. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. "If that information waits until both agents finish, the storage investigation may complete along the wrong path," the researchers said.
Asynchrony in adjacent forms: These systems offer limited asynchronous features, such as top-down task dispatching. They don’t have peer-to-peer lateral channels between agents or shared memories that require an agent to actively pause its work to read updates.
In their paper, the researchers point out that the main bottleneck hindering current multi-agent systems is that “an agent that is working cannot also be listening.”
“To our knowledge, no existing system gives concurrently working agents passive awareness of one another over a lateral, natural-language channel,” the researchers write.
How AgentRadio works
To dissolve the mutual exclusion between working and listening, the researchers developed AgentRadio, an asynchronous message-passing layer designed to plug directly into existing coding-agent harnesses.
AgentRadio equips agents with three primitives:
The create_thread primitive opens a conversation between participating agents.
The send_message primitive appends a message to a thread and returns without blocking the sending agent.
The wait_for_mention primitive blocks the process until a message mentioning the caller arrives. It delivers the message along with a full snapshot of all threads so the agent has instant context.
This trio enables agents to have a state of “passive awareness,” where they can continue their primary tasks while passing messages and updating their knowledge in the background.
AgentRadio's code is available under the Apache 2.0 license on GitHub. It is designed to be lightweight, requiring no direct modifications to the underlying agent harnesses like Claude Code or Codex CLI.
The architecture consists of two main parts:
The message server: A standalone process that acts as the central hub, storing all active threads, messages, and mentions for the group of agents.
Harness-side integration: Agents interact with the server using three simple shell scripts, one corresponding to each primitive.
The only strict requirement for the system to work is that the agent harness must be able to run a shell command as a background task. The agents are instructed in their system prompts to keep one watcher running and to send messages through the provided scripts. Running the wait_for_mention script in the background allows the agent to continue its work and receive notifications asynchronously.
To integrate this into an existing stack, a team still needs a "thin adapter that starts the workers, assigns identities, connects them to the shared server, and manages final synthesis," the researchers said. That work sits around the coding agent rather than requiring changes to the underlying model.
AgentRadio in action
To validate the real-world utility of AgentRadio, the researchers tested the framework on 124 tasks from the SWE-Atlas QnA benchmark. The tests covered domains including system design, root-cause analysis, security, and API integration.
The researchers used Claude Opus 4.6 and DeepSeek V4 Pro as the backbone models. For the harness, they evaluated configurations ranging from a single Claude Code agent (B0) to a team of agents with classic division of labor (L1), up to a team of agents using AgentRadio to coordinate asynchronously (L3).
The experimental results showed that the AgentRadio communication architecture outperforms both naive multi-agent setups and raw compute scaling.
While a single Claude Code agent with Opus 4.6 resolved only 32.3% of the tasks, the full AgentRadio setup nearly doubled that metric, resolving 62.1% of the tasks, and surpassed the single agent running on Opus 4.8, which hit 57.2%. It also boosted the DeepSeek V4 Pro results from 29.0% to 50.8%.
To understand how this practically impacts enterprise AI, the paper highlights a real-world task involving a MinIO system. Solving the task required checking per-request server logs, a requirement the agents did not anticipate during their initial planning phase.
In the L2 setting, where agents collaborate but lack asynchronous communications, two agents independently realized they needed these logs while executing commands. Because they could not share this finding mid-execution, one agent gave up privately and the other failed to propose it to the team. During the review phase, the team unanimously agreed on the wrong answer, missing five rubrics.
With AgentRadio activated, the agents made the same mid-execution discovery, but one agent instantly broadcasted the required server-side log evidence to the shared worklog. Because the other agents were passively listening, they absorbed this new evidence immediately. This real-time coordination transformed a failing score into a perfect 16 out of 16.
"The useful distinction is timing," the researchers said. "The team did not need another agent or another review round. It needed one agent's discovery to reach the right peers before its operational value expired."
The researchers note that the same pattern appears in enterprise incident work. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. If that information waits until both agents finish, the storage investigation may complete along the wrong path. “Passive awareness lets the second agent incorporate the contradiction at its next work step without interrupting a command already in progress,” they said.
The cost and complexity of coordination
AgentRadio requires a fixed multi-agent team budget, which inherently multiplies the token cost. The researchers acknowledge that the "tax is real," noting that average API spend rose from $2.96 per task for one Opus agent to $19.45 for the full AgentRadio stack.
However, raw scale does not equal performance. When researchers compute-matched the test by spending $17.76 on six independent Opus runs, the models only resolved 37.9% of tasks, compared with 62.1% for AgentRadio. This suggests that AgentRadio's architecture is a structural win, not just a brute-force scale win. Teams should still be aware of inter-agent churn. "Communication can redirect an agent toward better evidence, and it can also distract an agent from a valid path," the researchers warned.
A fixed multi-agent team should not become the default response to every engineering task. The more useful test to determine if a multi-agent setup is required is whether the task contains "responsibility breakpoints," the researchers said. These are places "where a competent engineer would involve another person because the work crosses an ownership boundary, needs an independent hypothesis, or carries enough risk to justify separate verification."
“Coordination is a strong fit when the task can be decomposed, the resulting parts remain interdependent, the single-agent success rate is unreliable, and an incomplete answer has a meaningful downstream cost,” the researchers said. Examples include repository-wide architecture questions, unfamiliar legacy systems, cross-service incident investigation, security analysis, dependency migrations, and multi-module refactors.
Conversely, a single agent remains the cleaner choice for “bounded, local, and reversible work,” such as a known one-file change or boilerplate generation.
“Use one agent while one context can still own the problem honestly,” the researchers said. “Introduce another responsibility when the existing agent would otherwise need to compress away evidence, cross an independent ownership boundary, or verify its own high-impact conclusion.”
From research to commercialization: Coral Code
While AgentRadio serves as a controlled research implementation using a fixed four-agent team and a five-phase protocol, the underlying principles are being adapted into a commercial product called Coral Code.
Instead of a rigid, multi-agent protocol applied to every ticket, Coral Code works from the bottom up. An engineer begins with their existing coding agent, and Coral introduces repository-scoped investigation, specialist responsibility, and communication only when the emerging evidence justifies it. "Coral packages the operational concerns around the tools engineers already use, providing the repository context, scoped specialists, communication, and evidence layer around the harness rather than inside it," the researchers said.
This dynamic approach optimizes costs by targeting the relevant unit: the cost of a completed, reviewable outcome.
The future of autonomous software engineering
While AgentRadio provides a major upgrade to agent orchestration, there are still hurdles to overcome. One major bottleneck that the researchers pointed out to is “attention governance and verification.”
“Passive awareness makes communication available during execution. It does not decide which agents should exist, which discovery deserves an interruption, who should receive it, or when the evidence is strong enough to revise the plan,” the researchers said. If every agent receives every update, the communication layer becomes noise. If several agents share the same bad assumption, faster communication can spread the error.
For example, in one of the case studies in the paper that involved the Grafana platform, four of nine rubrics required negative conclusions, such as observing that a datasource picker did not select automatically. The agents ran the relevant tests, yet none formed the missing negative hypothesis. Both configurations failed the four rubrics.
“Passive awareness can distribute an idea that somebody develops. It cannot supply a conception that never appears anywhere in the team,” the researchers said.
As task durations stretch longer, communication and coordination become critical. "The next generation of systems… needs adaptive responsibility assignment, evidence-aware routing, conflict resolution, explicit cost limits, permissions, recovery, and clear human escalation points," the researchers note. Most importantly, it requires durable provenance so engineering leads can inspect which agent made a claim and why an action was accepted.
"Longer-running agents make communication more important. They also make accountability much harder to fake," they said.
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み