PaperlayerView exact revision on arXiv

Source-linked AI summary

AgentConductor: Topology Evolution for Multi-Agent Competition-Level Code Generation

Siyu Wang, Ruotian Lu, Zhihao Yang, Yuchao Wang, Yanzhou Zhang, Lei Xu, Qimin Xu, Guojun Yin, Cailian Chen, Xinping Guan

arXiv:2602.17100v1cs.MA

TL;DR

Fixed interaction topologies limit adaptive coordination in multi-agent code generation. AgentConductor uses reinforcement learning and execution feedback to evolve difficulty-aware, density-controlled topologies, achieving state-of-the-art accuracy across five code benchmarks, including a 14.6-point pass@1 gain.

  • Problem

    Existing multi-agent code-generation systems typically rely on fixed interaction topologies rather than adapting coordination to task demands.

  • Method

    AgentConductor trains an LLM orchestrator with reinforcement learning to generate and iteratively refine density-aware layered DAG topologies using execution feedback.

  • Results

    14.6 percentage points: AgentConductor outperforms the second-best method on APPS pass@1 accuracy and reports state-of-the-art results across multiple code benchmarks.

  • Takeaways & Limitations

    The approach advances multi-agent code generation toward systems that are accurate, cost-efficient, scalable, and adaptable across problem difficulties.

Abstract

from arXiv · show

Large language model(LLM)-driven multi-agent systems(MAS) coordinate specialized agents through predefined interaction topologies and have shown promise for complex tasks such as competition-level code generation. Recent studies demonstrate that carefully designed multi-agent workflows and communication graphs can significantly improve code generation performance by leveraging collaborative reasoning. However, existing methods neither adapt topology density to task difficulty nor iteratively refine the topology within an instance using execution feedback, which leads to redundant communication and performance bottlenecks. To address these issues, we propose AgentConductor: a reinforcement learning-optimized MAS with an LLM-based orchestrator agent as its core, which enables end-to-end feedback-driven dynamic generation of interaction topologies. For each query, AgentConductor infers agent roles and task difficulty, then constructs a task-adapted, density-aware layered directed acyclic graph (DAG) topology, underpinned by two key innovations. First, we design a novel topological density function that captures communication-aware mathematical characterizations of multi-agent interactions. Second, we adopt difficulty interval partitioning to avoid excessive pruning for precise topological density upper bound measurement per difficulty level and finer-grained control. Empirically, across three competition-level and two foundational code datasets, AgentConductor achieves state-of-the-art accuracy, outperforming the strongest baseline by up to 14.6% in pass@1 accuracy, 13% in density reduction, and 68% in token cost reduction.

1. Introduction

AgentConductor addresses the limitations of static or insufficiently task-adaptive multi-agent topologies for competition-level code generation. It uses an RL-optimized LLM orchestrator to generate difficulty-aware, density-controlled layered DAGs that evolve through execution feedback.

  • Motivation: Competition-level programming requires deep problem understanding, sophisticated reasoning, and robust algorithmic expertise across widely varying difficulty levels.
  • Limitations of Existing Methods: Existing pruning and generation methods can reuse topologies across instances, causing task mismatch, degraded performance, or inefficient communication.
  • Topology Design: The proposed layered DAG supports intra-layer parallelism and cross-layer interactions, unlike chain, adjacent-layer, or locally branching tree topologies.Its topology is represented in a human-readable format that agents can directly generate.
  • AgentConductor: AgentConductor is an RL-optimized multi-agent system centered on an LLM orchestrator that generates difficulty-aware interaction topologies through multi-turn execution feedback.The orchestrator is first supervised-fine-tuned to learn priors over interaction graphs.
  • Optimization Objective: AgentConductor introduces a layered-DAG density function and multi-objective reward balancing structural correctness, code accuracy, and difficulty-aware density under task-specific constraints.
  • Results: Experiments on competition-level and foundational code benchmarks report state-of-the-art performance with higher accuracy, lower average density, and reduced cost than existing methods.

2. AgentConductor

