PaperlayerView exact revision on arXiv

Source-linked AI summary

FutureWeaver: Planning Test-Time Compute for Multi-Agent Systems with Modularized Collaboration

Dongwon Jung, Peng Shi, Muhao Chen, Yi Zhang

arXiv:2512.11213v2cs.AIcs.CL

TL;DR

Multi-agent systems lack principled ways to allocate test-time compute across collaboration under fixed budgets. FutureWeaver combines reusable collaboration modules with short-horizon action selection and long-horizon lookahead; experiments report consistent improvements over baselines across benchmarks and budgets.

  • Problem

    Multi-agent test-time scaling lacks principled mechanisms to plan agent invocations and coordination steps under hard compute budgets.

    Source: §1 · pp. 1–2

  • Method

    FutureWeaver uses reusable collaboration modules induced through self-play reflection and a dual-level planner that couples next-action selection with abstract lookahead over feasible continuations.

    Source: §1 · p. 2, §3.1 · p. 4, §3.2 · p. 4

  • Results

    FutureWeaver consistently outperforms standard and test-time-scaling baselines, achieving higher accuracy and more efficient resource use across benchmarks and budgets.

    Source: §1 · p. 2, §4.2 · p. 8, §5 · p. 9

  • Takeaways & Limitations

    The findings underscore the value of structured collaboration and forward-looking planning for budget-constrained inference.

    Source: §5 · p. 9

    Autonomous agent coordination requires developers and researchers to implement safety guardrails and bias monitoring.

    Source: Impact Statement · p. 9

Abstract

from arXiv · show

Scaling test-time computation has been shown to significantly improve large language model (LLM) performance without additional training. However, extending these techniques to multi-agent systems remains challenging: existing approaches lack principled mechanisms for allocating compute to enable effective collaboration, scaling coordination itself, or optimizing compute usage under explicit budget constraints. To address this gap, we propose FutureWeaver, a framework for planning and optimizing test-time compute allocation in multi-agent systems under fixed budgets. It introduces collaboration modules, formalized as modular, callable functions that encapsulate reusable multi-agent workflows and are automatically induced via self-play reflection from recurring interaction patterns. Building on these modules, it employs \emph{a dual-level planning architecture} that jointly performs short-horizon action selection and long-horizon abstract lookahead to optimize inference trajectories under budget constraints. Experiments on complex agent benchmarks demonstrate that FutureWeaver consistently outperforms baselines across diverse budget settings, validating its effectiveness for multi-agent collaboration in inference-time optimization.

1 Introduction

Multi-agent test-time scaling requires planning compute across agent interactions, not merely extending a single model’s reasoning. FutureWeaver combines reusable collaboration modules with dual-level planning, and reports consistent improvements over baselines in task success and budget utilization.

1 Introduction

  • Multi-agent compute allocation is a trajectory-planning problem involving which agents to invoke, when to verify, and how to integrate intermediate artifacts.Sequential orchestrator–worker routines offer limited coordination mechanisms and can underuse agent complementarities.Source: §1 · p. 1
  • Existing budget-aware methods largely optimize within fixed inference structures rather than selecting agent invocations and coordination steps under a hard budget.The value of spending compute at one step depends on the downstream trajectory it enables, including the ordering of agents and modules with heterogeneous costs and capabilities.Source: §1 · pp. 1–2
  • FutureWeaver uses reusable, callable collaboration modules induced through self-play reflection and a dual-level planner to allocate compute under fixed budgets.The short-horizon planner ranks next actions, while the long-horizon planner estimates future compute and feasibility to guide those choices.Source: §1 · p. 2
  • FutureWeaver consistently improves over baselines across challenging multi-agent benchmarks in task success and budget utilization.The framework’s benchmark results are attributed to balancing short-term decisions with long-horizon feasibility.Source: §1 · p. 2

2 Orchestrator–Worker Framework Under Budget Constraints

The orchestrator–worker framework models budget-constrained task solving as a sequence of agent actions that update intermediate states. An LLM-based orchestrator selects and evaluates worker actions until it returns a solution or exhausts the budget.

2 Orchestrator–Worker Framework Under Budget Constraints

  • Available worker agents have distinct capabilities and invocation costs, and the task proceeds through intermediate states from an initial description to a final output.The cumulative cost of actions is constrained by a fixed budget.Source: §2 · p. 3
  • At each step, the orchestrator selects a worker and its input; executing that action produces an output and a new state, with action costs bounded by the budget.The next action is selected from the execution history.Source: §2 · p. 3
  • An LLM instantiates the orchestrator policy to generate subtasks, assign workers, evaluate outputs, and choose subsequent actions until a solution is produced or the budget is exhausted.The implementation follows the ReAct framework.Source: §2 · p. 3

