Researchers at Coral AI Labs and several universities introduced AgentRadio, an asynchronous message‑passing layer that gives concurrently working coding agents passive awareness of each other. The infrastructure lets agents continue their primary tasks while broadcasting and receiving intermediate findings, enabling mid‑course corrections in highly interdependent, long‑horizon codebase investigations. In benchmark tests on SWE‑Atlas QnA, an AgentRadio‑coordinated four‑agent team solved 62.1% of tasks — nearly double a single Claude Code Opus 4.6 instance and outperforming a single Opus 4.8 run.
The challenge: long‑horizon code understanding and the coverage problem
Large enterprise repositories force agents to perform extended workflows: build the software, run it, trace execution across multiple files, and synthesize evidence across multiple steps. Single LLM‑based agents often follow a serial investigative path that becomes hard to revise as context grows; late discoveries do not reliably propagate, producing what the researchers call a "coverage problem."
SWE‑Atlas QnA measures performance on long‑horizon, natural‑language questions over live production repositories. These tasks require running the software and executing multiple commands, not just reading code. In the research experiments, a single Claude Code instance on Opus 4.6 solved 32.3% of these tasks; upgrading to Opus 4.8 increased success to 57.2%.
Why naive multi‑agent patterns fail
A straightforward response is to split work across multiple agents to reduce individual context size, but codebase understanding rarely decomposes cleanly. Subtasks are interdependent: a configuration file or bug found by one agent can redirect another agent’s entire exploration. Existing multi‑agent systems typically fall into three problematic patterns:
- Parallel but isolated: agents run simultaneously without communicating.
- Parallel but round‑synchronized: agents only exchange information at strict synchronization boundaries, forcing them to stop and wait for a common communication round.
- Adjacent asynchrony: limited asynchronous features (like top‑down dispatch) exist, but no lateral peer‑to‑peer channel that provides passive, real‑time awareness.
The central bottleneck is that "an agent that is working cannot also be listening." No existing system provided, prior to this work, concurrently working agents passive awareness over a lateral, natural‑language channel.
How AgentRadio works
AgentRadio is an asynchronous messaging layer designed to plug into existing coding‑agent harnesses. It provides three primitives:
- create_thread: open a conversation among participating agents;
- send_message: append a message to a thread and return immediately without blocking;
- wait_for_mention: block until a message that mentions the caller arrives, and deliver that message with a full snapshot of all threads for context.
These primitives enable "passive awareness": agents keep executing primary tasks while sending messages and updating knowledge in the background. The AgentRadio implementation is lightweight, released under the Apache 2.0 license on GitHub, and does not require deep changes to underlying agent harnesses such as Claude Code or Codex CLI. The architecture has two components:
- A message server: a standalone process storing active threads, messages, and mentions for the agent group.
- Harness‑side integration: three simple shell scripts corresponding to the three primitives.
The main operational requirement is that the agent harness can run a shell command as a background task. Agents are instructed to keep a watcher running and send messages through the scripts; running wait_for_mention in the background allows them to receive notifications asynchronously.
To make this production‑ready, teams still need a thin adapter that starts workers, assigns identities, connects them to the shared server, and manages final synthesis — work that sits around the coding agent rather than inside the model.
AgentRadio in experiments
The researchers validated AgentRadio on 124 SWE‑Atlas QnA tasks across system design, root‑cause analysis, security, and API integration. Backbone models included Claude Opus 4.6 and DeepSeek V4 Pro. Harnesses tested ranged from a single Claude Code agent (B0) through classic labor division teams (L1) to an AgentRadio‑coordinated asynchronous team (L3).
Key experimental results:
- Single Claude Code (Opus 4.6): 32.3% solved.
- AgentRadio full setup: 62.1% solved (nearly double the 4.6 baseline).
- Single Opus 4.8: 57.2% solved.
- DeepSeek V4 Pro: from 29.0% standalone to 50.8% with AgentRadio.
These results indicate AgentRadio provides a structural performance improvement beyond brute‑force compute scaling.
A practical case: MinIO task
In a MinIO‑related task, per‑request server logs were required to solve the problem — an evidence type not anticipated during initial planning. In the L2 setting (collaborative but without asynchronous sharing), two agents independently discovered the need for those logs but could not share the finding mid‑execution; one agent abandoned the idea privately and the team missed five rubrics during review.
With AgentRadio, one agent broadcast the server‑side log evidence immediately to the shared worklog; passively listening peers incorporated that evidence in their next steps, turning a failing outcome into a perfect 16/16 score. The researchers emphasize this is a timing issue: the team needed the discovery to reach the right peers before its operational value expired.
Cost, tradeoffs, and when to use multi‑agent setups
AgentRadio requires a fixed multi‑agent budget and thus raises token/API costs: the researchers report average API spend increasing from $2.96 per task for one Opus agent to $19.45 for the full AgentRadio stack. However, matching compute by running multiple independent Opus runs (six runs costing $17.76) yielded only 37.9% solved, versus AgentRadio’s 62.1%, suggesting the benefit is structural rather than purely a cost‑for‑tokens effect.
Coordination also introduces potential churn: communication can guide an agent toward better evidence or distract it from a valid path. The authors recommend not defaulting to fixed multi‑agent teams for every engineering task. Instead, consider multi‑agent coordination when the task contains "responsibility breakpoints" — points where an engineer would involve another person because work crosses an ownership boundary, needs an independent hypothesis, or demands separate verification. Good candidates include repository‑wide architecture questions, unfamiliar legacy systems, cross‑service incident investigations, security analyses, dependency migrations, and multi‑module refactors. Single agents remain appropriate for bounded, local, reversible work like one‑file changes or boilerplate generation.
From research to product: Coral Code
While AgentRadio is presented as a controlled research implementation with a fixed four‑agent team and a five‑phase protocol, the team is adapting the principles into a commercial product called Coral Code. Rather than applying a rigid multi‑agent protocol to every ticket, Coral Code starts from an engineer’s existing coding agent and dynamically introduces repository‑scoped investigation, specialists, and communication when evidence justifies it, packaging coordination around familiar tools to optimize cost per completed, reviewable outcome.
Open problems and the path forward
Despite AgentRadio’s gains, several challenges remain. The authors call out "attention governance and verification": passive awareness enables communication during execution but does not decide which agents should exist, which discoveries merit interruption, who should receive updates, or when evidence is strong enough to revise a plan. If every agent receives every update, the channel becomes noisy; if several agents share a bad assumption, faster communication can spread the error.
Further needs include adaptive responsibility assignment, evidence‑aware routing, conflict resolution, explicit cost limits, permissions, recovery mechanisms, clear human escalation points, and durable provenance so engineering leads can inspect which agent made a claim and why it was accepted. Longer‑running agents increase the importance of communication and the difficulty of maintaining accountable provenance.
Conclusion
AgentRadio demonstrates that asynchronous, passive peer‑to‑peer awareness among concurrently working agents materially improves multi‑agent performance on long‑horizon codebase tasks. The approach yields substantial gains over both naive multi‑agent setups and single‑agent model scaling, but it also carries monetary and governance tradeoffs that teams must weigh when deciding whether to adopt a multi‑agent architecture. Coral Code aims to operationalize these ideas with a dynamic, cost‑aware product around production engineering workflows.