AgentConductor uses an RL-optimized orchestrator to generate and iteratively update difficulty-adapted layered DAG topologies for multi-agent code generation. Its topology design explicitly models graph complexity and calibrates communication density to reduce unnecessary reasoning and token usage.

  • Orchestrator Training: The orchestrator is trained with supervised fine-tuning followed by trajectory-based reinforcement learning using multi-turn execution feedback.This training enables topology generation and subsequent updates in response to execution outcomes.
  • Task-Adaptive Topology: For each programming problem, the orchestrator estimates difficulty, selects suitable roles, and generates a matching interaction topology.The multi-agent system then executes according to the generated topology and receives execution feedback for refinement.
  • Topology Representation: The interaction topology is a human-readable YAML improved layered DAG supporting intra-layer parallelism, cross-layer connections, and multi-turn evolution.Nodes represent agent instances, while the orchestrator generates and coordinates the complete topology.
  • Dynamic Generation: Topology density is calibrated to inferred task difficulty, producing variable-length YAML sequences that reduce superfluous reasoning and token usage.At each turn, execution feedback is appended to the history and conditions the next topology generation.
  • Topology Complexity: Graph complexity is evaluated through node count, edge density, and graph depth, capturing token cost and system parallelism.The normalized complexity score contributes to the reinforcement-learning trajectory reward.
  • Difficulty-Based Bounds: 4, 7, and 10 nodes are the per-turn upper bounds for the three difficulty levels in the interaction-graph complexity reward.These bounds are obtained through statistical analysis and constrain topology density by difficulty.

3. Experiments

Experiments evaluate AgentConductor on five code-generation datasets using pass@1, topology density, and token cost, with comparisons against single-agent, classical multi-agent, and workflow-optimization baselines. AgentConductor achieves the highest accuracy across all datasets, adapts topology density to difficulty, and improves cost efficiency through sparser easy-instance graphs and denser hard-instance graphs.

  • Baselines and Metrics: AgentConductor is compared with GPT-4o-mini, classical multi-agent systems, and workflow-optimization methods across performance, topology density, and cost.The APPS case study reports Prompt Tokens, Completion Tokens, and average Scomplex, where larger Scomplex values indicate sparser topology density.
  • Accuracy: AgentConductor achieves the highest accuracy across all five evaluated code-generation datasets.The evaluation covers HumanEval, MBPP, APPS, LiveCodeBench (V4), and CodeContests, with code executed in a secure sandbox and performance measured by pass@1.
  • Accuracy: 58.8%, 46.3%, and 38.8% pass@1 on APPS, LiveCodeBench (v4), and CodeContests exceed second-best methods by 14.6%, 3.1%, and 1.1% percentage points, respectively.On basic tasks, AgentConductor reaches 97.5% on HumanEval and 95.1% on MBPP, surpassing second-best methods by 1.0% and 0.7% percentage points, respectively.
  • Difficulty Adaptation: AgentConductor uses sparser graphs for easier instances and denser graphs for harder ones, reducing easy-case token cost while preserving hard-case accuracy.Competing methods show little or no density adaptation across difficulty, causing unnecessary token expenditure.
  • Ablation Studies: The YAML-format error reward most strongly affects valid-topology rate, while the code-execution error reward most strongly affects code accuracy measured by pass@1.Topology-density sub-rewards Snode, Sedge, and Sdiameter affect density control and accuracy to different extents.

5. Conclusion · A. Supplementary Experimental Setup · A.1. Supplementary Details on Baselines

AgentConductor presents difficulty-aware reinforcement learning with multi-turn, execution-feedback topology evolution for adaptive multi-agent code generation. The supplementary setup compares against single-model and multi-agent baselines under aligned roles, prompts, and bounded topology sizes.

  • 5. Conclusion: AgentConductor trains an orchestrator to dynamically generate and refine interaction topologies using execution feedback and density-aware rewards.This enables fine-grained adaptability across problem difficulties.
  • 5. Conclusion: The method integrates difficulty-aware reinforcement learning with multi-turn topology evolution for competition-level code generation.The conclusion frames this integration as a new paradigm for multi-agent code generation.
  • A.1. Supplementary Details on Baselines: The baseline comparison includes Vanilla, represented by the single GPT-4o-mini backbone model.Vanilla reflects the capability of a single backbone model.
  • A.1. Supplementary Details on Baselines: Classical multi-agent baselines include AutoGen, MetaGPT, and MapCoder-style frameworks for general-purpose or coding-oriented tasks.The supplied setup identifies AutoGen as general-purpose and MetaGPT as designed for generic coding tasks.
  • A. Supplementary Experimental Setup: For multi-agent baselines, the evaluation aligns role definitions and system prompts with those used by AgentConductor.This alignment controls differences in agent roles and prompting during comparison.
  • A.1. Supplementary Details on Baselines: 20 participating agent nodes is the maximum for workflow and topology optimization baselines, matching AgentConductor’s density upper bound for the most challenging problems with up to two interaction turns.The setup uses this bound to support a fair comparison.