3 FUTUREWEAVER

FutureWeaver structures multi-agent collaboration as reusable callable modules and plans inference-time actions under fixed budgets. Its dual-level planner pairs immediate action ranking with lookahead over budget-feasible continuations, while self-play reflection supplies estimates and discovers modules.

3.1 Collaboration Modules

  • Collaboration modules package reusable workflows among multiple agents, addressing the limits of sequential one-agent-at-a-time coordination on complex tasks.The orchestrator can invoke a module as a single action; workflows can combine agent outputs or chain agents in a pipeline.Source: §3.1 · pp. 3–4

3.2 Dual-Level Planning Architecture

  • The planner expands a search tree over agent or module actions, combining short-horizon promise with long-horizon feasibility to choose a budget-respecting next step.The feasible speculative set also conditions the next step’s candidate proposals, coupling lookahead to action generation.Source: §3.2 · p. 4, §3.2.1 · p. 4

3.2.1 Short-Term Planning

  • Short-term planning ranks sampled actions using local consensus and a performance prior derived from similar past trajectories.The prior aggregates success rates from trajectories retrieved by semantic similarity; the combined signals are integrated with a geometric mean.Source: §3.2.1 · p. 5

3.2.2 Long-Term Planning

  • Long-term planning uses symbolic module-level speculative trajectories and estimated cumulative costs to filter continuations that exceed the remaining budget.Its feasibility score helps favor actions likely to sustain progress within budget, and the feasible set guides later candidate generation.Source: §3.2.2 · p. 5

3.3 Self-Play Reflection

  • Offline self-play reflection builds an experience buffer on validation tasks to estimate agent and module performance and costs and discover recurring successful interaction sequences.An LLM reflects on successful trajectories to turn recurring sequences into reusable modules, which are refined over further rounds; average observed costs are treated as transferable across tasks.Source: §3.3 · p. 6

4 Experiments

Experiments evaluate FutureWeaver on three agent benchmarks under fixed compute budgets. It achieves the strongest results across budgets, while component and cost analyses highlight the value of combining short- and long-horizon planning and using more of the available budget.

4.1 Experiment Settings

  • The evaluation covers GAIA, BrowseComp-Plus, and BigCodeBench, uses task-specialized agents and self-play-induced collaboration modules, and tests multiple budget settings.Budgets are based on average trajectory costs from self-play reflection, with larger constraints set by fixed increments or exponential scaling; Acc@B measures accuracy within each query’s token-cost limit.Source: §4.1 · p. 7

4.2 Benchmark Results

  • Fixed workflows underperform on GAIA and BrowseComp-Plus but surpass ReAct on BigCodeBench, where end-to-end coding workflows are more effective.The fixed-workflow results remain largely unchanged as budgets increase because these methods lack dynamic compute allocation.Source: §4.2 · p. 8
  • ReAct uses larger budgets poorly; Best-of-N and Iterative Verification add substantial compute but yield minimal, inconsistent accuracy gains that plateau.These results indicate that simply increasing budget through standard test-time scaling does not guarantee improved performance.Source: §4.2 · p. 8
  • FutureWeaver achieves the strongest results across all budgets, with gains attributed to more effective compute allocation through dual-level planning.The evaluation reports results on GAIA, BrowseComp-Plus, and BigCodeBench using Acc@B.Source: §4.2 · p. 8, Table 1 · p. 8

4.3 Impact of Short-term and Long-term Planning

  • On GAIA, short-term planning improves over vanilla ReAct, long-term planning performs slightly better at higher budgets, and combining both gives the strongest performance.The component comparison uses Claude models under $0.2 and $0.5 budgets.Source: §4.3 · pp. 8–9, Table 2 · p. 9

4.4 Cost Utilization under Budget Constraints

  • On GAIA, baseline costs plateau below budget, whereas FutureWeaver uses more of the available budget and achieves higher performance.Figure 2 compares average total cost with total budget for Claude and Qwen3.Source: §4.4 · p. 9, Figure 2 · p. 9

5 Conclusion

FutureWeaver combines reusable collaboration modules with dual-level planning to optimize multi-agent test-time compute under budgets. Experiments report higher accuracy and more efficient resource use than standard and test-time-scaled baselines.

5 Conclusion

  • FutureWeaver optimizes multi-agent test-time compute under budget constraints using reusable collaboration modules and dual-level planning.The planning balances short-horizon execution with long-horizon speculation.Source: §5 · p. 9
  • Across extensive experiments, FutureWeaver consistently outperforms standard and test-time-scaled baselines in accuracy while using resources more efficiently.Source: §5 · p. 9
  • The findings point to structured collaboration and forward-looking planning as promising directions for more adaptable, compute-efficient multi-agent systems.Source: §5 · p. 9

