Learning to Orchestrate Agents in Natural Language with the Conductor
Authors: Stefan Nielsen
Edoardo Cetin
Peter Schwendeman
Qi Sun
Jinglue Xu
Yujin Tang
Venue: ICLR 2026 Poster (2026)
Keywords: RL
reasoning
LLM
tool use
prompting
Primary area: foundation or frontier models, including LLMs
TL;DR: We introduce the Conductor, a new kind of language model trained with reinforcement learning to automatically discover powerful coordination strategies among LLMs

Abstract: Powerful large language models (LLMs) from different providers have been expensively trained and finetuned to specialize across varying domains. In this work, we introduce a new kind of Conductor model trained with reinforcement learning to automatically discover powerful coordination strategies among LLMs. Our Conductor learns not only to design targeted communication topologies for effective agent-to-agent collaboration, but also to prompt engineer focused instructions to the LLMs to maximally leverage their individual capabilities.  We show that, by learning optimal coordination strategies over pools of powerful worker LLMs, a 7B Conductor achieves significant performance gains beyond any individual worker, attaining state-of-the-art results in challenging reasoning benchmarks, such as LiveCodeBench and GPQA. By training with randomized agent pools, our conductor effectively adapts to arbitrary sets of open- and closed-source agents, meeting any user requirements. Furthermore, allowing the Conductor to select itself as a worker gives rise to recursive topologies, elevating performance with a new form of dynamic test-time scaling through online iterative adaptation.
More broadly, ours is among the early work demonstrating language model coordination can be unlocked through RL, where powerful coordination strategies emerge naturally in LLMs through pure end-to-end reward maximization.

Published as a conference paper at ICLR 2026
LEARNING TO ORCHESTRATE AGENTS IN NATURAL LANGUAGE WITH THE CONDUCTOR
Stefan Nielsen 1-
Edoardo Cetin l
Peter Schwendeman 2-1
Qi Sun 13
Jinglue Xu Yujin Tang'
1 Sakana AI, Japan
Uniivesityy of Michigan, USA 3 Institute of Science Tokyo, Japan
ABSTRACT
Powerful large language models (LLMs) from different providers have been ex- pensively trained and finetuned to specialize across varying domains. In this work, we introduce new kind of Conductor model trained with reinforcement learning to automatically discover powerful coordination strategies among LLMs. Our Conductor learns not only to design targeted communication topologies for ef- fective agent-to-agent collaboration, but also to prompt engineer focused instruc- tions to the LLMs to maximally leverage their individual capabilities. We show that, by learning optimal coordination strategies over pools of powerful worker LLMs, 7B Conductor achieves significant performance gains beyond any indi- vidual worker, attaining state-of-the-ar results in challenging reasoning bench- marks, such as LiveCodeBench and GPQA. By training with randomized agent pools, our conductor effectively adapts to arbitrary sets of open- and closed-source agents, meeting any user requirements. Furthermore, allowing the Conductor select itself as a worker gives rise to recursive topologies, elevating performance with a new form of dynamic test-time scaling through online iterative adaptation. More broadly, ours is among the early work demonstrating language model co- ordination can be unlocked through RL, where powerful coordination strategies emerge naturally in LLMs through pure end-to-end reward maximization.
INTRODUCTION
Through unprecedented scale and engineer- ing effort, modern Large Language Models (LLMs) (Anthropic, 2025; OpenAl, 2025; 2023; Team al., 2023) demonstrate the ability to solve formidably complex tasks, with performance even approaching that of top human experts (Luong & Lockhart, 2025). These remarkable latent capabil- ities are essentially the product of training scale and better utilization of the models themselves,
GPQA Diamond
UvaCodeBanch
B2-
with a history of research showing the importance of combining and developing the two for effective utilization (Liu al., 2023; Brown et al., 2020). However, utilizing these latent capabilities to their full potential remains a challenge even for ex- perienced users, with workflows being critical components of commer- cial AI products (AWS, 2025; Anysphere, 2025; Microsoft, 2025) while effective prompting and self-refinement strategies are still a core focus of the current research (Wei et al., 2022; Madaan et al., 2023a). Furthermore, different models are finetuned to specialize in particular datasets and domains with no single LM universally optimal across all tasks (Chang al., 2024).
Contuccer (Ders)
Gef ingh)
Gennis 2,5 Pe
mesydenk R1
Contucter (Ours)
GeT migy
Grenis 2.5 Pro
Devestest R1
Grasde Qpss
Clask
agentic
Figure 1: Our Conductor attains the state-of- the-art in GPQA and LiveCodeBench.
* Equual contribution
Work done during internship at Sakana AI Correspondence to: fant el sen, edo, junintang

---

Published as a conference paper at ICLR 2026
Based on these considerations, introduce the RL Conductor: new kind of reasoning model trained with reinforcement learning (RL) (Guo et al., 2025; Shao et al., 2024) to dynamically divide challenging problems, delegate targeted subtasks, and design communication topologies for set of worker LLM agents. Our model is itself an L.M tasked to output a sequence of workflow steps, each defined by natural language instruction focusing on some aspect of the overall task, the signed agent receiving that instruction, and each agent's 's visibility to the other agents as they perform their role. This formulation enables our Conductor construct entirely flexible agentic workflows customized to each input problem, with common strategies such as prompt engineering, refinement, and even meta-prompt optimization, naturally emerging from end-to-end reward maximization.
By effectively leveraging the complementary skills of its powerful worker agents, 7B Conductor attains state-of-the-art results on challenging reasoning benchmarks such as BiveCodeBench and GPQA Diamond (Figure 1). Our systematic evaluation shows that the performance of our Conductor goes considerably beyond both traditional self-reflection strategies with any of its workers, and also prior costly multi-agent collaboration baselines that use much larger number of agent calls (Wang et al., 2024; Yue et al., 2025). These findings hold well beyond the set training tasks and across a wide range of math, coding, and natural science domains, demonstrating the potential of our model to supersede manual agentic scaffolds with a general and robust end-to-end approach.
We also effectively extend our framework by finetuming tional techniques to better suit custom user requirements and further push performance in exchange for test-time compute. First, by training with randomized agent pools at each step, show model can generalize to arbitrary sets of open and closed-source workers, allowing users to still harness state-of-the-ee performance with expensive API calls. Furthermore, by allowing the Conductor to specify itself as a worker LLM, we give rise to a new kind of recursive topology, which unlocks a new tunable axis of inference-time scaling in reasoning models.
pretrained Conductor with two addi-
To facilitate future research and extensions, we share the codebase of our new framework with this submission, allowing the reproduction of all results. summary. our contributions are threefold:
We introduce the RL Conductor, language model trained through end-to-end reinforce- ment learning to divide challenging problems, delegate targeted subtasks, and design com- munication topologies for set of worker LLMs- all in natural language.
We demonstrate that by obtaining effective prompt engineering and coordination skills, small 7B Conductor can raise its worker LLMs to new heights, attaining state-of-the- re- sults complex reasoning tasks and outperforming more expensive multi-agent baselines.
We show how short finetuning unlocks extensions such as adaptability to arbitrary agent pools and powerful recursive topologies that yield a new test-time scaling axis.
REINFORCEMENT LEARNING AND REASONING
Recent progress in scaling the performance of LLMs by increasing test-time compute has been driven by the reinforcement learning (RL) "reasoning" paradigm, which has established itself as a ubiquitous new stage of training large-scale open and closed source models (Jaech et al., 2024; Guo et al., 2025; Meta AI, 2025; Yang et al., 2025; Comanici et al., 2025). The high-level recipe, introduced by the DeepSeek RI line of work (Wang et al., 2023; Shao et al., 2024; Guo et al., 2025), optimizes an LLM тo. using custom system prompt, by making it generate its own completions o, to set of verifiable problems = (4,,81). $1),.... (ΦN, sN). This custom system prompt instructs the model to answer each question while providing thinking trace before its solution attempt, placing each inside appropriate <th <think> and csolution on> tags. The rewards r; for each output of the model are then determined by two conditions:
1. The format condition, setting r; to -1 for any of the model's outputs that do not adhere to the specified <think</<solutinn
format.
2. The correctness condition, setting r; to 1 in case the model's correctly formatted outputs match the solution s; and to -0.5 otherwise.
Using these rewards, the model is trained with GRPO (Shao et al., 2024), a simple online RL algorithm. GRPO uses the LLM mo to generate set of G > grouped completions {o1.-.., 0G)
2

---