A.2. Implementation Details

AgentConductor uses Qwen2.5-3B-Instruct as its backbone and is fine-tuned with LoRA through LLaMA-Factory on synthetic contest-level code-generation data.

  • A.2. Implementation Details: AgentConductor uses Qwen2.5-3B-Instruct as its backbone and LLaMA-Factory for supervised fine-tuning.The fine-tuning uses LoRA-based adaptation.
  • A.2. Implementation Details: 4,500 synthetic samples from three contest-level code-generation datasets and three difficulty levels support training.Training uses an initial learning rate of 1 × 10−4 and batch size 4.

A.3. Progressive Quality Filtering for SFT Data · A.4. System Prompt for Orchestrator Agent · B. Additional Experimental Results

The supplied passages describe progressively filtered SFT data built from valid executable topologies and a system prompt for the trained orchestrator agent. No passage content is provided for the additional experimental results section.

  • A.3. Progressive Quality Filtering for SFT Data: A.3 Progressive Quality Filtering for SFT Data: Training examples are valid, executable, and semantically correct topologies generated by GPT-4o-mini for code-oriented tasks.They use the orchestrator’s role configuration and topology density constraints.
  • A.3. Progressive Quality Filtering for SFT Data: A.3 Progressive Quality Filtering for SFT Data: Second-turn topologies come from actual error messages and historical multi-agent logs rather than synthetic approximations.The passage characterizes these structures as real and valid.
  • A.3. Progressive Quality Filtering for SFT Data: A.3 Progressive Quality Filtering for SFT Data: Strict YAML syntax verification removes malformed or incomplete examples before dataset inclusion.The check ensures examples are well-formed, standard-loader parsable, and safely convertible into JSON objects.
  • A.3. Progressive Quality Filtering for SFT Data: A.3 Progressive Quality Filtering for SFT Data: JSON SCHEMA validation checks each converted topology against predefined orchestration constraints.The supplied rules require empty first-timestep ref fields and references only to agents from earlier timesteps.
  • A.4. System Prompt for Orchestrator Agent: A.4 System Prompt for Orchestrator Agent: Figure 6 presents the system prompt for the orchestrator agent.The figure is identified as showing that prompt.
  • A.4. System Prompt for Orchestrator Agent: A.4 System Prompt for Orchestrator Agent: The trained orchestrator agent’s system prompt is shown in the figure.This passage reiterates the figure’s purpose.

B.1. Code Generation Performance Analysis

AgentConductor’s performance analysis places fixed-scheme MetaGPT second-best on average, while end-to-end reinforcement learning methods narrowly trail it and topology optimization methods underperform. During reinforcement learning, the method progressively converges toward reasonable topology density and accurate code problem solving.

  • Comparative performance: MetaGPT achieves the second-best average performance among the compared methods despite using a fixed interaction scheme.It is described as a code-oriented multi-agent framework.
  • Comparative performance: FlowReasoner and Chain-of-Agents rank next among optimization-oriented approaches and narrowly trail MetaGPT in average results.Both are end-to-end reinforcement learning methods.
  • Comparative performance: Topology optimization methods underperform, likely because their learned topologies remain comparatively rigid and struggle with highly variable tasks.
  • Training dynamics: During reinforcement learning, training reward, valid two-turn topology count, and validation reward indicate progressive convergence toward reasonable density and accurate code problem solving.The convergence occurs in later training stages.

B.2. Analysis on the RL Training Curve · B.3. Case Study