Impact Statement

The impact statement calls for safety guardrails and bias monitoring when autonomous agent coordination is deployed. The related-work discussion distinguishes FutureWeaver’s budget-aware, inference-time planning from prior scaling and multi-agent design approaches, while supplementary details describe benchmark-specific agents and workflows.

Impact Statement

  • Autonomous agent coordination calls for rigorous safety guardrails and bias monitoring to support alignment with human values during deployment.Source: Impact Statement · p. 9

A Related Work

  • Prior budget-constrained test-time scaling mainly targets single-LLM settings or system efficiency, while FutureWeaver addresses budget-optimal compute allocation for multi-agent systems.Source: A Related Work · p. 14
  • Prior multi-agent optimization automates components such as prompts, tools, or workflows, but generally lacks dynamic budget-aware inference planning and reusable collaboration abstractions.Source: A Related Work · p. 14

B Supplementary Details on Agents and Collaboration Modules

  • Supplementary workflows include interactive search and browsing, ensembles, and search followed by browsing for GAIA; BrowseComp-Plus adds critic-based variants, while BigCodeBench uses code-and-verify variants.The code-and-verify workflows include an iterative variant fixed at two iterations.Source: B Supplementary Details on Agents and… · pp. 14–15

C Token Pricing for Cost Computation

The paper computes monetary action costs from input and output token use and token prices. It counts orchestration and planning calls in the budget, while generating both planning horizons jointly in one invocation per step.

C Token Pricing for Cost Computation

D Reliability of Mean-Based Cost Estimation

The paper checks whether mean-based self-play cost estimates remain useful at deployment. On GAIA with Claude models, the reported gaps are manageable, and the planner rechecks feasibility using the actual remaining budget.

D Reliability of Mean-Based Cost Estimation

  • 7% to 24% estimation gaps support mean-based cost estimates as reliable in practice, while the planner dynamically rechecks feasibility using the actual remaining budget.Fixed invocation counts limit cost variance; browsing-related and reasoning-heavy modules have higher standard deviations due to variable content lengths.Source: D Reliability of Mean-Based Cost… · p. 16, Table 4 · p. 16

E Implementation Details

The implementation details specify how the best-of-N and iterative verification baselines use available inference budget.

E.1 Baselines

  • Best-of-N uses N = 3, falling back to available attempts and self-consistency if the budget runs out early.Source: §E.1 · p. 16
  • Iterative verification spends any budget remaining after an initial answer on orchestrator review and refinement until the budget is exhausted.Source: §E.1 · p. 16

E.2 Dual-level Planning Architecture

The dual-level planner generates short-term actions alongside speculative longer-term module sequences. It filters continuations by estimated cost against the remaining budget, without needing to predict intermediate outputs accurately.

E.2 Dual-level Planning Architecture

  • The orchestrator jointly generates candidate next actions and plausible future module sequences in one invocation, reducing planning overhead.Source: §E.2 · pp. 16–17
  • Continuations exceeding the remaining budget are filtered out, and the share of feasible continuations determines the feasibility score h(·).Feasible plans carry forward to condition candidate generation and speculative continuations in the next round.Source: §E.2 · p. 17
  • Speculative trajectories check whether an action leaves budget for plausible completion; they need not predict intermediate states accurately.Module-level granularity keeps the procedure lightweight.Source: §E.2 · p. 17

F Validation of Trajectory-Level Success as a Performance Prior

The ablation tests whether trajectory-level success is a sufficient performance prior compared with fine-grained judging of individual subqueries. The accompanying algorithm is identified as dual-level planning, with execution bounded by a step limit and remaining budget.

F Validation of Trajectory-Level Success as a Performance Prior

  • The ablation uses an LLM judge to assess individual subqueries and tests Acc@0.5 on GAIA and BrowseComp-Plus with Claude models.Source: F Validation of Trajectory-Level… · p. 17
  • Subquery-level judging does not necessarily improve performance on GAIA and BrowseComp-Plus, supporting trajectory-level success as a robust, computationally efficient prior.The authors attribute this to workflow coupling: a correct subquery matters only if subsequent agents can use its output.Source: F Validation of Trajectory-Level… · p. 17

G Dual-Level Planning Algorithm

  • The dual-level planning algorithm continues while below Tmax, budget remains, and the task is unsolved, then returns a final output derived from the history.Its stated inputs include a policy, agents or modules, an exploration buffer, initial history, and total budget.Source: G Dual-Level Planning Algorithm · p. 19
Loading 2512.11213v2…