Compute Allocation in Multi-Agent Teams

In multi-agent design, decide the stage and the model for additional inference compute before you decide the number of agents. In the same lead-worker harness on ProgramBench, the reward per added dollar was about 2.7 times higher for a Sol team that delegated only planning. The comparison is with a Sol team that delegated all stages (3.8 vs. 1.4).

There have been two main ways to spend more inference compute on a coding agent. One lets the agent think longer, and the other lets it try more times. A team of agents is a third way, in which several agents divide one attempt. Inference-time compute scaling for a single agent is covered in Test-Time Compute Scaling.

A study from October 2026 formulates team design as a compute allocation problem. Teams made only of strong models got a higher reward than solo agents but cost three to seven times as much. The size of the gain depended on the stage and the model that received the additional compute.

Research on task decomposability and on failure attribution adds to this result. Together, they give three conditions to check before you build a team. The conditions are task decomposability, the stage to delegate, and the traceability of failures.

The Stage That Receives Additional Compute

Samway et al. (arXiv:2610.17471, 2026-10) built a minimal harness in which a lead agent delegates subtasks to worker agents. Each worker sees only its assigned subtask, not the full task description or the conversations of other workers. To isolate the effect of each stage, the lead prompt limits delegation to one stage or allows all three. The stages are planning (P), implementation (I), and verification (V), and all three together are PIV.

The benchmark is ProgramBench, with 200 tasks. The agent gets an empty workspace, a black-box reference executable, and behavior documentation, and it builds a compatible program from scratch. The main experiments use three tiers of GPT-5.6, named Sol, Terra, and Luna in the paper, at medium reasoning effort. Each result is the mean of three runs.

The efficiency η is the reward gain over the solo agent divided by the cost increase over the solo agent. The paper reports η in reward points per $100 of added cost, and one reward point is 0.01 of reward.

The paper describes this cost only with the term "total inference cost" and gives no other detail. Multiply the cost per task in the table below by the 200 tasks. The reported η values then match (planning: 5.7 points ÷ $148 added × 100 ≈ 3.8). This cost basis is an estimate that comes from this calculation.

The table below shows the results for a Sol lead with blocking scheduling. In blocking scheduling, the lead waits until a worker completes its work.

Reward is the three-run mean from Table 3 of the paper, and cost is the mean inference cost per task from Table 4. The team that delegated only planning to Sol workers got the same reward as the team that delegated all stages (0.634 vs. 0.631). Its cost was about half. The η was 3.8 for planning, at most 2.4 for implementation and verification, and 1.4 for all stages.

The authors explain this difference with the task structure. ProgramBench gives the target program only as a black box, so the agent must probe it to find the interface, edge cases, and outputs. Planning workers divide this probing in parallel, and the lead receives their reports and then implements and verifies the code itself.

flowchart LR
    L["Lead<br/>decomposes task"] --> W1["Planning worker 1<br/>probes reference executable"]
    L --> W2["Planning worker 2<br/>probes reference executable"]
    L --> WN["Planning worker N<br/>probes reference executable"]
    W1 --> R["Lead<br/>combines reports"]
    W2 --> R
    WN --> R
    R --> I["Lead<br/>implements code"]
    I --> V["Lead<br/>verifies code"]

Under PIV guidance, the lead continued to delegate after the first source edit. As a result, PIV issued about 2.4 times as many delegation calls as planning guidance, but the reward did not increase. The authors conclude that additional compute gave the most value before any code was written.

Where Cheap Workers Belong

When the workers change to the cheaper Luna model, the difference between stages becomes larger. At the token prices in the paper, Luna costs 1/20 of Sol for input and about 1/17 for output. Luna planning workers raised reward by 2.4 points at almost the same cost as the solo agent. Their η was 51.0, about 13 times that of Sol planning workers (3.8).

Luna implementation workers increased cost and lowered reward below the solo agent, so their η was −12.0. Luna verification workers left reward almost unchanged. The authors give this interpretation. Cheap workers help when they collect information for a strong lead. They do not help when they produce code that the lead must integrate.

In asynchronous scheduling, the lead continues its own work while the workers run. With this scheduling, one team had a Sol lead and Luna planning workers. This team got 47.5% of the reward gain over the Sol solo agent (PIV guidance) that an all-Sol planning team got. Its added cost was 13.9% of the added cost of the all-Sol planning team.

The lead sets the upper limit of reward. With the workers fixed at Luna, a change of the lead from Luna to Terra raised reward by 20.9%. A change from Terra to Sol raised it by a further 15.4%. A team of a Terra lead and Luna workers was 10.3% below a Sol solo agent.

An experiment with a fixed number of workers (a Sol lead with 2, 4, 8, or 16 Luna workers, single run) shows the same asymmetry. Planning workers raised reward at every team size, to 3.2% above the solo agent with 2 workers and 7.1% with 16. Implementation and verification workers improved up to 4 workers and then stopped. From 4 to 16 workers, the change was −1.5 points and −1.1 points, and the 95% confidence intervals include zero.