Definition. Each agentic workflow is defined as a sequence of workflow steps whose final output is returned the actual Conductor response o,, Each step specifies a string with a natural-language subtask, an integer id corresponding to the assigned worker agent responsible for performing that subtask, and an access Published as a conference paper at ICLR 2026
User
We call subarray of an array complete the number distinct elements in the subarray is equal to the number of distinct elements the whole array. Return number of complete subarnays.
Conductor
Here's the plan: 1) Model 2 will develop an algorithm to efficiently count all possible complete subarrays for given array, 2) Model O will implement the function to solve the problem.
model 22 0 0
subtasks - ("Develop an efficient algorithu to count the number of complete subarrays of an array". "Implement the algorithm described by the previous agent in Python" "] access_list== = ["all"]
Figure 2: The Conductor output. The Conductor responds with the entire coordination strategy.
for each question q E D. Then, for 2 and a KL-divergence penalty to the reference model DKL(-ll Teet), the optimization objective is given by the KL-discounted policy maximization:
G G
(()) D. (o)8
min(r:A4, clip(r,, 1 1- c) A.) -3 lKLL (1T mrer))
(1)
using the grouped completions compute Monte-Carlo advantage function (Sutton al., 1999):
A; Ti mean((r),...........
As specified its system prompt, this simple recipe has been shown to effective at aligning the model with self-emergent thinking capabilities, yielding unprecedented task specialization.
LEARNING TO CONDUCT AN ORCHESTRA OF MODELS
In this work, design new reinforcement learning framework for training Conductor language model to prompt-engineer and coordinate a set much larger and more powerful LLM agents. The Conductor outputs full agentic workflows that divide an input task, allocate natural-language sub- tasks, and define targeted communication strategies to best make use of the agents' complementary capabilities detailed in the remainder of the section.
3.1 FRAMING AGENT COORDINATION IN NATURAL LANGUAGE
The Conductor task. The Conductor's 's objective is to solve tasks indirectly by designing different agentic workflows specific to any input question q:
list indexing which subtask solutions from the previous steps to include in the worker's context.
The information about each agentic workflow is parsed from the Conductor's response after its chain-of oftthu three simple Python lists with the same number of entries. This output struc- ture exemplified in Figure 2, in which the Conductor devises an agentic workflow first querying agent 2 to devise algorithm, and then agent 0 to implement it in Python with the previous answer from agent 2 in context. To accelerate learning and make our framework compatible with arbitrary models, provide the Conductor with detailed instructions in the system prompt alongside exam- ples with the expected output format. This design lets the Conductor freely craft tailored subtasks and communication strategies across its workers, allowing the specification of agentic workflows
3

---

Published as a conference paper at ICLR 2026
sabtorky is ("Undersant the problew and fou snarey to calcutate the panishoeeu num. het Ideanff the integery whoue squares can be partiniued into saburingg that zare the integer bayf Thes, catrulate the con of the spurrs of thesr iurgers"
"Veriyy propored uaaegy provess cidoa>sopp"'
pope
underzionding Provide
stp-lby-sip
"Rofne the proyosed stralegy if necensrry and then implement the putishveniiubber func- Hon in Python acconding to the glaes contraints Prandde a map-tiy eep-try-itrp iolation in cideaziagr and renorn the foal code in cansver> as spectied")
subtasks ('Asalyee the giren parameters of the sisple harmonic motion (period and am plitade) and the nuttal posttion of the object. Ideatity the nathomatical equation that describes the position of the object finction time..
0.5
Conducter
"Calculaie the time tobes for the objest to from 5,70 -1.00 wingg the and parsnaters")
equction derived the
30
Figure 3: Emergence of powerful coordination strategies over training. Early in training, the Conductor issues sound subtasks, but does not tap useful collaborative strategies such verification (bottom-right). Near convergence, the Conductor has learned to utilize planners, issuc targeted instructions, instruct workers share reasoning, and leverage verification and refinement (top-right), leading to the Conductor surpassing the worker agents' performance on our training dataset (left).
ranging from simple best-of-N and sequential chain-like topologies to parallelizable arbitrary tree- structured approaches, harnessing the individual strengths and synergies of its agents.
Workflow execution and learning dynamics. Each agentic workflow outputted by the Conduc- tor is executed sequentially by prompting the specified worker agents with their assigned natural language subtask. In each workflow step, the worker's context includes the sequence of previous subtasks and corresponding responses defined in the access list, simply provided past messages in a conversational template. Analogously to the traditional RI framework, the reward r; for each response from the Conductor model determined by two progressive conditions:
1. The Conductor format condition, setting r; to O for responses from which the Python lists of subtasks, worker ids, and access lists canmot be parsed.
2. The Conductor correctness condition, setting r; to 1 if the final output from executing a well-formatted agentic workflow o, matches the solution s; and to 0.5 otherwise.
While training end-to-end with the conductor reward is inherently compatible with any RL algo- rithm (Schulman et al., 2017; Ahmadian et al., 2024), in this work, we employ the GRPO formula- tion described in Section 2. Training the Conductor with this simple recipe, observe the emer- gence of problem breakdowns and prompt-engineered subtasks that match the strengths of cach worker, together with communication strategies that combine independent attempts with final de- bate rounds. As shown in Figure: 3 and detailed in the following section, these Conductor behaviors lead to our model quickly surpassing each of its much larger workers, yielding state-of-the-an per- formance far beyond manually-designed multi-agent pipelines.
3.2 EXTENDING THE RL CONDUCTOR
Adaptive worker selection. To make the Conductor robust to variation in the available worker pool, extend our framework to operate over customizable subsets of models. To this end, we simply finetune a pretrained Conductor, restricting it for each question to a randomly sampled k-model subset from the larger total pool of n workers and accordingly modifying its input instructions. After training, this design makes the Conductor generalize and extract strong performance over a specific desired subset of S n models, allowing our model to cater towards specific user constraints and cost preferences. This extension aims to drive flexible coordination, with the Conductor learning to reconfigure problem breakdowns based on the varying synergies arbitrary sets agents.
Recursive topologies and test-time scaling, We also extend our framework by introducing recur- sive agentic workflows, allowing the Conductor to leverage its own capabilities to complement the other worker agents. During each inner recursive call, the Conductor is provided as an additional input its own parent output from which the call was instantiated, together with the previous agent's 's response. With this context, the Conductor will be given the chance instantiate agentic
4

---

Published as a conference paper at ICLR 2026
Table 1: Comparison with previous best "unconstrained" results. The Conductor's performance is significantly beyond official reported results across several challenging reasoning benchmarks, setting new records and pushing the boundary of LLM capabilities with collective intelligence.
In-Domain Tasks
Unseen Tasks
Model
M500
MMLU
RLPR
LCB
AIME25
BCB
GPQA-D
Avg.
gemma-3-27b-it
39.8
81.3
16.67
13.14
20.7
14.86
38.4
32.12 12
Qwen3-32B
73.5
83.5
31.00
21.21
20.0
30.41
64.1
53.81
Qwen3-32B (thinking)
80.7
37.25
25.86
72.9
28.38
66.8
56.57
D1-Distill-wen--333
82.5
84.4
33.50
26.86
63.0
33.07
58.1
54.49
Claude Sonnet 4
96.0
91.4
36.70
46.54
74.3
37.16
77.7
65.69
Gemini 2.5 Pro
96.0
92.4
40.55
67.24
78.3
37.51
84.8
70.97
GPT
99.0
93.5
42.20
82.90
90.8
32.75
82.3
74.78
Conductor (Ours)
99.4
94.1
44.75
83.93
93.3
37.86
87.5
77.27
workflow or end the coordination loop by returning the final subtask solution directly to the user. We avoid infinite recursion loops by allowing recursive calls, after the initial root Conductor call, to occur only up to a specified maximum number before returning the final response to the user. We unlock recursive capabilities in pretrained Conductor models by simply finetuning with the same RL algorithm while manually instantiating a single recursion call for half the samples in each batch. After training, this formulation allows for adaptively increasing the maximum number of recursion calls during inference to effectively introduce a new form of test-time scaling, leveraging recur- sion as tunable compute axis beyond open-ended chain-of-thoughts. We present a visualization of recursion in Fig. 12.
4 EVALUATING THE RL CONDUCTOR
We evaluate the capabilities of the RL Conductor at scale. In this section, we quantitatively show how 7B Conductor attains state-of-the-art results across current frontier models, outperforming wide range of expensive self-reflection strategies and traditional multi-agent collaboration baselines at fraction of the cost. Furthermore, we demonstrate how extensions such as test-time recursive scaling and adaptive worker selection can be efficiently integrated by finetuning our pre-trained Conductor to unlock new, powerful capabilities. Finally, we thoroughly analyze the properties and behavior of pretrained Conductors, illustrating the emergence of prompt engineering capabilities with increasing model size and tifficulty-adaplie coordination strategies.
4.1 TRAINING AND EVALUATION SETUP
For our main experiments, we train a small Conductor with 7B parameters with the framework detailed in Section 3, starting from a Qwen2.5 checkpoint (Hui et al., 2024). Our Conductor is tasked to devise agentic workflows of up to five steps using both proprietary frontier models, such as Gemini-2.5-Pro (Comanici et al., 2025), Claude-Sonnet-4 (Anthropic, 2025), and GPT-5 (Ope- nAI, 2025), together with open-source alternatives such as al., 2025), Gemmma-27B-instruct (Team et al., 2025), and Qwen3-32B (Yang al., 2025). Our training dataset comprises 960 problems from four reasoning domains covering a range of math, coding, and general real-world reasoning questions, selected for their difficulty and diversity. In composing this dataset, we used the seminal competition MATH corpus (Hendrycks et al., 2021), the multitask language comprehension task MMLU (Hendrycks al., 2020), the real-world reason- ing task RLPR (Yu et al., 2025), and the code generation benchmark LiveCodeBench VI (Jain et al., 2024). We empirically find that, by relying on powerful set of workers, our framework effectively sidesteps the canonical exploration problem faced by other small models trained with RL (Cetin et al., 2025), efficiently reaching convergence with AdamW (Loshchilov & Hutter, 2017) in only 200 GRPO iterations, small batch size of 256 samples, and without any KL regularization.
(Guo Di-issiil--iisssle--eeeen
Our evaluation focuses on assessing the Conductor's capabilities to generalize across a set of chal- lenging reasoning tasks both within and outside its training domain. For in-domain evaluation, use all unseen test questions from MATH500, MMLU, RLPR, and LiveCodeBencl V6. For out-of- domain evaluation, include three unseen test tasks with GPQA Diamond (Rein al., 2024), the set diamond difficulty questions on natural science taken from the Graduate-level Google-prut proof Q& A benchmark, BinCh (Zhuo et al., 2024), evaluating code generation and task automa-
5

---

Published as a conference paper at ICLR 2026
MATH500
MMLU
ALPR
LiveCodeBench
00
S.aam rnfection
Nu B'Agett Saadinca
500 (M)
20
Celeen DDurr
Contect (tuerl
and
Figure 4: Conductor in-distribution evaluation against multi-agent methods and 5-turn reflec- tion agent baselines. The Conductor surpasses all baselines by substantive margins, exemplifying the Conductor's ' ability to amplify the capabilities of its workers. Numerical results in Table
tion, and AIME25 (Mathematical Association of America, 2025), the latest set of problems used for the American Invitational Mathematies Examination. These tasks cover diverse set of competition and graduate-level models, with neither individual open nor closed-source model currently reigning supreme. To account for empirical stochasticity, we repeat each evaluation up to 16 times based on the number of questions in each task, reporting mean accuracy and standard errors. We provide all details on training and evaluation paradigms, including full hyperparameters, in Appendix A and E.
4.2 ELEVATING LLMS TO A NEW FRONTIER WITH THE CONDUCTOR
We first compare the Conductor's in-domain and out-of-domain performance with the previous best prior results obtained with different state-of-the-art open and closed source models. For each of our baselines, we report the "unconstrained", where all models utilize maximum reasoning and output token budgets, highest recorded performance across our own re-evaluations, private implementa- tion, and online leaderboards. potentially including proprictary, undisclosed prompting and sam- pling strategies. Nonetheless, shown in Table 1, our Conductor obtains substantial improvements compared to the very best baseline in each considered task, attaining state-of-the-art performance records when evaluated both in-domain and out-of-domain. For example, as shown in Fig. 1, the performance of the Conductor at the time of writing is beyond any prior LLM on the livecodebench online leaderboard even surpassing the latest OpenAl's O-series models (Jaech et al., 2024), which were not included in our worker pool due to their exceedingly high cost. Furthermore, we see the Conductor, through its powerful coordination strategies, is able generate performance gains across AIME25 and GPQA-Diamon provements these challenging benchmarks, mirroring the performance jump 12 from o3 to GPT-5, for example. We believe these results strongly validate the remarkable efficacy of our Conductor establishing a new frontier in the capabilities of language models through collective intelligence and a new kind of powerful, adaptive agentic coordination.
in the range of 3%, which is consistent with entire generational im-
4.3 CONTROLLED LARGE EVALUATION
Expensive multi-turn agentic baselines. We also directly compare the RL Conductor with a broad range of multi-turn baselines and prior state-of-the-art adaptive routing strategies trained and eval- uated with our same worker pool. First, we consider a robust and popular self-reflection agentic approach (Madaan et al., 2023b; Du al., 2023b) where for all questions, each agent is prompted up to five times to revise and improve its answers, while keeping all its previous attempts in context. Moreover, we consider four expensive multi-agent routing coordination strategies, including MAS- Router (Yue et al., 2025), Mixture-of-Agents (MoA) (Wang et al., 2024), RouterDCC (Chen et al.,

---

Published as a conference paper at ICLR 2026
2024), and Smoothie (Guha et al., 2024). In all multi-agent baselines, we train and evaluate these models with the same set of agents as our Conductor, as described in Section 4.1. These prior multi-agent strategies essentially train router classifier to construct agentic workflows by simply selecting models and/or human-designed coordination topologies from a set of pre-specified options. We note that the expressivity of these prior strategies is inherently constrained when compared to our new framework, which places complete specification freedom in the Conductor by directly using natural language as its output medium.
Quantitative results and analysis. We report the results from this large-scale scale evaluation in Fig- ure 4, once again demonstrating how the Con- ductor's new unrestricted approach, with unpar- alleled specification freedom, yields unmatched levels of performance across each single con- sidered task. With the sole exception of Rou- terDC, we note that all the baseline methods this comparison have strictly higher inference cost than our Conductor, which learns to con- struct efficient agentic workflows with age of 3 steps, well below the requested limit de- spite being trained with no regularization. For ex- ample, MASRouter's performance heavily hinges on its usage of expensive human-designed agen- tic coordination strategies, combining 4-5 differ- models and roles into extensive topological sequences. We believe this stark cost difference makes the Conductor's dominance even more markable, highlighting how our model's unrestricted prompt-engineering and task delegation ca- pabilities provide critical degree of adaptivity inherently beyond prior routing models and fixed human-designed strategics.
17.5
Conductor
70.0
67.5
63.0
MoA
Averagg
57.5
Smoothie
MASRouter
58.0
52.5
RouterDC
Average Number
Figure 5: Performance vs Efficiency. The Con- ductor far surpasses multi-agent baselines at a fraction of the cost. Scores are task-averages from Fig. 4. Numerical results in Table 7
4.4 USER- NEER-CUSTOMIZATION AND TIME RECURSIVE SCALING
We incorporate the extensions detailed in Section 3.2 into a pretrained Conductor with short fine- tuning phases. We train using small subset of questions already seen during training, demonstrating how powerful extensions can be easily integrated without new data. We hope these experiments can provide future work with an inexpensive blueprint to adapt our powerful new model.
Dynamic worker pool. We evaluate our Con- ductor finetuned on randomized model subsets and compare it with its pre- pre-trained counterpart, which was always given full access to all mod- els in our original set. In particular, we fo- cus on two evaluation user cases, restricting our
Sucset
Subert
LCB Accuooy
40-
models to use either exclusively the closed or
open-source subsets of models. We note that before our targeted finetuning phase, the Con- ductor relied open-source models only in very specific scenarios, given their significantly inferior performance for most tasks. Nonethe- less, as shown in Figure 6, when evaluated with only open models, the finetuned Conductor is able to effectively combine their individually weaker capabilities with surprising effective- ness, even consistently outperforming Claude Sonnet 4 by almost 10% within our constrained setting. This demonstrates core capability of the Conductor, which is that the Conductor is not exclusively reliant the performance foundation of frontier models, and indeed displays larger absolute gains when using a foundation with a larger room for improvement. At the same time, when evaluated with only closed models, the finetuned Conductor does not compromise its original
Gemani-22 3-Pp
Clascte Seomer
(PP:5
Blse Centurtor
Astastive Condarttor
gemma- 778-6
Oeven zate rhiiding)
Buse Cendector
Addaytive Canducter
Comnt
Figure 6: Finetuned on randomized model pools, the Conductor achieves strong performance over rarely used open- model subsets while maintaining performance on the
subsets.

---

Published as a conference paper at ICLR 2026
Table Test-time recursion generates further performance gains. To accommodate recursion, we use our controlled evaluation setting described in Section 4.3. When allowed to specify itself as a worker LLM and adaptively revise its initial coordination strategy test-time, the Conductor unlocks substantive additional gains on BigCodeBench.
Model
AIME25
BigCodeBench
GPQA-D
Average score
gemma-3-27b-it
6.67
10.8
33.33
16.93
Qwen3-32B
23.33
23.0
54.05
33.46
Qwen3-32B (thinking)
23.33
20.9
59.09
34.44
RI- RI-Distill-Qwent 3is
30,00
24.3
51.01
35.10
Gemini Pro
46.67
35.1
75.25
52.34
Claude Sonnet 4
35.33
35.8
67.30
46.14
GPT 5
46.67
33.8
72.73
51.73
Conductor (Ours)
66.67
37.8
81.31
61.93
Comductor-Recursive (Ours)
66.67
40.0
82.32
63.00
Figure 7: Conductor Scale. The 3B Conductor still learns optimal agent selection, as shown by the agent distribution converging on the three most powerful models (left). However, when scaling to 7B, the Conductor generates additional performance gains, even for identical agent selection, through its improved prompt engineering (right). Evaluation performance taken from Fig. 4.
Agant
performance
R3-Dleti Ri-Couti--wwm--00 Owan-200
Owerd 328 minking!
032
Condictor
GPTS-
Obadi Spenec
Gerin io
Conductor 38
22an-220
0.15
30
Owvers-322 528 tenkking)
042
20
605
10-
Clade Scrret
Gerii
125
0d2
Clodle Sennit
Gensio he
Gmndl Conductor 38
Conductorr
state-of-ther -frth-rr behavior, entirely matching its pretrained performance. These results demonstrate that our model can be readily extended to cater to individual user requirements and help mitigate the field's inherent cost-performance tradeoffs.
Self-referential recursive scaling. We evaluate finetuned recursive Conductor out-of- distribution tasks, where both our pretrained model and all its individual workers still show potential for improvement. In particular, GPT5, behave suboptimally when evaluated on BigCodeBench, requiring agentic workflows signif- icantly differing from those learned during pretraining. We present our results in Table showing how incorporating recursion yields a marked performance boost, especially evident on this chal- lenging benchmark. We note that we set our recursive variant to use less than 2x the number of its original agentic calls to mitigate additional costs, potentially leaving room for further improvement on the Conductor's performance by simply increasing compute. Delving deeper into our results, as shown in Figure 10, we find the Conductor effectively redistributes its agent selection towards Claude and Gemini 2.5 during its BigCodeBench recursive calls after observing the unexpect- edly suboptimal behavior of GPT5. Overall, these results compellingly demonstrate the recursive Conductor's 's newfound ability to intelligently design and adjust its agentic workflows on the fly, concretely improving its effectiveness and robustness unseen test scenarios.
observe that some generally proficient coding models, such as
4.5 ANALYZING AND ABLATING THE PROPERTIES OF AN EFFECTIVE CONDUCTOR
Conductor scale. We start our analysis of the Conductor's remarkable capabilities by investigating the role played by model scale. To this end, we examine and compare the behavior of our 7B Con- ductor by training a smaller variant with 3B parameters following the same recipe. We then analyze how the agentic workflows designed by the two models differ, together with their final performance on L LiveCodeBenchh As shown in Figure 7, training progresses, find that the two Conductors
8

---

Published as a conference paper at ICLR 2026
100%
LiveColuBunch
Percentage
50%
25%
slep
0%
2 steps steps
100%
4 stepp steps
Percentage
75%
MMLU
50%
25%
0%
50
100
125
150
175
200
Figure 8: Task adaptivity. In more straightforward tasks, such as MMLU, the Conductor learns that 2 agents working together is optimal. In more complex settings, such LiveCodeBench, the Conductor allocates more compute by devising coordination strategies with 3 or even 4 agents.
converge to select the same distribution of worker agents. However, while both of our models still display performance well beyond all of our baselines, larger 7B variant maintains clear edge the end of training. Comparing the substasks specified by the 7B Conductor and its 3B counterpart, illustrated respectively in Figures and 15 of Appendix larger model's ' superior prompt engineering skills. This relationship further highlights how our new framework opens new axis for scaling multi-agent coordination far beyond prior routing efforts. Together with our results, we believe this analysis further evidences the importance of removing manual constraints on subtask specification; enabling the increased natural language capabilities of larger and newer base models to directly translate into more intelligent prompt engineering and allowing the Conductor to unlock a new level of agency over each its workers.
trace this performance gap to the
Task and difficulty adaptivity. Additionally, we study how distinct input tasks of varying difficulty influence our Conductor. Our analysis reveals a compelling emergent behavior, with the model learning to dynamically allocate more compute to harder problems by specifying agentic workflows with an increased number of steps. We illustrate this phenomenon in Figure 8, showing a stark dif- ference between the distributions of workflow steps for LiveCodeBench code generation and simpler MMLU multiple-choice questions. As training progresses, the Conductor learns to divide complex LiveCodeBench problems into increasingly granular subtasks, often deploying multiple planning steps followed by implementation and verification attempts. In contrast, as MMLU primarily tests factual knowledge and comprehension, the Conductor produces simpler workflows, typically limited to one or two steps of targeted information retrieval. By inspecting the output traces presented in Ap- pendix F. we also observe that the model explicitly reasons about task complexity before specifying its workflows. Coupled with its notable efficiency, this adaptivity highlights how natural language grounding again critical factor in our model's adaptivity, enabling workflows that dynamically match problem difficulty while avoiding wasted computation simpler cases.
RELATED WORK
Reinforcement learning with tools. Reinforcement learning (RL) has become an increasingly popular paradigm for the elicitation of reasoning capabilities in LLMs (Guo er al., 2025; Lambert al.. 2024; Chu et al., 2025). Recent works aim extend the RL paradigm go beyond pure textual reasoning through tool use, enhancing capabilities in geometric reasoning. complex equation solving, code execution, search-augmented question answering, and precise computation (Gehring et al., 2024; Feng et al., 2025; Yu et al., 2024; Le et al., 2022: Nakano et al., 2021). For example, Gehring et al. (2024) and Le et al. (2022) incorporate execution feedback on code synthesis and unit tests into end-to-end RL, Feng al. (2025) use dynamic interleaving of real-time code execution, while Nakano et al. (2021) equip the base model with a text-based web-browser. Yu al. (2024) consider multi-step tool usage through step-grained reward shaping. Our framework establishes new extension to the tool-using RL paradigm, where powerful collaborative reasoning topologies emerge from RL. by equipping the base model with workflow delegation through API calling.

---

Published as a conference paper at ICLR 2026
Multi-agent coordination. With increasingly powerful individual LLMs, recent works aim to de- sign topologiaal and prompt-based scaffolds to coordinate groups of agents (Du et al., 2023a; Wang et al., 2024; Dang et al., 2025; Madaan al., 2023a; Yue et al., 2025). Wang al. (2024) and Du et al. (2023a) propose carefully hand-designed scaffolds to orchestrate agents within and across successive rounds, Guha et al. (2024) and Yue et al. (2025) learn embedding spaces map queries to agents and topologies, Zhuge et al. (2024) treat collaboration as learnable graph, and Chen et al. (2024) learn router to direct queries the single best-matched agent. Our framework differs from all existing approaches by learning powerful agent coordination strategies through pure end-to-ent to- RL, allowing the Conductor complete freedom learn any strategy expressible in natural language.
DISCUSSION AND EXTENSIONS
In this work, we introduce the Conductor, a new language model trained with reinforcement leam- ing to push the boundaries of frontier LLMs through collective intelligence and automated prompt engineering- By dividing challenging problems, delegating targeted subtasks, and designing effec- tive communication topologies, a 7B Conductor attains state-of-the-an -frt performance across a diverse set of highly competitive benchmarks, going well beyond manually designed agentic pipelines and expensive multi-agent baselines. Furthermore, we demonstrate that the capabilities of our pretrained Conductor can be easily extended via finetuning, giving users the ability to specify customized agent sets and unlocking new form of test-time scaling with recursive calling the Conductor itself. By sharing our full code with this submission, we hope to facilitate future efforts in using language models themselves intelligent mela-agents, flexibly harnessing the complementary capabilities of a broader set of models. To this end, an exciting, unexplored extension is to go beyond L.MS alone, introducing workers with expertise in other modalities (Jumper et al., 2021; Intelligence al., 2025), allowing the Conductor to use natural language as an expressive unifying interface and tackle increasingly ambitious human challenges in fields such biology, robotics, and beyond.
ACKNOWLEDGEMENTS
We thank Koshi Eguchi and Kou Misaki for the infrastructure support, and the entire Sakana AI R&D team for their valuable comments and suggestions.
AUTHORS CONTRIBUTIONS
Stefan Nielsen proposed the Conductor as an LLM that reasons over collaboration topologies and subtasks, and implemented and tuned the Conductor. Edoardo Cetin proposed the Conductor as an LLM that reasons over collaboration topologies and subtasks and implemented the core algorithm and training paradigm. Peter Schwendeman proposed and implemented essential prompting and training improvements, tuned the Conductor, built the baseline suite, and conducted analyses that strengthened and validated the system. Qi Sun implemented and conducted the out-distribution task evaluation. Jinglue Xu designed and curated the training datasets. Yujin Tang initiated and led the project, implemented the initial algorithm, and conducted the first experiments. All authors contributed to the experimental design and paper writing.
10

---

Published as a conference paper at ICLR 2026
Reproducibility statement. We provide source code in the supplementary material along with trained model weights in an anonymized external repository. We additionally provide the full details of our experimental setup including datasets, model specification, training regime, and evaluation protocol - in Appendix A and E. Our base model and all datasets are publicly available.
Ethics statement. Our work considers multi-agent collaboration, and in partieular, the connection between reinforcement learning. reasoning, and the capabilitiess of small LLMs to automatically discover optimal coordination strategies over LLM workers. Given this, we see foresee no issues regarding fairness, privacy, or security, or any other harmful societal or ethical implications outside broader considerations for the field itself. However. we do note that the reliance of our method on expensive language models might further exacerbate the economic divide and barriers posed by Al.
REFERENCES
Arash Ahmadian, Chris Cremer, Matthias Gallé, Marzich Fadace, Julia Kreutzer, Olivier Pietquin, Ahmet Üstün, and Sara Hooker. Back to basics: Revisiting reinforce style optimization for learn- ing from human feedback in llms. arXiv preprint (:XXx::2402.174400 2024.
Anthropic. Claude sonnet 4. https: http:://wwwwwattttt http://pppp..cccc////e/////e///e cessed: 2025-08-29.
2025. Ac-
Anysphere. Cursor: The ai code editor.
Accessed: 2025-08-29.
AWS. Amazon q developer. https://aww amazon. http:///cccc///e///c/eeeeee/ee// 2025. Accessed:
2025-08-29.
Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. Advances in neural information processing systems, 33:1877-1901, 2020.
Edoardo Cetin, Tianyu Zhao, and Yujin Tang. Reinforcement learning teachers of test time scaling. arXiv preprint ar ar5iv:2506.00 250.0888800.0.888 08388, 2025.
Yupeng Chang, Xu Wang, Jindong Wang, Yuan Wu, Linyi Yang. Kaijie Zhu, Hao Chen, Xiaoyuan Yi, Cunxiang Wang, Yidong Wang, Wei Ye. Yue Zhang, Yi Chang, Philip S. Yu, Qiang Yang, and Xing Xie. A survey on evaluation of large language models. ACM Computing Surveys, 2024. doi:
10.1145/3641289, URL https: / a1. acm. brg/doi/ 10.0 1145/3641289
Shuhao Chen, Weisen Jiang, Baijiong Lin, James Kwok, and Yu Zhang. Routerde: Query-based router by dual contrastive learning for assembling large language models. Advances in Neural Information Processing Systems, 37:66305-66328, 2024.
Tianzhe Chu, Yuexiang Zhai, Jihan Yang, Shengbang Tong, Saining Xie, Dale Schuurmans, Quoc V Le, Sergey Levine, and Yi Ma. Sft memorizes, rl generalizes: A comparative study of foundation model post- teainrrriing...... arXiv preprint arXiv:2501. 2025.
Gheorghe Comanici, Eric Bieber, Mike Schaekermann, Ice Pasupat, Noveen Sachdeva, Inderjit Dhillon, Marcel Blistein, Ori Ram, Dan Zhang, Evan Rosen, et al. Gemini 2.5: Pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capa- bilities. arXiv preprint arXiv:2507.06261 2025.
Yufan Dang, Chen Qian, Xueheng Luo, Jingru Fan, Zihao Xie, Ruijie Shi, Weize Chen, Cheng Yang, Xiaoyin Che. Ye Tian, et al. Multi-agent collaboration via evolving orchestration. arXiv preprint arXiv:2505. / 19591, 2025.
Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. Improving fac- tuality and reasoning in language models through multiagent debate. In Forty-first International Conference on Machine Learning. 2023a.
Yilun Du Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. Improving fac- tuality and reasoning in language models through multiagent debate. In Forty-first International Conference Machine Learning, 2023b.

---

Published as a conference paper at ICLR 2026
Jiazhan Feng, Shijue Huang, Xingwei Qu, Ge Zhang, Yujia Qin, Baoquan Zhong, Chengquan Jiang, Jinxin Chi, and Wanjun Zhong. Retool: Reinforcement learning for strategic tool use in llms. arXiv preprint arXhv:2504.11555 2025.
Clémentine Fourrier, Nathan Habib, Thomas Wolf, and Lewis Tunstall. Lighteval: lightweight framework for Ilm evaluation, 2023. URL https://github. com/husgiingaaceliighttev pp. 9.
Jonas Gehring, Kunhao Zheng, Jade Copet, Vegard Mella, Quentin Carbonneaux, Taco Cohen, and Gabriel Synnaeve. Rlef: Grounding code Ilms execution feedback with reinforcement learning. arXiv preprint arXhv:2410.02089, 2024.
Neel Guha, Mayee Chen, Trevor Chow, Ishan Khare, and Christopher Re Smoothie: Label free lan- guage model routing. Advances in Neural Information Processing Systems, 37:127645-127672, 2024.
Daya Guo, Dejian Yang. Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, et al. Deepseek-rl: Incentivizing reasoning capability in Ilms via reinforcement learning. arXiv preprint arXiv:2501.12945 2025.
Zhiwei He, Tian Liang, Jiahao Xu, Qiuzhi Liu, Xingyu Chen, Yue Wang. Linfeng Song, Dian Yu, Zhenwen Liang, Wenxuan Wang, Zhuosheng Zhang, Rui Wang, Zhaopeng Tu, Haitao Mi, and Dong Yu. Deepmath- 103k: A large-scale, challenging, decontaminated, and verifiable mathemat- ical dataset for advancing reasoning. 2025. URL https: / aawxiv.vvvv..////i///...//aaaiva org/ abs/ 2504 11456.
Dan Hendrycks, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. Measuring massive multitask language understanding. arXiv preprint arXiv:2009.03300, 2020.
Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. Measuring mathematical problem solving with the math dataset. arXiv preprint arXiv:2 103.vv2203.0387... 2021.
Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang. Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, et al. Qwen2. 5-coder technical report. arXiv preprint arXiv:2409. 12186, 2024.
Physical Intelligence, Kevin Black, Noah Brown, James Darpinian, Karan Dhabalia, Danny Driess, Adnan Esmail, Michael Equi, Chelsea Finn, Niccolo Fusai, et al. Pi 0.5: A vision-languaae-actioo model with open-world generalization. arXiv preprint arXiv:2504. /6054, 2025.
Aaron Jaech, Adam Kalai, Adam Lerer, Adam Richardson, Ahmed El-Kishky, Aiden Low, Alec Helyar, Aleksander Madry, Alex Beutel, Alex Careey, et al. Openai ol system card. arXiv preprint arXiv:2412.1672 2024.
Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang. Armando Solar-Lezama, Koushik Sen, and Ion Stoica. Livecodebench: Holistic and contamination free evaluation of large language models for code. arXiv preprint arXiv:2403.077 079744 2024.
John Jumper, Richard Evans, Alexander Pritzel, Tim Green, Michael Figurnov, Olaf Ronneberger, Kathryn Tunyasuvunakool, Russ Bates, Augustin Zidek, Anna Potapenko, et al. Highly accurate protein structure prediction with alphafold. nature, 596(7873):583--555
2021.
Nathan Lambert, Jacob Morrison, Valentina Pyatkin, Shengyi Huang, Hamish Ivison, Faeze Brah- man, Lester James V Miranda, Alisa Liu, Nouha Dziri, Shane Lyu, al. Tulu 3: Pushing frontiers in open language model post-training. arXiv preprint arXiv:24] I. 15/44, 2024.
Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven Chu Hong Hoi. Coderl: Mastering code generation through pretrained models and deep reinforcement learning. Advances in Neural Information Processing Systems, 35:21314-222 21322,, 2022.
Hunter Lightman, Vineet Kosaraju, Yura Burda, Harri Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, and Karl Cobbe. Let's verify step by step. arXiv preprint arXiv:2305.200 20050, 2023.
12

---

Published as a conference paper at ICLR 2026
Pengfei Liu, Weizhe Yuan, Jinlan Fu, Zhengbao Jiang, Hiroaki Hayashi, and Graham Neubig. Pre- train, prompt, and predict: A systematic survey of prompting methods in natural language pro- cessing. ACM computing surveys, 55(9):1-35, 2023.
Ilya Loshchilov and Frank Hutter. Decoupled weight decay regularization. arXiv preprint arXiv:1711.05101, 2017.
Thang Luong and Edward Lockhart. Advanced version of Gemini with Deep Think officially achieves gold-medal standard at the international mathematical olympiad. Google DeepMind blog, July 2025. URL https: attoturl.at/oeeee Accessed via Google DeepMind "Research" blog.
Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. Self-refine: Iterative refine- ment with seff-eeedback Advances in Neural Information Processing Systems, 36:46534 46594, 2023a.
Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. Self-refine: Iterative refine- ment with self-feedback. Advances in Neural Information Processing Systems, 36:46534-46594 2023b.
Mathematical Association of America. Aime, february 2025.
https://
artofproblent emsol www.wwinnn.........ooo.......oet wwwmwwwiiindde.... wwtpiddxx.ppp//AAtee hhtppppppp//// Probl ems and Solutions/,,002
Meta AL. The Ilama herd: The beginning of a new era natively multi-
modal ai innovation. Meta AI blog, 2025. URL https:/ /ai meta. ccm/blog/
11laam4-mmmm and Hugging Face.
Released April 2025; available via llama.com
Microsoft. Microsoft ott.oo/ooooooooooooooooooooooooo 08-29.
Accessed: 2025-
Reiichiro Nakano, Jacob Hilton, Suchir Balaji. Jeff Wu, Long Ouyang, Christina Kim. Christo- pher Hesse, Shantanu Jain, Vineet Kosaraju, William Saunders, et al. Webgpt: Browser-assisted question-answering with human feedback. arXiv preprint 2rX1v:2111..09332222
OpenAl. Introducing gpt-5. https: gust 2025, Accessed: 2025-08-29.
com/ ittpeaaaiccon/nnee////ttttcoaaao
Au-
R OpenAl. Gpt-4 technical report. arxiv 2303.08774. View in Article, 2(5):1, 2023.
Jiayi Pan, Xiuyu Li, Long Lian, Charlie Snell, Yifei Zhou, Adam Yala, Trevor Darrell, Kurt Keutzer, and Alane Suhr. Learning adaptive parallel reasoning with language models. arXiv preprint 1rX4v:2504.15466, 2025.
David Rein, Betty Li Hou, Asa Cooper Stickland, Jackson Petty, Richard Yuanzhe Pang. Julien Di- rani, Julian Michael, and Samuel R Bowman. Gpqa: A graduate-level google-proof q&a bench- mark. First Conference on Language Modeling, 2024.
John Schulman, Filip Wolski, Prafulla Dhariwal, Alec Radford, and Oleg Klimov. Proximal policy optimization algorithms. arXiv preprint arXiv: 2017.
Zhihong Shao, Peiyi Wang. Qihao Zhu, Runxin Xu, Junxiao Song. Xiao Bi, Haowei Zhang, Mingchuan Zhang, YK Li, Y Wu, et al. Deepseckmath: Pushing the limits of mathematical reasoning in open language models, 2024. URL htpp:://rxiv. org/ubx/2402.033300, 2(3):5, 2024.
Richard Sutton, David McAllester, Satinder Singh, and Yishay Mansour. Policy gradient meth- ods for reinforcement learning with function approximation. Advances in neural information processing systems, 12, 1999.
13

---

Published as a conference paper at ICLR 2026
Gemini Team, Rohan Anil, Sebastian Borgeaud, Sean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew Dai, Anja Hauth, Katie Millican, et al. Gemini: a family of highly capable multimodal models. arXiv preprint 2311v22312.1185,, 2023.
Gemma Team, Aishwarya Kamath, Johan Ferret, Shreya Pathak, Nino Vieillard, Ramona Merhej, Sarah Perrin, Tatiana Matejovicova, Alexandre Ramé, Morgane Rivière, et al. Gemma 3 technical report. arXiv preprint wrXiv:2503.19786 2025.
Junlin Wang. Jue Wang, Ben Athiwaratkun, Ce Zhang, and James Zou. Mixture-ote of-brre----ggg-ss-s--- enhances large language model capabilities. arXiv preprint arXiv:2406. N00:2446.00492,, 2024.
Peiyi Wang. Lei Li, Zhihong Shao, RX Xu, Damai Dai, Yifei Li, Deli Chen, Yu Wu, and Zhifang Sui. Math-shepherd: Verify and reinforce ilms step-by-step without human annotations. arXiv preprint ar www.::3322.0992.2 2023.
Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoe Le. Ed Chi, Sharan Narang, Aakanksha Chowdh- cry, and Denny Zhou, Self-consistency improves chain of thought reasoning in language models. arXiv preprint arXiv:2203. //171, 2022.
Jason Wei, Xuezhi Wang. Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc Le, Denny Zhou, et al. Chain-of-thougg prompting elicits reasoning in large language models. Advances in neural information processing systems, 35:24824-24837, 2022.
Colin White, Samuel Dooley, Manley Roberts, Arka Pal, Ben Feuer, Siddhartha Jain, Ravid Shwartz- Ziv, Neel Jain, Khalid Saifullah, Sreemanti Dey, al. Livebench: A challenging, contamination- limited I1m benchmark. arXiv preprint arXiv:2406. 02244066.9144 19314, 2024.
Juncheng Wu, Wenlong Deng, Xingxuan Li, Sheng Liu. Taomian Mi. Yifan Peng. Ziyang Xu, Yi Liu, Hyunjin Cho, Chang-In Choi, Yihan Cao, Hui Ren, Xiang Li, Xiaoxiao Li, and Yuyin Zhou. Medreason: Eliciting factual medical reasoning steps in llms via knowledge graphs, 2025.
URL https::///// /ttxxvivvvv.//////// org/ abs/ 200s/2500 250 4. 00993.
Chengyin Xu, Kaiyuan Chen, Xiao Li, Ke Shen, and Chenggang Li. Unveiling downstream perfor- mance scaling of llms: A clustering-based perspective. arXiv preprint arXiv:2502. 17262, 2025.
An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao. Chengen Huang, Chenxu Lv, et al. Qwen3 technical report. arXiv preprint arXiv:2505.099 09388. 2025.
Tianyu Yu, Bo Ji, Shouli Wang, Shu Yao, Zefan Wang, Ganqu Cui, Lifan Yuan, Ning Ding, Yuan Yao, Zhiyuan Liu, et al. Ripr: Extrapolating rlvr to general domains without verifiers. arXiv preprint arXiv:2506.182. 18254, 2025.
Yuanqing Yu, Zhefan Wang, Weizhi Ma, Shuai Wang, Chuhan Wu, Zhiqiang Guo, and Min Zhang. Steptool: Enhancing multi-step tool usage in Ilms through step-grained reinforcement learning. arXiv preprint arXiv:2410.07745 2024.
Xiang Yue, Tuney Zheng, Ge Zhang, and Wenhu Chen. Mammoth2: Scaling instructions from the web. Advances in Neural Information Processing Systems, 2024.
Yanwei Yue, Guibin Zhang, Boyang Liu, Guancheng Wan, Kun Wang. Dawei Cheng, and Yiyan Qi. Masrouter: Learning route 1lms for multi-agent systems. arXiv preprint arXiv:2502. 11133, 2025.
Mingchen Zhuge, Wenyi Wang, Louis Kirsch, Francesco Faccio, Dmitrii Khizbullin, and Jürgen Schmidhuber. Gptswarm: Language agents as optimizable graphs. In Forty-first International Conference on Machine Learning. 2024.
Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, et al. Bigcodebench: Bench- marking code generation with diverse function calls and complex instructions. arXiv preprint arXiv:2406. 15877, 2024.
14

---

Published as a conference paper at ICLR 2026
Table Completion tokens and reasoning budgets in the unconstrained setting
Model
Max Completion Tokens
Reasoning Budget
Gemini Pro 2.5
65535
32768
Claude Sonnet 4
64000
32768
GPT 5
128000
high
R1-Distill RLI-Ditill-Qwen-322 Qwen-32B
20480
N.A
Gemma-3-27b-it Qwen3-32B (thinking) Qwen3-32B
20480
N.A
20480
enabled
20480
N.A
A EXPERIMENTAL DETAILS
A.1 TRAINING SETUP
Model, optimizer, and training regime. We use Qwen2.5-7B (Hui et al., 2024) as our base model with max completion length 1024. We train for 200 iterations, sampling questions per iteration and generating 64 rollouts per question with temperature of 1.0. We use AdamW (Loshchilov & Hutter, 2017) as optimizer with 31 = 0.9, $2 0.999, e 0.2 and a base learning rate of 0.000001 with cosine scheduling and a warmup ratio of 0.03. We disable reference model synchronization and set the reference model KI. divergence penalty to O.
Agent settings. We set all agent workers to 4096 max completion tokens and decode with tem- perature 0.2. Reasoning budgets for the closed source models are set to their minima, which is 128 tokens for Gemini 2.5 Pro, 0 for Claude Sonnet 4, and 'minimal' for GPT-5. For Qwen3-32B (both non- thinking and thinking modes), we set their decoding parameters as top-p=0.8, top-k=20, and use presence penalty of 1.0.
Recursion. We train our Conduutor-Recursionn by taking our trained Conductor and finetuning for 20 iterations 350 sample filtered subset of our training dataset, comprising 175 Benchh and 175 RLPR questions. We continue with the same configuration of 64 rollouts per sample, amounting to batch size of 256, and use reference model synchronization KL divergence penalty. We use a discount factor of 0.25 to scale the rewards in the initial, non-recursive round and normalize rewards across rounds.
Compute resources. We train our Conductor on 2 NVIDIA H100 80GB GPUs.
A.2 DATASETS
We select the following tasks for training and evaluation both for their usage in other multi-agent works and for their difficulty and popularity in measuring frontier model performance. For instance, MATH500 is used in (Yue al., 2025) and MMLU is used in (Yue al., 2025; Chen al., 2024). We also note that we chose harder versions of popular benchmarks in multi-agent papers. For exam- ple, Yue al. (2025); Chen et (2024): Du al. (2023b) use GSM8K evaluate mathematical reasoning, and we chose the more challenging AIME25.
MMLU (Hendrycks al., 2020). massive multitask language comprehension dataset spanning 57 tasks, including history, law, sciences, and social sciences, among others, testing world knowledge and problem solving ability. All questions are multiple choice. The training data comprises 99842 samples and the test data comprises 14042 samples.
MATH500 (Lightman et al., 2023). A subset of 500 of the most challenging problems selected by Lightman et al. (2023) from the MATH dataset (Hendrycks et al., 2021). We construct train set of 300 samples and test set of 100 samples.
LiveCodeBench (Jain et al., 2024). This is the coding subset of the Live Bench (White al., 2024), which is a contamination free, continuously updated benchmark spanning 17 diverse tasks including coding, math, data analysis, and language among others. BiveCodeBench comprises leetcode-stye style code generation problems. We select the oldest version, version 1, as our training data, and the newest version (at the time of writing), version 6, for testing.
15

---

Published as a conference paper at ICLR 2026
RLPR (Yu et al., 2025). A non-mathematical, general reasoning dataset obtained subset from WebInstruct (Yue et al., 2024), where samples are filtered using GPT-4.1 to remove overly easy questions. The total dataset comprises 77700 samples, of which we take 46620 training data and 15540 as test data.
AIME25 (Mathematical Association of America, 2025). One of the most challenging and popular mathematical reasoning benchmarks, this dataset is the 30 questions used in the 2025 edition of the annual American Invitational Mathematics Examination. We use all 30 questions for evaluation.
GPQA-Diamond (Rein et al., 2024). This is the set of diamond difficulty problems on natural science taken from the Graduate-level Google-proof Q&A benchmark. The dataset comprises 198 problems in multiple-choice format. We use all 198 for evaluation.
BinCh (Zhuo et al., 2024). A challenging code generation benchmark focusing on diverse function calls and challenging instructions, We select the "hard" and "complete" subset, comprising 148 samples, which is specifically designed for code completion based on comprehensive doestrings. We use all 148 samples for evaluation. For all code evaluation we use the default gradio backend, hosted on the HuggingFace space'.
A.3 EVALUATION SETUP
Unconstrained setting. We refer to the setting in which we set the completion tokens and reasoning budget limits to their max as unconstrained. This is the setting with which we obtain our results in Section 4.2. Completion tokens and reasoning budgets are detailed in Table 3. In the case of Qwen3-32B (thinking), no budget is configurable, instead we simply select "enabled"". We make one exception to the max reasoning configuration in the unconstrained evaluation setup, which is for GPT-5 in BigCodeBench, where we evaluate GPT-5 at medium reasoning effort as opposed to high reasoning effort. This is due GPT-5's performance being marginally stronger under medium reasoning effort, which is in line with OpenAl's own findings regarding GPT-5 (OpenAI, 2025), in which for certain tasks medium may outperform high reasoning effort.
Constrained setting. For our evaluation in Section 4.3, we evaluate the Conductor under cost constraints (which we term constrained) in which all agent models are capped to 4096 output tokens and all reasoning budgets are set to their minima. The reasoning budget minima are "minimal", 128, and 0 and "disabled" for GPT 5, Gemini 2.5 Pro, Claude Sonnet and Qwen3-32B (thinking) respectively. Note this is the identical setting with which we train the Conductor.
We evaluate the Conductor with recursion (Section 3.2) using this same constrained setting to ac- commodate the fact the Conductor will be passed the final worker response as part of its context.
We evaluate AIME25 and GPQA-Diamond using Lighteval (Fourrier et al.) and BigCodeBench using the original source repository".
Baselines. Within the constrained setting, we evaluate against state-of-the-un multi-agent routing and scaffolding techniques, including MasRouter (Yue et al., 2025), RouterDC (Chen et al., 2024), Smoothie (Guha et al., 2024), and MoA (Wang et al., 2024) as seen in Figure and Table 7. We train MasRouter and RouterDC using the by sampling from the training dataset that train Conductor. We select the evaluation model based on best validation loss from a validation set which is of the same distribution, but independent of both the training and testing sets. Specifically, MasRouter is trained with a batch size 256 and validated every 5 iterations. We stop training early after seeing sufficient evidence of overfitting (i.e. 10% drop off in validation). RouterDC is trained on 500 samples, with each sample repeated 5 times to collect an average performance of every work on the given question. The collected average performance is used to compute the contrastive loss described in Chen et al. (2024). Smoothie is applied to test-time questions and outputs of each worker model with both dependent (selecting a model per question) and independent (selecting single model for all questions) strategies. MoA is also applied as test-time scaffold with a single MoA layer and single aggregator layer for total of 8 model calls. The aggregator model chosen at random. All baselines were compared against using the code and default settings provided by their respective authors.
used to
16

---

Published as a conference paper at ICLR 2026
Table OOD few-shot prompting boosts performance. Conductor performance is increasing in the proportion of few-shot examples it's provided with that are taken from unseen tasks.
Model
MATH500
MMLU
RLPR
LiveCodeBench
In-distribution
88.20
92.31
42.60
58.32
Mixed OOD and In-distribution OOD (Ours)
88.70
92.62
42.60
61.43
89.33
93.14
42.63
64.29
In all tasks, we report the best of either our own implementation or any existing online leaderboards that use the same configuration. In cases where we use an online leaderboard's 'ss reported score for any model, we then match that score's precision, hence why we report, for example, AIME25 and GPQA Diamond to I decimal place and BigCodeBench to 2 decimal places.
Performance improvement scale. We note that in our evaluation setup we focus on highly com- petitive reasoning benchmarks. such as AIME and GPQA-Diamond. Such tasks tend to have long-tailed distribution of difficulty (Xu et al., 2025) where breakthroughs a small subset of par- ticularly challenging problems could be representative of entire generational improvements in LLM reasoning. For example, the difference between two generations of GPT reasoning models, from GPT-o3 and GPT-5, is 3.3% AIME25' and 2.7% on GPQA-Diamond in absolute percentage terms. Moreover, the Conductor framework not only yields improvements in a single domain but across a diverse range of such highly challenging benchmarks, across math, coding, and natural sci- ence, something we believe particularly validates the meaningfulness of its advancements beyond the performance foundation frontier models.
B ADDITIONAL EXPERIMENTAL RESULTS
B. EFFICIENCY ANALYSIS
We present in Table 5 additional efficiency results for the Conductor in comparison with Claude Sonnet 4, Gemini 2.5 Pro, and GPT-5 using consensus inference-time scaling framework (Wang et al., 2022). We take MMLU as representative task, set the consensus sampling to 5 (in keeping with the Conductor's max allowable workflows of steps), and report average token usage per sample, average cost per sample, and cost adjusted performance (taken simply performance / average cost per sample in cents). We see the Conductor not only outperforms consensus, but additionally offers substantial efficiency gains in terms of token usage and average cost relative to this popular inference-time scaling technique.
Table 5: Efficiency comparison with 5x inference-time scaling (consensus vs. reflect).
Model
Performance
Token Usage
Avg. Cost Cost-adjusted Performance
Claude 5x consensus
91.00 90.66
1412.8
0.0211
42.94
Claude 5x reflect
2517.0
0.0208
43.58
Gemini x consensus
91.60
1658.4
0.01658
55.23
Gemini 5x reflect
88.33
2919.8
0.01675
52.70
GPT 5 5x consensus
91.30
1376.3
0.0138
66.34
GPT 5 5x reflect
91.79
2457.132
0.0142
64.42
Conductor
93.14
735.2
0.009
103.49
We present in Table 6 additional efficiency results for the Conductor in comparison with multi-agent baselines. We report average performance, token usage per sample, and average cost per sample, with averages taken over the four-way mixed training dataset of MMLU, RLPR, LiveCodeBench, and MATH500. We see that, in line with Figure 5, the low API calls of the Conductor translates
"Kaggle leadboard: http://wwwwg..coooooooo/////////
AAttificial Analysis leaderboard: https://shorturlalll..tt
17

---

Published as a conference paper at ICLR 2026
into substantive efficiency gains, attaining second lowest token usage and highly competitive cost efficiency while outperforming all other baselines by large margins.
Table 6: Efficiency comparison across multi-agent baselines.
Model
Performance
Token Usage
Cost
MoA
62.13
11203
0.04855
Smoothic
56.48
9909
0.03929
RDC
52.41
840
0.00561
MasRouter
56.89
4970
0.01345
Conductor
72.35
1820
0.02384
B.2 INFERRING AGENT COMPATIBILITY THROUGH OOD FEW-SHOT PROMPTING
As described in Section 3, supply the Conductor with few-shot examples of known, successful coordination strategies in order to condition the generative distribution of the pretrained language model to the orchestration task at hand, raising the probability of properly formatted completions at initialization.
We find, perhaps surprisingly, that Conductor performance is increasing in the proportion of few- shot examples taken from OOD tasks, where best performance is attained when all few-shot ex- amples are OOD, For example, we find that if training the Conductor solve coding problems, providing the Conductor with successful coordination strategies on non-coding tasks, such as math problems, boosts performance on coding tasks, even outperforming a setting which the Conductor is provided with successful coordination strategies on coding problems. This finding is empirically demonstrated in Figure and Table where we see clear separation throughout training and at final evaluation according to the proportion of OOD few-shot examples.
We posit that this behavior arises due to the fact that the tasks, by being OOD, prevent the Conduc- tor from exploitation of the provided strategies and better incentivize exploration of the coordination strategy space. this sense, the OOD few-shot examples help to deliver useful information regard- ing compatible combinations of agents, but isolate this information from reward-hackable strategy that can be lazily repeated.
B.3 PERFORMANCE DIVERSITY
Throughout our evaluation, we find, in line with existing leaderboards and surveys (Chang et al., 2024), that no single model reigns supreme over all tasks, with differing models excelling or strug- gling in differing tasks. Examples of this in our evaluation include GPT-5's strong performance in math and competitive coding (seen AIME and LiveCodeBench), while Gemini excels in scien- tific reasoning (GPOA-Diamond), Claude Sonnet struggles competitive coding (relatively weak in LiveCodeBencch, but is one of the dominant models at code generation with diverse function call- also prevalent at the granular "sub-task" level, where
ing (eigCodeBench). This specialization we often find the Conductor learns that different models are most useful as "planners" or "writers" answer particular kinds of questions. For instance, our SOTA performance in LiveCodeBench leverages Gemini 2.5 Pro and Claude Sonnet 4 working together as high-level planners and only later employs GPT-5 write the final optimized code, which far outperformed alternate strategies using GPT-5 in planning role that the Conductor attempted at early training iterations.
Furthermore, regarding 'weaker' open-source models, we even observed concrete instances where these models could fill roles and solve particular questions that their closed-source counterparts failed at. We note this was more prevalent at a subtask level, where using GPTS as the final valida- tor for several BigCodeBench questions would fail to adhere to the benchmark's 's strict formatting requirements, disregarded by this agent. In these instances, simply switching away to the much smaller Qwen3-32 or DeepSeek final validators would allow the Conductor succeed. While expectedly less common, we also found examples at the global "task level", with most such cases in RLPR and MML.U.
18

---

Published as a conference paper at ICLR 2026
Table 7: Self-reflection and multi-agent baseline comparison. The Conductor outperforms all multi-agent baselines and all individual worker agents, including when evaluated at 5x context length and 5x self-reflection.
Model
MATH500
MMLU
RLPR
LiveCodeBench
Avg.
Gemini Pro 2.5 (4K/128)
85,30 1.42
91.53 = 0.26
39.57
1.50
40.14 = 2.20
64. 14
Claude Sonnet 4
82.90 1.59
90.66 1 1.01
32.60
0.35
38.00
1 1.50
61.04
GPT (4K/minimal)
74.45
89.79 1
33.13
57.50
63.72
78.50 1.99
84,41 +: 0.87
32.75
+: 1.56
24.86 1 0.90
48.95
gemma-3-22 3-22bit
37.45 + 7.84
63.58 + 2.26
14.93 4.99
7.21 = 2.07
30.79
Qwen3-32B (reasoning)
76.85
1.79
83.28
+ 0.20
34.35
= 0.98
31.21
= 2.16
56.42
QwBn3-32B (direct)
73.15 2.25
84.02
30.60
0.82
26.79
53.64
5x Context Length
Gemini Pro (20K/128)
1.39
91.51 +: 0.24
39.57 1.50
$2.93 2.16
67.60
Claude Sonnet
82.20 1.54
86.93 + 0.54
32.42 = 0.81
37.93 = 1.18
59.87
GPT 5 (20K/minimal)
75.50 = 2.89
89.42 = 0.34
32.68
1.09
58.36 = 2.15
63.99
DeepScck-R1 R1-Distill-- Distill-Qwen-322 Qwen-32B
82.50 1.76
84.43 + 0.64
33.50
0.78
26.86 0.33
50.11
gemma-3-27b-it
39.80
81.28
16.67
2.70
13.14
37.72
Qwen3-32B (reasoning)
76.85 1.79
84.08 1 0.36
34.35
0.98
25.86
1.25
55.29
Qwen3-32B (direct)
73.50 2.14
83.54 1 0.40
31.00 1: 0.85
21.21
1.60
52.31
5x Self-Reflection
Gemini Pro 2.5
81.75 1.80
88.33 0.37
39.30 1.99
47.43 1.67
64.20
Claude Sonnet 4 GPT
83,66 1.74
+ 90.66
32.42
34.56
60.33
76.93 + 2.40
91.79 + 0.07
31.80 2.00
57.57 200
64.52
DeepSeek-RI-Diseee -I----tiD---------- Sesstll--wee-32BB
81.00 1.73
84.41 0.15
32.32 0.36
26.50 = 0.75
49.48
gemma-3 3-2m-i-
29.00 5.94
61.57 + 0.56
15.05 6.21
5.57 0.90
27.80
Qwen3-32B (reasoning)
76.00 2.65
83.60 + 0.51
35.90 0.26
32.71 2.30
57.05
Qwen3-32B (direct)
69.90 2.95
83.37 = 31.33 0.32
30.79 1.54
53.85
Scaffolding AAgreegation Baselines
MASRouter
80.60 0.89
86.28 + 2.77
32.80 = 4.77
27.86 = 3.24
56.89
MoA
83.10 :: 2.65
88.46 1 0.76
38.37
1: 0.95
38.57
1 3.50
62.13
RouterDC:
59.25 4.22
87.52 1: 0.06
27.53
2.22
35.33
2.34
52.41
Smoothie (Independent)
76.85
+ 83,28
34.35
0.80
31.21
-
56.42
Smoothie (Dependent)
76.95 2.06
83,56 + 0.27
34.45
- 0.67
31.00
2.04
56.48
Conductor (Ours)
89.33
93.14 +
42.63 0.65
64.29
72.35
B.4 CONTROLLED LARGE SCALE EVALUATION FULL RESULTS
We present in Table 7 the full numerical results for controlled large scale evaluation across all worker models and multi-agent baselines. For Smoothie, we train both a independent and dependent versions, where the independent version selects single model for all questions and the dependent versions selects a different model depending on the specific question. We report the best performing Smoothie variant in our Figure 4 in the main text in Section 4.
B.5 LARGE SCALE EVALUATION EXTENDED DISCUSSION
We note that on LiveCodeBench, the MoA baseline underperformed GPT-5, failing to leverage GPT-5's impressive capabilities. Examining the evaluation logs reveals the drop in performance is explained by MoA suboptimally using the candidate solutions of less capable models to inform the final response, or often being misled by the incorrect solutions other models. Indeed, we see that for other tasks where models are closer in capability, MoA performed better, but for Live- CodeBench where there is a high variance in performance, MoA struggled to discern the correct an- combination of answers among the 7 candidate responses. We note that this finding echoes the result obtained in Table 11. showing that sein-weight models can degrade the performance of the frontier models when combined suboptimally, with particularly marked performance drops in
19

---

Published as a conference paper at ICLR 2026
Table 8: Dut-of-Distribution evaluation under cost constraints. The Conductor continues to deliver performance gains when zero-shot transferred to new, unseen tasks.
Model
AIME25
BigCodeBench
GPQA-D
Avg.
Et-Distill-Qwen--22
30.00
24.3
51.01
35.10
gemma-3-27b-i
6.67
10.8
33.33
16,93
Qwen3-32B (thinking)
23.33
20.9
59.09
34,44
Qwen3-32B
23.33
23.0
54.05
33,46
Gemini Pro 2.5
46.67
35.1
75.25
52.34
Claude Sonnet
35.33
35.8
67.30
46.14
GPT 5
46.67
33.8
72.73
51.07
Conductor (Ours)
66.67
37.8
81.31
61.93
LiveCodeBench. We posit that this reveals a property of MoA, which performance depends in large part on the ability to discern correct from incorrect, which becomes increasingly challenging in tasks with very large solution spaces (for example writing optimized code).
One concrete example illustrating this point is the following example taken from MMLU. Here, the open-weight models produced incorrect reasoning and responses, ultimately leading to the incorrect selection: Many years ago, children who had good manners kept quiet their parents with other persons. Today, well-mannered children have more freedom. Sometimes good manners in one place are bad manners in other place../truncatter
talking
Which of the following sentences is not true according to the passage? Options: A. Well-mannered children should always keep quiet. B. Eating with others is bad manners. C. Good manners are different from one place another.D. People always want others to bother them. In this example, Gemini 2.5 Pro correctly identified C as the answer but the final response was misinformed by the erroneous reasoning of other responses.
Regarding MASRouter, we instead find that this baseline relies heavily on human-engineered scaf- folding techniques which require careful placements of selected models for specific roles. Therefore, when asked to make many specific decisions about model and role selection, MASRouter this frame- work can struggle to determine which models are best suited for each task. This issue especially evident when MASRouter is exposed to our wide pool of worker agents, where discovering the optimal combinations of agents and allocations of roles challenging. Additionally, the manually designed setup of MASRouter forces it to rely on fixed prompt templates and scaffolds to direct mod- els to solve problems, with limited generality beyond the domains was designed for. By contrast, the Conductor uses numan-designed fixed prompts, can leverage LLM's strong generalization properties and learn how to write custom focused subtasks that best leverage their capabilities for each question.
B.6 ZERO-SHIOT GENERALIZATION BOUNDED CONTEXT
We additionally provide experimental results for our Conductor when zero-shot transferred to unseen tasks and evaluated under the const constrained setting described in Section 4.3. We marked performance gains across all OOD tasks in this setting, mirroring our findings for the in-distribution setting presented in Section 4.3. We note in BigCodeBench the somewhat surprising result that Qwen3-32B outperforms Qwen3-32B (thinking). Analyzing the completion transcripts, we see that this performance decrease typically stems from added verbosity causing formatting failures. Indeed, this is similar to the situation observed in GPT-5, where medium reasoning effort outperformed high reasoning effort.
B.7 ABLATION STUDIES
We ablate the subtasks by retraining the Conductor with an alternate prompt, identical to 13, but with the requirement to generate subtasks removed. Instead, all models selected the coordination strategy are uniformly prompted with 'Solve the user question'. The Conductor is thereby trained only to work out optimal agent combinations and collaboration topologies.
20

---

Published as a conference paper at ICLR 2026
Table Ablations studies on subtasks, few-shot conditioning, and utilizing fine-grained com- plex topology specification
Model
MATH500
MMLU
RLPR
LiveCodeBench
fine-grained
88.67
93.55
42.28
61.24
w/o few-shot
82,00
92.69
41.50
54.86
w/o subtasks
88.5
92.75
41.95
58.62
Conductor (Ours)
89.33
93.14
42.63
64.29
Subtasks. We present results of the abla- tion in Table 9, where the ablation model is denoted w/o subtasks. We see consis- tent drop in performance across all tasks, with a particularly substantial drop in Live- CodeBench. This result reveals that necessity of careful and targeted prompt engineering is increasing in overall task complexity and, in particular, instruction complexity. Solving LiveCodeBench code- generation problems successfully typically require abiding by numerous constraints and formatting requirements, while ensuring code is accurate and runable. By contrast, MATH500, MMLU, and RLPR questions are typically just few sentences, meaning direct requests solve perform reasonably well.
0.10
c43
Indiutiibution
Nixed DCO and in decributtoo
Figure 9: OOD few-shot examples improve Con- ductor performance.
This therefore reveals a promising scope of application for the Conductor, namely that for increas- ingly difficult and task complexity, in which instruction following and abiding by constraints is of utmost importance, the performance gains accessible by the Conductor increase as well.
Agent selection. We ablate the agent selection produced by the Conductor by fixing all agents to a single powerful agent, GPT-5. We label this model "Conductor w/ all GPT-5'. We present these results in Table 10. We find the Conductor outperforms its "only GPT5" counterpart across the tasks, confirming that our model is indeed harnessing the differing capabilities of the diverse worker pool through its targeted agent selection. In particular, outperforms other closed source models such as AIME, the Conductor with all models matches the performance of its 'only GPT-5' variant, demonstrating that the agentic workflows designed deliver the maximum performance attainable by its best constituent model. In contrast, for tasks in which GPT-5 struggles GPQA-Diamond or BigCodeBBncch, the Conductor can leverage the performance of other, more capable agents, thereby allowing for significant performance improvements beyond its 'only GPT-5' variant. Nonetheless, is already consistently exceeding that of GPT, highlighting how both subtask design and harnessing collective intelligence are indispensable components to our framework.
that for tasks where GPT-5 already
do note that the performance of the 'only GPT-5' variant
Table 10: Conductor performance fixing all agents to GPT-5
Model
AIME
BigCodeBench
GPQA-D
Avg.
Claude Sonnet
74.30
37.16
77.70
63.0533
Gemini 2.5 Pro GPT-5 Conductor w/ all GPT-5
78.30
37.51
84.80
66.8700
90,80
32.75
82.30
68.6167
93.33
33.50
82.60
69.8100
Conductor
93.30
37.86
87.50
72.8867
Conductor ablation. We ablate the Conductor itself, replacing our trained Conductor with a pow- erful frontier model and instructing it to act task planner and coordinator, using our identical
21

---

Published as a conference paper at ICLR 2026
Table 11: Replacing our trained Conductor with GPT-5 and Gemini 2.5 Pro.
Model
ICB
AIME
BigCodeBench
GPQA-D
Avg.
GPT-5 conduct models
50.86
76.67
34.50
77.78
59.9525
GPT-5 conduct
67.43
93.30
33.10
86.36
70,0475
Gemini 2.5 Pro conduct
70.29
93.30
35.13
87.62
71.5850
Conductor
83.93
93.30
37.86
87.50
75.6475
prompting setup and overall Conductor framework. We assess three additional models for this ab- lation. The first, labelled "GPT-5 conduct 7 models", tasks GPT-5 to act as the conductor, allowing it to design coordination strategies of up to 5 workflow steps with access to the same full set of workers. The second and third labelled "GPT-5 conduct models" and "Gemini conduct models", further restrict the agent pool to only the best-performing large frontier models (GPT 5, Gemini 2.5 Pro, Claude Sonnet 4), as we noticed an over-reliance on open-source models in highly sub- optimal ways following preliminary experiments with "GPT-5 conduct 7 models" (for example by asking RI -diistll-Qwen--222 to act as a final checker before returning the solution to the user, often resulting in solution formatting failures).
To make sure these baselines performed at the best of their ability, we also incorporated an automatic resampling strategy whenever GPT-5 or Gemini produced format failure (with unlimited retry attempts) and doubled the conductor's original output token limit in order to make better use of their reasoning capabilities.
First, in Table 11 we note that the Conductor expectedly maintains its superior performance across tasks, confirming the effectivvness of our training strategy. In particular, both GPT-5 and Gemini appear over-reliant on an initial pool of models based on their prior biases, which fails to match actual downstream performance. A prime example of this is that the baselines fail to understand that Claude is less capable at LiveCodeBench or GPT-5 is less capable at BigCodeBench, leading to deteriorated performance without an effective feedback mechanism to adjust their knowledge misconceptions, provided by the Conductor's 's training phase. Second, we interestingly find that, despite having never been trained on these tasks, both "GPT-5 conduct models" and "Gemini conduct 3 models" outperform their constituent agents (GPT5 and Gemini) across numerous tasks, and their performance is also visibly superior to our much smaller base 7B Qwen model before any training. We believe this provides further evidence validating the Conductor's 's underlying hypothesis that powerful LLMs are inherently suitable to act as effective meta-orchestrators, highlighting the potential of harnessing future and or larger base models simple direction scale our new framework down the line.
Few-Shot examples. We ablate the effect of the few-shot examples provided the Conductor. In this setting, the Conductor prompt is as specified in Figure 13, but with the few-shot examples removed. This ablation serves isolate the effect of training Conductor with its generative distri- bution conditioned to the orchestration task versus training a Conductor with no prior over workable strategies. We find in Table 9 that few-shot conditioning yields substantial performance gains in the Conductor, with a consistent drop in accuracy across all tasks in the ablation model, denoted w/o Few-Shot. This result mirrors prior work SFT coldstarting O. where conditioning the generative distribution of the model before undergoing reinforcement learning has been widely observed to improve performance.
B.8 ALTERNATE COORDINATION TOPOLOGY
We evaluate the performance of the Conductor under alternate coordination topology specifi- cation scheme, in which the Conductor specifies, for each agent, which positions in the topology should be made visible. That is, rather than specifying all [] for each agent, the Conductor can additionally make visible the output of any agent at a position Hence, the Conductor could specify for some agent their context be comprised of the outputs of the agents the 0, 2, and 3 positions as [0, 2, 3]. This is therefore a generalization of our method, permitting the Conductor more fine-grained control over the composition of each LM agent's 's context as they attempt their subtask.
22

---

Published as a conference paper at ICLR 2026
Inbii distributoon
We present in Table the results of this alternate co- ordination topology specification scheme, denoted by the model Fine-grained. Promisingly, we find that the Conductor is able to learn to the alter- nate and more complex scheme effectively, discov- ering how to design tree and chain topologies with their corresponding subtasks. However, we find that ultimately more complex scheme does not produce significant performance gain,, and hence we opt for the simpler binary version presented in the main text of the paper. We leave revisiting the complex, fine- grained control over coordination topology to future work, where we hope that with larger and more intelligent Conductor beyond 7B, additional perfor- mance gains may be unlocked through discovery of powerful topologies.
Recursive distnibution
Figure 10: Recursive Conductor worker dis- tribution BigCodeBench. The Conduc- tor redistributes its agent selection towards Claude and Gemini in recursive rounds, flecting their superior performance.
B.9 TASK ADAPTIVITY
We show in Figure that the Conductor is task and difficulty adaptive, where the Conductor learns allocate more compute harder tasks and questions. We find that for hard tasks, such as Live- CodeBench code generation problems, the Conductor learns to allocate more compute to solving problems by devising more worker-intensive coordination strategies, often with multiple plan- ners and then final solvers and verifiers. By comparison, for relatively more straightforward tasks such as information extraction from text or factual recall, the Conductor is more likely to allocate fewer models, even 1-shot the problem in single step.
B.10 RECURSION REDISTRIBUTION
We plot the agent distribution for the Conductor when evaluated BigCodeBench and permitted to use recursion, as detailed in Section 4.4. We find that the Conductor is able to recognize the suboptimal performance of GPT5 on this task and adaptively redistribute its agent selection towards Claude Somnet 4 and Gemini 2.5 Pro. illustrating that the Conductor can adapt the coordination strategies learned in pretraining when unseen tasks necessitate
C CONDUCTOR SCHEMATIC
We provide visualization of our Conductor workflow in Figure 11. In the provided example, illustrate a task combining translation (between English and Chinese) and mathematical reasoning. The Conductor receives the request in Chinese, calls a Qwen model to first translate the request into English, before calling Gemini to solve the question. Concurrently, the Conductor passes the user question DeepSeek to solve in Chinese. GPT is called the end of the workflow to check both the English attempt by Gemini and the Chinese attempt by DeepSeek, before returning the correct solution in Chinese back the user.
D RECURSIVE SCHEMATIC
We show in Figure 12 our recursive extension to the Conductor detailed in Section 3.2. With re- cursion enabled, we allow the Conductor to call itself, providing itself the opportunity to revise the outcome of its previous coordination strategy. In the shown figure, we illustrate example in which the the Conductor begins with strategy calling two models, Qwen and Gemini, to first develop a closed form solution final response of this strategy, the Conductor adapts its strategy to call new model, DeepSeek, to numerical integration, obtaining the correct answer the user query.
integral before then applying the bounds. However, upon obtaining the
23

---

Published as a conference paper at ICLR 2026
User: 2 8 22 x y y (mod 7),
C
2 -F
Conductor: Transfate the question from Chineee into clear, netural English, keeping the details of the problem precise.
Conductor
S x.y y 2025 ( 7), 18 T- ?
Qwen32B: How many integer pairs satisfyx* +ooffxx++77 +y 2025 y (mod 7)?
User: ds Mi 18 y 2025 H. (mod 7), Ri
2 28 9474 ?
Conductor: Carefully provide a clear step-by-step solution before giving the finaa answer.
problem
Conductor (Swen SeepSeei Germee' GPT) #8:0:
Conductor: 0 -
86.5.09% (F (27),27),1-0 (-36,
27), (27. (-)) 36).
0998 38
DeepSeek Sawpkk:wwenn2BBB1em [.) 16:6
2:98 (36. 21), (6,277).
Gemini: L-]] pains: (36, -27).
(-36, 27), (27, (-27, 36).
Conductor: Carefully check and revise ettempt return
concise correct solution in Chinese.
Figure 11: Conductor schematic visualization. The Conductor combines the differing specializa- tions of the workers LLMs to answer complex user queries. Here we visualize a workflow bridging both mathematical reasoning and English-Chinese translation.
E CONDUCTOR PROMPT AND FEW-SHOT EXAMPLES
We show in Figure 13 our Conduc- tor prompt, which describes in full the Conductor's orchestration task. The components consisting of the subtasks, model ids, and access list defined the Conductor, along with the general scheme for how the nal response will be obtained from the final model. The available language models are passed the Conductor as purely ordinal numbers, e.g 'Model O, Model ...', in order to fully encour- age exploration of the possible models in the pool without possible bias from known model names. We additionally show in Figures 17 and 16 two samples provide
LATE Haagnaa Seatcc
Inagrata procdat Rasson
G
ragiae dellaate pet
Parle soch be bourdh sohe cuntion
Eindical lene and peccer
was crai art srunance with
Recurdve csll
Despdant emig fevieen
apprachro
Figure 12: Recursive Conductor visualization. At test time, the Conductor is able to adapt intial coordination strategies on-the-fly.
of the few-shot examples the Conductor to condition its genera- tive distribution to the required orches- tration task. These few-shot examples are real Conductor completions taken from coldstart training runs, and provided as part of the Conductor prompt. Figure 14 shows the recursion prompt, in which we permit the Conductor to devise new coordination strategy after viewing the outcome of its previous strategy.
Few-shot example details. As detailed in Section 4, we design our training set as combination of problems taken from MATH5000, LiveCodeBench, MMLU, and RLPR. Our OOD few-shot examples are taken from Medreason (Wu et al., 2025), DeepMath (He et al., 2025), and Countdown (Pan et al., 2025). We select just four examples, one from each of Medreason and DeepMath and two from Countdown, and select examples to ensure a range of workflow steps and selected agents to encourage exploration of the coordination space. Examples shown in Figure 17. For the In- Distribution few-shot setup, we again choose four few-shot examples, with from each of our component tasks, MATH500, RLPR, MMLU, and LiveCodeBench. Again, we select examples to balance workflow steps and agent selection encourage exploration. Examples shown in Figure
24

---

Published as a conference paper at ICLR 2026
Figure 13:
The Conductor prompt. Our Conductor prompt instructs the Conductor with the re- quired format for its output to be parseable as complete coordination strategy
Your role as assistant involves obtaining answers to questions by an iterative process of querying powerful language models, each with different skillset.
You are given a aser-provided question and a list of available numbered language models with their metadata. Your objective is to output sequence of up to 5 workflow steps.
Each routing is made three elements: language model, its assigned subtask accomplish, and an "access list" of past worklow steps see its context when trying to accomplish subtask.
A subtask could directly ask the language model to solve the given question from scratch, refine the solution of the previous subtask in the sequence, perform any other completely different task that would facilitate later language models the sequence to answer the original question their expertise.
Based your answer, the first model selected will be prompted with the user question and the first subtask you define. Euch following model in the sequence will be prompted with the history of the previous subtask and response messages specified its relative subtask. The answer of the final model and sublask will be provided back as the final solution to the user.
access list, and will asked to accomplish
Your response should be provided three Python lists.
The first list should be called model id, and contain the integers corresponding to the numbered language models in the sequence you want to prompt.
second should called subtasks, contain the strings that will used prompt corresponding language model specified in model
The third list should be called access Jist, and contain the lists of past routing messages (subtasks and assistant responses) from the previous routing steps include the context in the current routing step.
You can the string all for of the routing steps in access list to provide all the previous routing messages in the language model's contex. Alternatively, if you want agent attempt it's subtask withous any access previous routing steps, you can pass empty
For instance:
(few-shot examples}
USER QUESTION:
{user_question)
AVAILABLE LANGUAGE MODELS:
(available models}
16. For the semi-OOD setting, we balance in-distribution and OOD, taking one example from MATH500, one example from LiveCodeBench, one example from Countdown, and one example from Medreason.
EXAMPLE CONDUCTOR COMPLETIONS
We present in this section additional examples Conductor completions, exemplifying the Conduc- tor's capability agentic workflow coordinator. We provide examples including 1) the Conduc-
25

---

Published as a conference paper at ICLR 2026
Figure 14:
The recursive prompt. When allowing self-referential recursion, the Conductor views the response obtained from its previously designed coordination strategy and decides whether to iterate on its strategy or pass the existing response back to the user.
Here is the final response obtained the end of your routing steps:
[worker response)
You now have chance correct or improve this response outputting a new sequence of up to {max number of routing steps} routing steps, with the same format.
Once again, the goal is to produce final response that answers the original user question correctly. Now, if you pass the string "oll" for any of the routing steps in "access list", the previous final routing message will also included in the language model'ss contexts, together with the history of the previous subtask and response messages specified in your new access list.
In the previous final response obtained from your previous routing steps is already cor- rect, you can pass three empty lists for "modeljdd, "subtasks" ", and "accessJist" to return this the user as case you think the previous final response is incorrect need of verification, can devise a sequence of routing steps that will revise or verify the previous response.
tor recognizing the simplicity of problem and I-shotting it with single model (Figure 18), 2) the Conductor organizing the agents into a tree topology to take advantage of independently solvable steps (Figure 19), and 3) the Conductor allocating more compute to a hard problem (Figure 20).
We further illustrate in Figure 2 an example 3B completion which illustrates our claim Figure 7, that despite the 3B Conductor converging the same agent selection the 7B model, its less advanced reasoning capabilities produce less intelligent subtasks.
We additionally present example completions for when the Conductor is permitted to recursion (Section 3.2), in which we show an example of the Conductor recognizing the response obtained at the end of the initial coordination strategy looks satisfactory and thereby directly returns it (Figure 21) and an example the Conductor calling an additional agent to check through the past reasoning traces and revise the obtained response (Figure 22).
F.1 CONDUCTOR CATEGORIZATION
We present in this subsection categorization for some of the most frequent orchestration modes we tended to observe throughout Conductor training and evaluation. We note that these categories are rough, as the collaborative strategies employed by the Conductor are numerous and continue to grow as we evaluate the Conductor in new settings. Nonetheless, we observed frequently the following:
Sequential coordination with a high-level planner, followed by an executor, usually with additional models in between acting refiners and checkers (Figures 23, 24)
Tree coordination, where the first agents work independently and an additional agent ag- gregates the independent work (Figures 19).
Tree coordination, where the conductor recognizes the question depends purely on factual recall, and thereby does not necessitate any agent-to-agent collaboration (Figure 27).
Sequential coordination with a highly logical reasoning process, where each agent proceeds step-by-step to decompose a challenging multi-step problem (Figure 20).
Conductor task abdication (one of our personal favorites), where the Conductor passes its own role onto one the more powerful agent models, e.g, asking Gemini 2.5 Pro to come up with subtasks and direct the other models what do (Figure 28)
26