The RL training curve shows steady gains in reward, density-check feasibility, and validation score, indicating stable progress. The case study shows problem-tailored initial topologies with difficulty-dependent density and execution-feedback-driven second-round adjustments.

  • B.2. Analysis on the RL Training Curve: All three tracked metrics increase steadily across the first 110 RL training steps.The metrics are average reward, the count of topologies passing the density check, and validation score.
  • B.2. Analysis on the RL Training Curve: The concurrent upward trends indicate that the self-critic RL procedure is stable and makes consistent progress.
  • B.3. Case Study: The figure presents generated interaction topologies for two problem cases at each difficulty level.
  • B.3. Case Study: Initial interaction topologies differ across problems and are tailored to individual problem characteristics.
  • B.3. Case Study: Initial topology density varies according to task difficulty.
  • B.3. Case Study: The method dynamically adjusts the second-round topology using first-round execution results.
  • B.3. Case Study: Second-round adjustment does not necessarily reduce the number of agents, because additional agents may be introduced.

B.4. Zero-Shot Transfer to Unseen Roles and Task Types

AgentConductor’s orchestrator transfers without additional training to unseen textual task types and newly introduced roles, integrating them into interaction topologies and achieving a 15.8% success rate on selected GAIA samples.

  • Unseen Roles: Without additional training, the orchestrator integrated unseen online searcher and visual checker roles into generated interaction topologies.The roles were added with corresponding tool interfaces despite never appearing during SFT or RL training.
  • Evaluation: 15.8% success rate was achieved on 50 filtered single-modality textual GAIA samples under strict zero-shot transfer.These tasks differed substantially from the code-generation domain used for training.
  • Generalization: The results indicate non-trivial generalization to unseen domains, task types, and agent capabilities.This conclusion follows from the strict zero-shot evaluation on GAIA samples.

B.5. Supplementary Cross-Domain Experiments · C. Detailed Definitions of Topology Notions · C.1. Algorithm Workflow of AgentConductor

AgentConductor generalizes beyond competition-level code generation through role-adapted, feedback-trained orchestration, while its formalism defines typed agents, communication edges, layered DAG execution, and iterative topology regeneration. The workflow uses execution outcomes and topology traces to decide which agents to reuse, rerun, or activate until success or a turn limit.

  • B.5. Supplementary Cross-Domain Experiments: AgentConductor’s cross-domain evaluation expands the orchestrator with searcher, thinker, verifier, and planner roles for reasoning-centric tasks.The roles are implemented after applying Chain-of-Agents’ role definitions and data filtering strategy to subsets of GAIA, HLE, and PopQA.
  • B.5. Supplementary Cross-Domain Experiments: The cross-domain reward retains YAML validation and topology density while replacing code execution with binary LLM-based answer validation.Correct answers receive 1 and incorrect answers receive 0; other training and inference settings remain unchanged.
  • B.5. Supplementary Cross-Domain Experiments: AgentConductor outperforms Chain-of-Agents across the evaluated datasets despite using a smaller 3B versus 7B backbone.The reported results also show strong accuracy and low variance across three seeds, supporting robustness and transfer beyond code generation.
  • C. Detailed Definitions of Topology Notions: Agent nodes comprise an orchestrator, role-assigned LLM-agents, and ToolAgents equipped with callable external APIs.The orchestrator generates multi-turn YAML topologies and manages execution, while ToolAgents can provide retrieval or code-execution capabilities.
  • C. Detailed Definitions of Topology Notions: Communication edges are categorized as intra-turn dependencies, inter-turn cross-agent dependencies, and automatically added inter-turn self-edges.Self-edges let an agent incorporate and refine its own previous outputs across consecutive turns.
  • C. Detailed Definitions of Topology Notions: Each turn decodes the orchestrator’s YAML plan into a strict layered DAG whose same-step agents execute in parallel without intra-step edges.The node set is instantiated with LLM-agents and ToolAgents, and execution follows the DAG’s layer order.
  • C. Detailed Definitions of Topology Notions: After each turn, a tester returns PASSED or an execution error, and failures trigger topology regeneration using errors, logs, and the topology trace.The orchestrator decides which agents to reuse from memory, rerun, or activate, continuing until PASSED or the maximum number of turns K is reached.
  • C.1. Algorithm Workflow of AgentConductor: Algorithm 1 concludes the paper’s overall AgentConductor workflow.The workflow is presented as the culmination of the preceding topology definitions and execution process.

C.2. Theoretical Derivation and Proof of Topology Density … D.2. Reinforcement Learning Objective for Generating Topologies with Adaptive Complexity