The authors explain this difference with the amount of information that workers return. Each planning worker runs the reference executable about seven times regardless of team size, so the lead receives more information as the team grows. More implementation workers divide a fixed plan into smaller parts. Each assignment shrinks from 1.4k to 0.4k characters, and the share of source edits by Luna workers rises from 54% to 85%.

A team with 16 Luna planning workers came within 1.4 points of an all-Sol team whose lead set the team size, at 70% lower cost. This result came from putting the additional compute into cheap workers at the planning stage.

Tasks That Can and Cannot Be Divided

The gain from planning workers came from probing that could be divided into independent parts. Kim et al. (arXiv:2512.08296, v3 2026-04) compare this condition at the task level. They used 260 configurations with 6 benchmarks, 5 architectures, and 3 LLM families. In all configurations, they matched tools, prompts, and total reasoning tokens (a mean of 4,800 per trial).

On the financial analysis task, the centralized architecture was 80.8% higher than the single agent in relative terms. On PlanCraft, a sequential planning task, all multi-agent architectures declined, and the independent architecture had the largest decline at 70.0%.

The paper explains the difference between Finance-Agent and PlanCraft with token use inside a fixed budget. On decomposable tasks, each agent completes its local reasoning and uses the remaining budget to exchange partial results. On tasks with strong sequential dependencies, constraint checks and state tracking use most of the budget, and the messages that follow lower reasoning quality.

The domain complexity scores of the two tasks were similar, 0.41 for Finance-Agent and 0.42 for PlanCraft. The paper names task decomposability, rather than complexity, as the factor that separated the results.

On SWE-bench Verified, a coding task tested on a 20-problem subset, all multi-agent architectures were below the single agent (−2.1% to −14.9%). The paper classifies this task as decomposable with a low domain complexity (0.255) and explains the decline with capability saturation. Most models already exceed about 45% as a single agent, so coordination has little room to add.

Coordination overhead and error amplification by architecture are covered in Evaluating Multi-Agent Systems and Choosing an Orchestration Topology.

A comparison with matched thinking-token budgets points in the same direction. Tran and Kiela (arXiv:2604.02460, 2026-04) used four models on multi-hop question answering (FRAMES, MuSiQue).

This study compared a single agent with five multi-agent architectures at the same budget. At a budget of 1,000 tokens, the mean accuracy was 0.418 for the single agent and 0.379 for the sequential multi-agent system. The single agent was the best or statistically indistinguishable from the best at every budget except 100 tokens.

The authors explain this with the data processing inequality. The messages that other agents receive are made from the original context, so they cannot add information about the answer. This argument assumes full use of the context, and the authors also expect multi-agent systems to become competitive when context use degrades.

When you put the three results together, they point to one condition for a gain from additional agents. A gain occurs when workers bring information that is not in the lead's context. When workers only divide information that already exists, only the coordination cost increases. This is a judgment.

Can You Trace a Failure

A team with a good compute allocation can still fail, and then you must find the cause. Failure attribution is the problem of finding the responsible agent and the decisive step in the log of a failed run. The decisive step is the earliest step whose correction changes the final output to the expected output.

The shared benchmark, Who&When, contains 184 failure logs from 127 multi-agent systems, with human labels for the responsible agent and the decisive step. Algorithm-generated logs (CaptainAgent teams) are short, with at most 10 steps. Hand-crafted logs (Magentic-One) are longer, with a mean of 28.8 LLM calls (as counted by TraceElephant).

The baseline numbers from the original paper are in Judging Multi-Agent Adoption on Reliability. Methods published in 2026 identify the responsible agent in the 70% range, but their accuracy for the decisive step is much lower.

Values are percentages, and "Answer given" means that the attribution method also received the correct answer to the task. In the same-backbone comparison, FALAT (arXiv:2606.00765, 2026-05) reached a best responsible-agent accuracy of 73.0%. CHIEF (arXiv:2602.23701, 2026-02) reported 77.59% when it received the answer.

Decisive-step accuracy was at most 52.00%, even on short logs. On the longer hand-crafted logs, the methods in the table stayed near 30%. FAMAS, which uses repeated replays, has a reported value of 41.38% on hand-crafted logs (answer given, CHIEF Table 1).

Evaluation conditions also change the numbers by a large amount. The CHIEF paper reported 29.31% step accuracy on hand-crafted logs. FALAT ran CHIEF again with a backbone of the same name, DeepSeek V3.2, and got 10.3%. The step accuracy of FALAT on hand-crafted logs is 22.2% to 29.1% for an exact match and rises to 43.1% to 53.4% within ±5 steps.

What you record also changes attribution accuracy. TraceElephant (arXiv:2604.22708, 2026-04) collected 220 failure traces from three systems, and one of the three systems is a single-agent scaffold. It recorded the input context, metadata, and tool logs of each step.

With two attribution techniques that received the answer, step accuracy was 0.16 to 0.17 without input context and metadata, with only outputs (including tool logs) kept. With full traces, it was 0.28 to 0.30.