---

Published as a conference paper at ICLR 2026
Figure 15: Example 3B Conductor completion. The 3B model provides workable strategy, but suboptimally instructs the first model to hide their reasoning due to constraint provided by the user, impairing collaboration.
User
Solve the following math problem step by step: Let F(=) = z+i 2 for all complex numbers = & i, and 1) for all positive integers n. Given that zo 137 + i, find 22002- For your final
let 2n = F(2-11)
answer, follow these guidelines:
Provide ONLY the final result without explanations, equations, or steps For equations with a single solution, provide just the value (e.g.. '5' not 'x=5')
3B Conductor
Here's approach:
model id [0. 1.
subtasks 1"Solve the problem step by step and provide the final value of 22o02 without planations, equations, or steps in <idea>> tags. Use standard LaTeX notation for the final result.",
"Verify the proposed solution by reapplying the function F(z) check if it indeed leads to the result after 2002 iterations. Use '<idea> <fidea> to show your verification steps and present the final correct answer according the question' instructions.".
"Ensure the result is accurate and provide it in LaTeX notation instructed.")
access Jist [fI. a"lll",, ['all"),["all"" [I
This sequence divides the work:
1. Model 0 directly tackles solving the recurrence relation and providing the final value.
Model verifiex the result applying the function repeatedly confirm converges expected. Model ensures the accuracy of solution and formats according to the guidelines.
27

---

Published as a conference paper at ICLR 2026
Figure 16: In-distribution few-shot examples. The two few-shot examples provided are taken from MATH500 and MMLU.
EXAMPLE 1:
Question: Subject: Physics. converging lens placed 30.0 em to the right of diverging lens of focal length 10.0 cm. A beam of parallel light enters the diverging lens from the left. and the beam is again parallel when it emerges from the converging lens. Calculate the focal length of the converging lens.
Assistant Response: Given the simplicity of the problem and the required formatting. use two models that can handle physics calculations. Model 3 can perform the required physics calculation and determine the focal length of the converging lens based on the given conditions. "Suussequetll, Model 5 can verify the solution, format the result according the required guidelines, and return the final response.
model id [3.
subtasks ["Calculate the focal length of the converging lens and provide the final result in the required Show your working in <idea>> </idea< tags."
"Verify the solution proposed by the previous model and refine if necessary. Format the final answer in the required format, using standard mathematical notation and units."]
access list [11. ["alt"]
EXAMPLE
Question: Solve the following math problem step by step: palindrome is number that reads the same forwards and backwards. The sum of particular set of three consecutive positive integers is a three-digit palindrome. If the sum is less than 220, what is the greatest possible value for the largest of the three integers in the set?.
Assistant Response: We need least models to solve this. can use model first try and solve the question, model 2 can check if the answer is correct given the constraints, and then with the additional context, model 0 can finalize and re-attempt the problem if necessary.
model id [0,
subtasks = Fiidd a set of three consecutive positive integers whose sum is a three-digit palindrome smaller than 220 and calculate the largest of those nunbers.",
"Verify if the number found by previous agent largest set of three consecutive posi- tive integers whose sum is a three-digit palindrome smaller than 220.".
"Ensure the final answer is formatted correctly according to the rules and provide the neces- sary LaTeX representation.)
access list = [[] ['ll",, ""ll"",[""ll"" ["ll"]]
28

---

Published as a conference paper at ICLR 2026
Figure 17: Out-of-distribution few-shot examples. The two few-shot examples provided taken from deepmath and medreason, which are out-of- relative to the training tasks of MATH500, MMLU, RLPR, and LiveCodeBench.
EXAMPLE
Question: Does brain-derived neurotrophic factor enhance the contraction of intestinal mus- cle strips induced by SP and CGRP mice? Answer Choices: A. Yes B. No
Assistant Response: The user question about determining if brain-derived neurotrophic factor (BDNF) enhances the contruction of intestinal muscle strips induced by SP and CGRP in mice. This seems like straightforwwrl query that may not require iterative modeling it's about the availability of scientific data standard result from experimentation rather than problem solving or algorithmic implementation. The best approach will be directly ask each model to provide an answer, as the user question is likely based on known data rather than needing complex model-to modellll collaboration.
model id
subtasks = ("Does bruin-derived neurotrophic factor enhance the contraction of intestinal muscle strips induced by SP and CGRP in mice? Answer with A for Yes or B for No.".
"Does brain-derived neurotrophic factor enhance the contraction of intestinal muscle strips induced by SP and CGRP in mice? Answer with A for Yes or for No",
"Check the two previous answers and provide the correct answer according to the question's formatting instructions if necessary."
access list = [" ["all"]]
EXAMPLE 2:
Question: Evaluate the limit:
lim
In(1
+ t)
In(1 f)
Provide the final answer <answer>> <Janswer'> tags and use LaTeX notation.
Assistant Response: Given the difficulty of the question, let's try 4 models to solve this. The first two models can work independently to propose a limit tends to 0 by potentially using Taylor expansion, the third model can check the work the first Hopital's ' rule to confirm result, the final model can oversee entire process, handle final verification by confirming that all approaches point to the same conclusion and return the response the user.
models and optionally
model id 16, 5, 5,
subtasks (UUnderstand the question and provide an intial solution to approximate the limit tends to 0, potentially by using Taylor expansion. Show your work in <ideu> </idea>> tags."
"Understand the question and provide an intial solution approximate the limit as tends to O, potentially by using a Taylor expansion. Show your work in <idea> <fidea> tags.".
"Verify the work done by the first two models and optionally L'Hopital's rule numeri- cal methods to confirm the result. Show your work <idea> <fidea> tags.".
"Check the work of the previous models, refine where necessary and obtain the correct final answer. Provide the final onswer according the question' 's formatting instructions."
aisess.lstt [1]. []. ["all"), "aal"",["'all" ["all"]]
29

---

Published as a conference paper at ICLR 2026
Figure 18: Example Conductor completion with a I-shot strategy. In the following example, the Conductor recognizes the simplicity of the question and directly solves it with single model.
User
heartbroken dog whose owner died two months ago missing her much that he attends services every day at Italian church where her funeral was held, patiently waiting for her to return Tommy, a seven-year-old dog, belonged to Maria Lochi, 57, and had been her faithful partner after she udopted him when she found him in fields close to her home.
The dog Tommy still goes to the church every day
Options:
attend his owner's 's funeral
B. wuit for Lochi to come buck
C. stay together with Lochi
D. celebrate Mass with Father Panna
Conductor
This is straightforward comprehension and recall task from the given text, only need one model do that: First, comprehend and recall the information from the story provided for the dog Tommy, which requires an understanding of context and deducing Tommy's reason for going to the church. 2. Output the most accurate answer from the comprehension of the context.
model id [31
subtasks ""Deducee from the story provided the user question, why Tommy still goes the church every day to the most appropriate option among the given choices A, B, C, and D. Provide the option letter in <answer>> tags, for example <answer>> [JJnswer>>." access list [[]]
Figure 19: Example Conductor completion with a tree topology. The Conductor solves the prob- lem with two independent steps followed by an aggregation step, specified by its access list of [ [[],
(1, [*al1"]].
User
One ticket show costs $20 at full price. Susan buys 4 tickets using a coupon that gives her 25% discount. Pam buys tickets using a coupon that gives her 30% discount. How many more dollars doex Pum pay than Susan?
Conductor
1. We need to calculate how much Susan pays for her 4 discounted tickets (Model 1). 2. We need to calculate how much Pam pays her discounted tickets (Model 2). 3. We need determine the difference cost between Pam and Susan's 's tickets (Model 3).
model id 2, 31
subtasks = ""Calculate the cost of tickets at a 25% discount.",
"Calculate the cost of tickets at 30% discount.".
"Determine the difference in cost between what Pam and Susan paid for their tickets." "
aistssllstt [[], []. ["all"]]
30

---

Published as a conference paper at ICLR 2026
Figure 20: Example Conductor completion allocating more agents to solve a harder problem. In the following BiveCodeBench example, the Conductor devises extensive workflow utilizing all 5 possible workflow steps.
User
You given weighted simple connected undirected graph with N vertices and M edges, where vertices munbered 1 N, and edges numbered to M. Additionally, positive integer K is given. Edge (1 S S M) connects vertices u, and a weight of we For a spanning tree T of this graph, the cost of T is defined as the sum, modulo K. of the weights of the edges in T. Find the minimum cost of spanning tree of this graph.
The input given from Standard Input in the following format:
U1
V1
W1
Uhr
WMM
Print the answer
Conductor
The first model (Model 6) should understand the problem statement define the objectives.
2. The second model (Model 4) should analyze the given graph and its edges to understand the structure. 3. The third model (Model 5) should determine the sirategy to find the minimum cost spanning tree. 4. The fourth model (Model will implement the strategy Python function. 5. The final model (Model 2) validate implemented solution, ensuring meets all constraints and requirements.
model id 16, 2,
subtasks ("Understand the problem statement and goals. Define what needs to done to solve the given problem.",
"Analyze the graph structure and the constraints to identify key steps in the algorithm for solving the given problem.".
"Develop strategy to find the minimum cost of spanning tree with costs computed modulo K. Ensure the strategy can handle the input constraints.",
"Implement strategy a Python function to solve problem as defined, ensuring all constraints are met.".
"Validate and test the Python implementation ensure the solution is accurate and meets all requiremens.")
access list = [[]. [[ll)", ["al",, ["all"""""" ["ll"[]]
31

---

Published as a conference paper at ICLR 2026
Figure 21: Example Conductor-recurssvv completion, determining that the original coordina- tion strategy was already sound.
User
are given string of length consisting of lowercase English letters.
If there are any adjacent occurrences of and b in S. print Yes; otherwise, print No. order of and b does not matter.)
(The
Conductor
First, we'l Ill directly attempt to solve the problem. 2. Next, we' llll check and refine the solution if necessary. Finally, we' provide the most accurate and detailed solution, following all the given instructions.
model id [0, 1,
subtasks ("Transform the string into in exactly k operations and provide the number of to do so. Show work in <idea>> tags and present the final solution in janswery lags.",
"Check the proposed solution and refine it if necessary, ensuring all steps are correct and complete. Provide a detailed verification jidea tags and a final solution <answer>> tags.",
"Refine the solution further and provide detailed, accurate, and well-structured solution. Provide the solution in <idea>> and jansweri tags specified, and implement it in Python function named 'munberOfWass'""
access list 11]. "aal"",["all""
RESUIT OF COORDINATION STRATEGY:
Using the plan developed by the previous agents, can implement the function as follows:
from typing import List
class Solution:
def nunberOfWaystselff, str, str, int) >>
Conductor-recursive
The previous response provided correct and efficient solution. It seems well-reasoned and directly addresses the user's ss question with correct Python code. Given that the model's response correct and concise, I don't 't need to make any further atlempts or verify it. Therefore, will pass three empty lists to return the previous correct response to the user.
model. id subtasks = []
access list = []
32

---

Published as a conference paper at ICLR 2026
Figure 22: Example Conductor-reeursive completion, determining allocating additional agents to provide feedback and verify in the recursion round.
User
are given string of length consisting of lowercase English letters.
If there are any adjacent occurrences of and b in S. print Yes; otherwise, print No. (The order of and does matter.)
Conductor
First, we'll directly attempt to solve the problem. 2. Next, we' check and refine the solution if necessary. 3. Finally, we' provide the most accurate and detailed solution, following all the given instructions.
model 10, 1,
subtasks ["Take the string and devise an algorithm for counting adjacent occurrences of given letter. Show your work in <idea> tugs and present the final solution in <answer>> tags.",
"Check proposed solution and refine it if necessary. ensuring steps are correct and complete. Provide a detailed verification in <idea> tags and then implement the algorithm when applied to 'a' and 'b' in Python in <answer'> lags.",
"Refine the solution further and provide a detailed, accurate, and well-struetured solution. Provide the solution in <idea>> and <answer>> tags as specified, and implement a Python function named "mumberOfWass"")
list [[]. ["ll",, ["lll"]]]
RESULT OF COORDINATION STRATEGY:
Using the plan developed by the previous agents, we can implement the function as follows:
from typing import List
class Solution:
def munserOfWasssselff,. s: str. Is str, k: int) -> int:
Conductor-recursiie
The previous response seems to correct, as it handles the presence of "ab" or "ba" stripped input string 's'. However, to ensure robustness, I'll ask one model to previdffeeddbcck another verify the solution.
feedback and
model 1]
subtasks ['Verify the previous solution and provide your feedback in <idea>> tags. If cor- rect, directly return the solution. If incorrect, correct it and return the final code in <answer> tags.".
"Review the previous model's work, verify its solution, and provide the final correct answer according to the user requirements. Show your reasoning in jidea, tags and return the final code in <answer> togs."]
access list 11" [llalt" [all"]
33

---

Published as a conference paper at ICLR 2026
Figure 23: Utilizing a planner and coder in LiveCudeBench. In this LiveCodeBench problem, the Conductor leverages Gemini 2.5 Pro first act strategist and then GPT act coder.
User
There are cities in certain country.
will travel from your office in city to destination in city N, via zero or more cities.
Two types of transportation are available: company car and train. The time required to travel from city to city is as follows:
Conductor
First, need understond the problem and the transportation options available. Then need find the minimum time travel from city considering the various options. Finally need implement the solution in Python and ensure meets all the constraints and requirements. model id [0, 2]
subtasks [ ["Understand the problem and the transportation options available. Determine the strategy find minimum time to travel from city to city
"Implement the solution in Python according to the problem constraints and requirements and provide the final code in <answer>>agg, Show your work in <idea> tags if needed.")
access list [[].[["all"
34

---

Published as a conference paper at ICLR 2026
Figure 24: Comprehending, planning, strategizing, and finally coding with agents on Live- CodeBench. In this LiveCodeBench problem, the Conductor leverages Claude Sonnet 4 to first understand the objective and constraints, then Gemini 2.5 Pro strategizes and plans, before GPT-5 implements the final code.
User
are given 0-indexed integer array nums representing initial positions of some marbles. You are also given two O-indexed integer arrays moveFrom and move'lo of equal length.
After completing all the steps, return the sorted list of occupied positions.
Conductor
First, we need to understand the problem, its constraints, and the goal. Then, need come up with efficient strategy for how solve, Finally need write optimized code implementing the plan. model [1, 21
subtasks ("Understand the problem and determine the goal, which is implement func- tion that returns the total frequencies elements with the maximum frequency given array. Also, analyze the given examples and constraints to understand best approach.".
"Analyze the examples and constraints to find strategy for determining the elements with the maximum frequency and calculating their total frequency. Provide step-by-step plan in <idea'> tags."
"Implement the Python function 'maxFrequencyElemmnn following the strategy from the previ- step. Show your work in <idea>> tags and return the final code in <answer>> tags specified."
access list [[].["ll"]] J.[["all"
35

---

Published as a conference paper at ICLR 2026
Understanding the method, analyzing the data, then solving in MMLU. In this MMLU problem, the Conductor leverages Gemini 2.5 Pro and Claude Sonnet to analyze the data and methods, before handing over to GPT-5 to aggregate their work into the final response.
Figure 25:
User
Flying over desert an airplane, two scientists looked down with trained eyes at trees and bushes. After on hour's flight one of the scientists wrote in his notehook, "Look here for probable metal.".
The study of trees, branches and roots indicated that
Conductor
First, need understand the context and scientific method used by the scientists to locate minerals based the condition of plants and At the same we need analyze specific data provided about gold different parts of the trees to determine the correct answer. model id [0, 1,2]
subtasks ["Understand the scientific method used by the scientists locate minerals based tree and plant characteristies."
"Analyze the data collected from the trees, branches, and seeds to determine the gold distri- bution"
"Based on the methodology and the data, analyze which option correct and provide solution in <answer>> lags"]
access Jist ((..O.((""ll
36

---

Published as a conference paper at ICLR 2026
Figure 26: Factual recall makes use of tree topology. this Medreason problem, the Conductor explicitly recognizes that agent-to-agent collaboration is unnecessary, and relies instead querying models independently and aggregating to solve the answer.
User
Does brain derived neurotrophic factor enhance the contraction of intestinal muscle strips induced by SP and CGRP in mice?
Conductor
user question about determining if bruin-derived neurotrophic factor (BDNF) enhances the contraction of intestinal muscles stripes induced by SP and CGRP in mice. This seems like straightforward query that may not require iterative modeling its more about the availability of scientific data standard result from experimentation rather than problem solving or algorithmic implementation.
The approach will be to directly ask two models to provide an answer, as the user question likely based on known data rather than needing complex model-to-model collaboration. model id [0, 2, 1]
subtasks DDDes brain derived neurotrophic factor enhance the contraction of intestinal muscle strips induced by SP and CGRP in mice?",
"Does brain derived neurotrophic factor enhance the contraction of intestinal muscle strips induced by and CGRP mice?"
"Check the two previous answers to the user question and provide the correct answer ac- cording to the formatting instructions if necessary")
access Jist [[].0..["all"])
37

---

Published as a conference paper at ICLR 2026
Figure 27: Small models can help format check. In this BigCodeBench problem, we noticed GPT- making frequent formatting errors, providing additional information and hyerparameter choices in the dataframe title. Employing Qwen-32B as final format checker helped solve this problem and raise GPT-5's performance.
User
Create a Pandas DataFrame from list of pairs and visualize the data using a bar chart. The title of the barplot should be set to CCttegory Value". The function should output with:
Conductor
We' 'll have model plan the requirements for the visualization and how do the sampling, and a second to implement the code as required. 'Il use a final model ensure answer abides by the user's 's formatting requirements.
model id [0, 2, 3]
subtasks ["Consider the user question and plan the key aspects of the visualization. Use <idea> tags to show your working and ideas."
"Create the required Pandas DataFrame using the ideas provided by the first model. Provide your answer in <answer>> lags."
"Ensure the final code satisfies the exact user-provided formatting requirements and con- straints before returning the code back to the user."
list [[].["all),, [.[["alll"]
38

---

Published as a conference paper at ICLR 2026
Figure 28: Conductor role abdication. The Conductor abdicates its role subtask planner to Gemini 2.5 Pro, tasking it with devising subtasks for the other models to enact.
User
You are given an array nums consisting of positive integers. We call a subarray of an array complete the following condition is satisfidd:
The number of distinct elements in the subarray equal the number of distinct elements in the whole array...
Implement the function 'connCompleteSSaarrrys that solves this problem.
Conductor
We' need models with strategic and analytical skills to implement an efficient algorithm,, validate our logic, and handle Python code. Let's leverage Model (Analytical) dissect the problem and plan the subtasks. The other models will then follow these subtasks to solve the problem.
Based this, 1 have sequence three models that each will contribute solving the problem especially filling in algorithm and Python code.
model id 10, 1,
subtasks l'Analyze the problem, understand the constraints, and propose strategy solve the problem. Break down the subtasks step by step, including identifying necessary variahles and the logic involved.".
"Follow the plan and assigned subtusk provided by the first model"
"Based on the assigned subtask provided by the first model, identify any runtime errors or issues with the algorithm and return the final correct Python function to the user.)
access list [[].""lll) alll"
39


Reviews:
[{"review_id": "URJg6LMukD", "reviewer": "Reviewer_TwCE", "summary": "The paper proposes training a small (7B) Conductor model using reinforcement learning (RL) to orchestrate multiple strong LLMs for complex reasoning tasks. The model is trained using GRPO for 200 iterations. The experiments demonstrate that the Conductor achieves better performance on these reasoning tasks compared to any single model. Overall, the experimental results largely support the claim that the Conductor model improves reasoning performance in practice, although the margin of improvement is not always substantial.", "questions": "- The reward mechanism is described at a high level. Could you elaborate on the credit assignment? Is the final reward applied to the entire sequence of tokens generated by the Conductor? How does this scalar reward effectively train the complex, multi-step workflow generation?\n- The premise of the paper is that different models have specialized, complementary skills. Could you provide concrete examples of this from your experiments? For instance, are there cases where a generally \"weaker\" model (like Qwen3-32B) correctly solves a sub-task that a \"stronger\" model (like GPT-5) fails at, demonstrating true complementary specialization?\n- How much more computational cost (e.g., inference rounds or total tokens) does the Conductor framework introduce compared to the single-model / single-agent scenarios? A clear analysis of the performance-cost trade-off is needed.", "limitations": "", "rating": 2, "confidence": 3, "soundness": 3, "presentation": 1, "contribution": 2, "strengths": "- The core idea of using reinforcement learning to train a dedicated task planner/assigner (the \"Conductor\") is a potentially interesting direction to combine different models’ strengths.\n- The experimental results demonstrate that this approach is effective, showing performance gains over individual state-of-the-art models.", "weaknesses": "- **The presentation has significant flaws.** Some expressions are imprecise, lack formal explanations, or are unsuitable for an academic paper. For instance, the GRPO formula in Equation (1) appears to be incorrect, as it seems to be missing the clipping mechanism characteristic of PPO-style algorithms. Also, the paper frequently uses the term \"agentic workflows\" without providing a formal definition within the context of this study. This term is often over-used, and the authors need to clarify precisely what it entails in their framework. Several other key terms are left undefined or used imprecisely. For example:\n    - What do the authors mean by the \"latent capability\" of LLMs (line 37)?\n    - What constitutes the \"unconstrained\" setting for evaluation (line 267)?\n- **The motivation for training a separate Conductor model is not fully convincing given the experimental results.** While Table 1 and Figure 4 show that the Conductor improves upon the best single agent (model), the performance foundation clearly comes from the powerful frontier models it orchestrates (e.g., GPT-5 achieves 90.8 on unseen task AIME25, while Conductor reaches 93.3). The marginal gain seems small. This raises a critical missing baseline: what is the performance of a strong model (like GPT-5 or Gemini 2.5 Pro) when simply prompted to act as the task planner and assigner? Furthermore, the results for other multi-agent baselines in Figure 4 are confusing. Why do established frameworks like MoA and MASRouter show results inferior to a single-agent Gemini 2.5 Pro? Were these baselines tested with the same powerful set of worker models as the Conductor? This needs clarification to fairly assess the Conductor's contribution.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "VoDjvWvifc", "reviewer": "Reviewer_5Z3X", "summary": "This paper introduces a conductor model trained with RL to \"orchestrate\" between different underlying LLMs to perform work. The conductor attains SOTA on reasoning benchmarks and outperforms all component models. The authors also enable online recursive adaptation of the conductor agent. This unlocks a new form of dynamic test-time compute scaling.", "questions": "What is the \"non-trained\" baseline (e.g., BoN/pass@)? What is cost-normalized performance?", "limitations": "", "rating": 8, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 4, "strengths": "This is an excellent paper. The training setup is sound and the conductor is trained end-to-end with RL. This strategy unlocks new SoTAs on top reasoning benchmarks. The training setup also clearly observes novel strategies from the conductor (e.g., having sub-LLMs validate each other's outputs and plan with each other). There are a number of ablations to prove robustness and follow-ups to results, and many of them have interesting results of their own (e.g., showing the impact of spending more agents on harder tasks). Figures are clean. Examples are thorough.", "weaknesses": "It is unclear if these techniques improve performance compared to other test-time-compute strategies (e.g., pass@k, best-of-N, consensus, or other heavily prompted setups to increase test-time-compute put into solving the same problem). Because the incremental lift from this strategy seems relatively small, this paper would be significantly strengthened by including comparisons to other test-time-compute strategies to show that it's worth it compared to e.g., pass@k/BoN/cons/prompting/etc.\n\nMoreover, it would be useful to understand \"cost-normalized\" performance; quantitatively, much more latency and cost is incurred from using this strategy and is it worth the performance gained? There is a plot with number of agent calls but latency in terms of time/tokens and cost in terms of actual API pricing or equivalent would be much more interpretable here to baseline the tradeoff needed to get the performance wins.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "ROn0QfMSlZ", "reviewer": "Reviewer_c7Bs", "summary": "The paper presents a major conceptual step: turning a small LLM into a meta-agent that learns to orchestrate larger, specialized LLMs through reinforcement learning. Instead of directly solving problems, the Conductor learns to design agentic workflows—decomposing tasks into subtasks, assigning them to specialized worker models, and defining how agents communicate and share context.\nIt establishes new SOTA reasoning results on tasks such as LiveCodeBench, GPQA-Diamond, and AIME 2025 and introduces a flexible, extensible framework for autonomous multi-agent coordination via language.", "questions": "Typos:\n- Line 200 \"to its own parent output\"\n\nQuestion:\n\n- How sensitive is the Conductor’s learning to the choice of reward granularity (binary correctness vs. partial credit or verification-based rewards)? Would denser reward shaping improve stability or lead to different emergent strategies? What reward strategies have you guys tried? I am generally really curious about this. \n\n- What are the different modes of orchestration the Conductor learned? Did you guys do some simple categorization?", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 4, "contribution": 2, "strengths": "- While prior work (e.g., Mixture-of-Agents [Wang et al., 2024], or Smoothie [Guha et al., 2024]) explores routing or fixed multi-agent topologies, this work chooses to learn such coordination end-to-end using pure reward maximization, without predefined roles or handcrafted scaffolds.\n- The idea of recursively calling itself as part of the agentic workflow is interesting and open pathways for further studies.\n- The empirical results are strong, beating top frontier models.\n- I like the in-domain and out of domain analysis. Really put things in perspectives. It is nice to know that Conductor is not just overfitting on specific task or formats.", "weaknesses": "```One concern I have is whether the benefits from Conductor came from orchestration or agentic workflow planning, or purely prompt engineering?```\n\nThe Conductor orchestrates the agentic flow with respective subtasks. And RL is used to train the model to do better at this task which can be roughly divided to two tasks: 1) manage and assign the best match between model and tasks. 2) create better subtask directions/prompts. There is no ablation that fixes 1), that is, use only one model (like GPT-5) and then train Conductor with RL. If Conductor is still doing pretty well, that means benefits from orchestrating is minimal. I would highly suggest doing such an ablation which would make your case a lot stronger. \n\n```The tasks themselves are not very multi-agent dependent```\n\nTasks like Math500, AIME or LiveCodeBench are not really suitable tasks for multi-agent. Ideally, a multi-agent task or a task where multi-agent can have some leverage or just single agent are tasks that naturally can be divided to subtasks that are heterogenous. I don't find these tasks to have those properties. Like do you write first part of the math solution and then write the second part using another model? I saw some examples where Conductor ask models to refine or verify. But those are not really something that a model have specialty in. The task selection is a bit off.\n\n```Lack of other benefits```\n\nTo continue from last point. A weird task selection would cause the benefit of multi-agent to diminish. Multi-agent frameworks comes in with three big pros -- efficiency, safety and performance. There is no efficiency benefits for this because everything is sequential and one model has to wait for last model to finish (correct me if I misunderstood). This limits the contribution of the Conductor. I would love to see such a pipeline work in a meaningful agentic setup.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "RF6eM0pMq6", "reviewer": "Reviewer_og9K", "summary": "This paper introduces the conductor, which can automatically divide the task and assign subtasks to different models, and a method to training the conductor with RL. With the conductor, small LLMs surpass large LLMs on multiple tasks.", "questions": "N/A", "limitations": "", "rating": 8, "confidence": 2, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "- The concept of conductor is novel. The workflow is fully automatic and doesn't need human's design.\n- The quantitive result is promising.\n- The extra analysis is detailed.", "weaknesses": "N/A", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)