The paper derives topology density from agent count, communication structure, and coordination depth, then defines role-specialized agents and trains topology generation with execution-feedback rewards and a clipped, KL-regularized objective. The resulting framework adapts interaction complexity to task difficulty while optimizing code-test performance.

  • C.2. Theoretical Derivation and Proof of Topology Density: Topology interaction cost is characterized by agent count N, edge density, and graph depth d, capturing fixed overhead, message passing, and coordination latency.The method links these graph properties to operational cost and uses depth-aware complexity rather than communication structure alone.
  • C.2. Theoretical Derivation and Proof of Topology Density: For a manager-guided DAG with b parts, Theorem 1 establishes d(k) = b; when layers lack interactions, the method uses s to measure effective graph depth.The proof bounds every path by b vertices, while the exceptional measurement accounts for additional response time caused by independent layers.
  • C.3. Detailed Definitions of Multi-Agent Roles: AgentConductor uses six specialized agent types, with a Managing Agent selecting necessary agents during each code-generation round.The pool supports retrieval, planning, algorithm design, coding, debugging, and testing functions.
  • C.3.1. RETRIEVAL AGENTS: Retrieval agents use E5 to identify semantically relevant documents, while the offline retrieval agent targets semantically similar code solutions.Retrieved outputs can incorporate other agents’ inputs as reference context.
  • C.3.2. PLANNING AGENT; C.3.3. ALGORITHMIC AGENT: The Planning Agent produces step-by-step coding plans and iteratively refines them using previous error messages and the last-round plan.The Algorithmic Agent separately generates customized algorithmic solution steps from the problem and other agents’ outputs.
  • C.3.4. CODING AGENT; C.3.5. DEBUGGING AGENT: The Coding Agent generates an initial solution from the problem, plan, and retrieved references, while the Debugging Agent revises or regenerates code after issues arise.The Managing Agent’s planning decisions determine the debugging strategy from the second round onward.
  • C.3.6. TESTING AGENT: The Testing Agent returns binary pass/fail results and graded diagnostics that determine both reinforcement-learning rewards and iterative termination.Testing evaluates generated-code correctness at the end of each iteration.
  • D. Supplementary Definitions for RL; D.1. Definitions of Multi-Turn Trajectories and Returns in RL; D.2. Reinforcement Learning Objective for Generating Topologies with Adaptive Complexity: The RL objective maximizes discounted execution-based returns for difficulty-adapted topologies and test-passing code, while clipping policy updates and applying token-level KL regularization.Rewards include code-validation outcomes and whether topology density stays within a difficulty-specific upper bound; β balances reward maximization against policy divergence.

D.3. Reward Design and Sensitivity Analysis · D.3.1. REWARD DESIGN PRINCIPLES

AgentConductor’s reward design jointly optimizes topology validity, solution correctness, and communication-efficient sparsity. It separates execution correctness from topology density and applies difficulty-specific density bounds derived from successful samples.

  • D.3.1. REWARD DESIGN PRINCIPLES: The reward design targets YAML topology validity, generated-solution correctness, and difficulty-aware sparsity that controls communication cost.These objectives are implemented through execution-correctness reward r_e and topology-density reward r_g.
  • D.3.1. REWARD DESIGN PRINCIPLES: Execution correctness is handled by r_e, covering both topology syntax and the generated solution’s execution outcome.The separation supports targeted optimization of correctness and topology structure.
  • D.3.1. REWARD DESIGN PRINCIPLES: Topology density is handled separately by r_g to encourage communication-efficient agent interaction structures.This component complements execution correctness rather than combining both objectives into one reward.
  • D.3.1. REWARD DESIGN PRINCIPLES: Invalid YAML structures receive a strong negative reward because they cannot support valid multi-agent execution.Other YAML penalties apply only to topology structure and remain independent of roles or tasks.
  • D.3.1. REWARD DESIGN PRINCIPLES: Once the YAML structure is correct, its format penalty becomes zero, allowing r_e to focus solely on program execution correctness.This isolates syntax handling from execution evaluation after structural validity is established.
  • D.3.1. REWARD DESIGN PRINCIPLES: Topology density upper bounds are set to 4, 7, and 10 for tasks at different difficulty levels.The bounds were obtained by statistically analyzing thousands of SFT-generated samples and the densities required for successful solutions.
Loading 2602.17100v1…