This result applies to how you record a delegation structure. In the ProgramBench harness, each worker sees only its subtask. Thus, to evaluate the decision of a worker, the assignment from the lead must stay in the log as input context. When you divide implementation among many cheap workers, the number of trajectories that can contain the decisive step also increases.

This connection is a judgment. A study that measures attribution accuracy directly on lead-worker coding teams was not found. Methods to set the scope of execution logs in production are covered in How Companies Operate Coding Agent Harnesses.

Conditions Under Which This Claim Does Not Hold

The best stage to delegate changes with the task. Commit0-Lite (16 Python libraries, one run per configuration) supplies a skeleton and unit tests. On this benchmark, implementation guidance was the most effective in 8 of 10 configurations, and planning was never clearly the best.

But Commit0-Lite has few tasks and is near saturation, because Sol got a perfect reward on 12 of 16 tasks. Thus, the paper treats this difference only as a directional result. The advantage of planning was observed on ProgramBench, where the agent must discover the specification.

If the lead model does not delegate, no allocation occurs. Minimal guidance is a prompt that lets the lead decide when and how to delegate. Under minimal guidance, a Claude Opus 4.7 lead spawned only 0.3 workers per task. That team was indistinguishable from the solo agent (+0.001 ± 0.022).

With PIV guidance, Opus 4.7 teams gained 0.043 to 0.063 in reward at 1.7 to 2.0 times the solo cost. Claude Haiku 4.5 teams delegated, but every configuration scored at or below the solo agent (−0.041 to −0.004) at about twice the cost. The two Claude results and the fixed-size experiment are single runs.

For GPT-5.6, the standard deviation of the 200-task mean across runs is at most 0.014. But the reward on a single task differs between runs by 0.057 to 0.113 on average. The team gain was generally largest on easy tasks and smaller on hard tasks, and only implementation guidance did worst on easy tasks.

A higher worker cap or a messaging tool did not add a gain. When the worker cap rose from 5 to 20, the reward changed by −1.6 to +1.6 points. Cost rose by 5% to 17% in 7 of 10 configurations.

The inter-agent messaging tool lets an agent send messages to all running agents. In Sol teams (PIV guidance), 84% of the messages went to the lead, and the reward did not change. Luna teams lost 4.4 to 7.1 points.

The denominator of η is the added cost, so a small reward difference gives a large value for Luna configurations with a small added cost. It is a judgment that a value such as 51.0 must be read together with the size of the reward gain. The prediction model of Kim et al. has a cross-validated R² of 0.373, or 0.413 with a task-grounded capability index. Thus, more than half of the performance variance stays unexplained.

Most failure attribution numbers come from logs of web research tasks such as GAIA and AssistantBench. The only coding logs in TraceElephant are 44 failure records of SWE-Agent on SWE-bench, and they are single-agent records. Their step accuracy was 29.6% (Static Agentic technique, answer given), similar to the web task systems (30.6%, 30.8%).

It is an estimate that step attribution is similarly difficult in the failure logs of lead-worker coding teams. None of the three lines of research measured compute allocation and failure traceability in one experiment.

Checks Before You Build a Team

When you turn the three conditions into practical checks, you get the five questions below. Before you answer them, build a single-agent baseline with the same task, the same tools, and the same total budget. Without a baseline, you cannot measure the gain or the cost of a team.

On Who&When (web task logs), the decisive-step accuracy of automatic attribution is near 50% even on short logs. Thus, use automatic attribution results to narrow the range that a person checks. This recommendation and the recommendations in the table are judgments derived from the evidence in the previous sections.

References

• Scaling Inference-Time Compute with Teams of Coding Agents, arXiv:2610.17471 (2026-10)
• Towards a Science of Scaling Agent Systems, arXiv:2512.08296 (2025-12, v3 2026-04)
• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv:2604.02460 (2026-04)
• FALAT: Tracing Failures in LLM Agent Trajectories via Dependency-Guided Search, arXiv:2606.00765 (2026-05)
• From Flat Logs to Causal Graphs: Hierarchical Failure Attribution for LLM-based Multi-Agent Systems, arXiv:2602.23701 (2026-02)
• Seeing the Whole Elephant: A Benchmark for Failure Attribution in LLM-based Multi-Agent Systems, arXiv:2604.22708 (2026-04)

Every figure was checked against each original paper as of 2026-10.

Summary

The gain from a multi-agent team depends more on the allocation of additional inference compute than on the number of agents. In homogeneous Sol teams on ProgramBench, delegation of only planning gave the same reward as delegation of all stages at about half the cost. A cheap model clearly raised reward only when it served as a planning worker. The contrast between financial analysis and sequential planning shows that this gain occurs when the task can be divided into independent parts.

The limits are also clear. The best stage to delegate changes with the task and the lead model. On Who&When (web task logs), automatic failure attribution identifies the decisive step only about half the time, even on short logs. Before you build a team, first prepare a single-agent baseline, a stage that produces new information, and execution logs that include inputs.