JudgeFlow: Agentic Workflow Optimization via Block Judge
Abstract
Optimizing LLM-based agentic workflows is challenging for scaling AI capabilities. Current methods rely on coarse, end-to-end evaluation signals and lack fine-grained signals on where to refine, often resulting in inefficient or low-impact modifications. To address these limitations, we propose JudgeFlow, an Evaluation-Judge-Optimization-Update pipeline. We incorporate reusable, configurable logic blocks into agentic workflows to capture fundamental forms of logic. On top of this abstraction, we design a dedicated Judge module that inspects execution traces particularly failed runs and assigns rank-based responsibility scores to problematic blocks. These fine-grained diagnostic signals are then leveraged by an LLM-based optimizer, which focuses modifications on the most problematic block in the workflow. Our approach improves sample efficiency, enhances interpretability through block-level diagnostics, and provides a scalable foundation for automating increasingly complex agentic workflows. We evaluate JudgeFlow on mathematical reasoning and code generation benchmarks, where JudgeFlow achieves superior performance and efficiency compared to existing methods.
Keywords:
Machine Learning, ICML1 Introduction
Large language models (LLMs) (Brown et al., 2020) have achieved remarkable success across a wide range of domains. Moving beyond the scope of foundation models (Bommasani et al., 2022), by integrating LLMs into intelligent agent architectures, the emerging foundation agents (Liu et al., 2025a) have attracted more attention. Starting from early work on prompt engineering, such as reasoning-enhanced methods (Wei et al., 2023; Wang et al., 2023b; Yao et al., 2023a), to more recent developments in multi-agent system approaches (Du et al., 2023; Li et al., 2023; Hong et al., 2024), these handcrafted strategies have achieved strong performance across a range of tasks, including mathematical reasoning (Cobbe et al., 2021), code generation (Austin et al., 2021), question answering (Yang et al., 2018), and decision making (Sun et al., 2025).
However, these agentic systems still depend heavily on manual design, making workflow construction complex, costly, and inflexible. AutoML (Hutter et al., 2019) has shown that automating traditionally handcrafted and labor-intensive processes in machine learning can substantially reduce human effort and accelerate the development of high-performance models. Inspired by this success, recent efforts aim to automate the design and optimization of LLM-based agentic workflows (Lee et al., 2025). While these agentic systems still rely on LLMs as core execution engines, optimizing the LLMs themselves through pretraining or fine-tuning (Rafailov et al., 2023) often demands substantial computational resources and massive-scale data, making such approaches expensive in many settings (Kaplan et al., 2020). Instead, keeping the underlying model parameters fixed, and focusing on optimizing the systems structure and behavior leads to a more tractable and efficient optimization.
Automation efforts in agentic systems initially focused on prompt optimization, exemplified by Textual Gradients which leverage LLM feedback for end-to-end optimization (Pryzant et al., 2023; Yuksekgonul et al., 2024; Wang et al., 2024b; Yin and Wang, 2025). Current efforts are expanding to optimize architecture and execution flow of entire agentic systems. Agentic workflow can be modeled as neural network (Liu et al., 2024; Ma et al., 2025), graph (Zhuge et al., 2024a; Zhang et al., 2025a), and code (Hu et al., 2025; Zhang et al., 2025b; Zheng et al., 2025), each offering different levels of representational capacity, interpretability, and optimization difficulty. For instance, Directed Acyclic Graphs (DAGs)-represented workflows facilitate tractable optimization but constrain the ability to represent complex structures such as loops or conditional branching. In contrast, code-represented workflows provide comprehensive expressivity in defining intricate logic and control flow, but error attribution within code execution is difficult, and optimization often has to rely solely on end-to-end evaluation signals rather than fine-grained intermediate feedback. Building on code-represented workflows, Zhang et al. (2025b) introduce operators as modular units that encapsulate common agentic actions and propose a Monte Carlo Tree Search (MCTS) framework that employs LLMs to iteratively optimize workflows using past experience. However, the expansion phase in MCTS and the subsequent evaluation of candidate workflows can be expensive, and the effectiveness of the optimization process is constrained by the granularity of guidance available for modifications. In the absence of sufficiently fine-grained diagnostic information to precisely identify which specific part within the complex workflow requires modification, the search may explore ineffective or low-impact alterations. Furthermore, complex code structural interactions such as conditional constructs where only one branch of an if-else statement is executed along a trajectory leave certain components without informative signals, thereby hindering fine-grained analysis.
To address these challenges, we introduce JudgeFlow, an Evaluation-Judge-Optimization-Update pipeline. First, we incorporate reusable and configurable logic blocks into agentic workflows. These blocks capture three fundamental forms of logic: sequential, loop, and conditional, which are able to broadly represent code-based workflows. Compared with operators, which abstract specific agentic operations or functionalities (Zhang et al., 2025b), logic blocks serve as higher-level structural abstractions. By introducing logic blocks that abstract such common control structures, we retain the structural diversity of code-represented workflows while providing an intermediate level of abstraction between operators and workflows. This additional layer facilitates interpretability and exposes more meaningful diagnostic information for subsequent optimization.
Second, we incorporate a dedicated Judge module that analyzes the execution trace, with particular emphasis on failed runs. We hypothesize that optimizers should receive both evaluation and optimization signals. For each unsuccessful execution, the Judge attempts to identify the most problematic block within the workflow as illustrated in Figure 1. To further improve the precision of diagnosis, we adopt a rank-based approach at the block level. The resulting targeted diagnostic signals are propagated to the subsequent optimization stage, enabling more focused and efficient refinement of weak blocks. In this way, optimization efforts can be concentrated on repairing underperforming components, resulting in more effective and reliable improvements in overall workflow performance. Besides relying solely on end-to-end evaluation signals, our approach leverages block-level diagnostic information, enabling the optimizer to focus on the most problematic components.
In summary, our contributions are as follows:
- •
We propose a novel Evaluation-Judge-Optimization-Update pipeline named JudgeFlow;
- •
We introduce reusable and configurable logic blocks as higher-level structural units, which balance the expressivity of code-based workflows with tractable optimization, while supporting interpretability and intermediate execution tracing;
- •
We design a Judge module that analyzes execution traces, especially failed runs, and assigns rank-based responsibility scores to problematic blocks, enabling fine-grained error localization and targeted refinement for subsequent optimization.
- •
We evaluate JudgeFlow on mathematical reasoning and code generation benchmarks, showing that it outperforms existing methods.
2 Related Work
LLM-based (Multi-)Agent Systems
In recent years, LLM-based (multi-)agent systems have achieved notable successes (Wang et al., 2024a; Huang et al., 2024; Tran et al., 2025). At the single-agent level, foundational works have enabled agents to reason and act by interleaving thought and action (Yao et al., 2023b), to enhance complex problem-solving through structured exploration of thoughts (Yao et al., 2023a), and to interact effectively with external tools or APIs (Wu et al., 2024). At the multi-agent level, frameworks such as CAMEL (Li et al., 2023), AutoGen (Wu et al., 2023), and MetaGPT (Hong et al., 2024) have facilitated sophisticated collaboration on complex tasks, demonstrating strong performance across diverse domains. Despite these advances, existing systems remain constrained by a reliance on handcrafted prompts and rigid communication topologies, which limit adaptability as task complexity scales. This has spurred a shift toward automated agentic systems capable of optimizing their own architectures and behaviors.
Agentic Systems Automation
Early automation efforts in agentic systems primarily focused on prompt optimization (Pryzant et al., 2023; Ramnath et al., 2025; Li et al., 2025), with approaches such as LLMs-as-optimizers (Yang et al., 2024), self-referential evolution (Fernando et al., 2023), textual gradients (Yuksekgonul et al., 2024), and self-supervised optimization (Xiang et al., 2025). More recent research has expanded beyond prompt-level tuning toward optimizing the architectures and execution flows of entire agentic systems. For example, Liu et al. (2024) explores dynamic communication structures for adaptive collaboration, while Zhuge et al. (2024a) models agents as computational graphs to refine both prompts and inter-agent orchestration. Shang et al. (2024) proposes a novel modular design automatically searching for high-performance agent structures. Zhou et al. (2024) investigates agents capable of self-optimization using symbolic optimizers. Hu et al. (2025) introduces a meta agent that automatically discovers novel, high-performing, and generalizable agentic system designs. Yin et al. (2025) introduces a self-referential framework that enables agents to recursively improve themselves. Zhang et al. (2025b) employs LLMs as optimizers with a Monte Carlo Tree Search (MCTS) variant to discover effective workflows. Zhang et al. (2025a) automatically evolve agentic supernet systems leading to query-specific workflows. Su et al. (2025) leverages debate and reflexion to collaboratively refine workflows while reducing search redundancy. Zheng et al. (2025) introduces safety-constrained evolutionary programming in a declarative graph space, ensuring structural validity and robustness. While these efforts mark significant progress, most existing approaches still focus on end-to-end or global architectural optimization, often leading to inefficient search and a lack of fine-grained diagnostic feedback, which limits both scalability and interpretability as task complexity grows.
LLM as a Judge
The LLM-as-a-judge paradigm leverages large language models to automate the evaluation of generated content, addressing the scalability limitations of human assessment (Gu et al., 2025). This approach has been widely adopted for assessing complex outputs based on predefined criteria (Li et al., 2024). To mitigate the potential bias of the LLM-as-a-Judge (Wang et al., 2023a), various methods have been proposed. Liu et al. (2025b) propose a ranking-based alignment method that significantly improves the judging performance of LLMs. In addition, Zhuge et al. (2024b) proposed the framework to use agentic systems to evaluate agentic systems. In a related application, Zhang et al. (2025c) attempts to automate the failure attribution for LLM multi-agent systems, revealing that providing stronger ground-truth signals can substantially improve attribution quality, and aggregated analysis across multiple failures can uncover reliable error patterns.
3 Methodology
3.1 Problem Formulation
Our framework models an agentic workflow by hierarchically composing basic agentic actions (Operators) into structured logical units (Blocks) as follows.
A configured operator is the basic unit of agentic action, where represents a categorical label for its core function like generate or self_refine (details in Appendix A), and is the operator configuration, which includes the LLM backbone, prompt template, and other hyperparameters (Zhang et al., 2025b). Building upon operators, a logic block is a higher-level structural unit that orchestrates one or more configured operators, where is the logic block type, dictating how the operators are orchestrated. The set of available types includes three fundamental forms of logic as shown in Figure 2 (details in Appendix B):
- •
SequenceLogic (seq): A sequential execution block where operators are executed one after another. Each operator consumes the output of its predecessor, ensuring a linear flow of intermediate results until the final operator produces the block output.
- •
LoopLogic (for): An iterative block that repeatedly invokes its internal operators. The iteration continues until the stopping condition is satisfied.
- •
ConditionalLogic (cond): A branching block that first executes a designated condition operator. Based on the evaluation outcome, it then activates one of two operator sequences. Only the operators in the selected branch are executed to generate the block output.
Correspondingly, is the logic block configuration, which contains the set of configured operators in the block and block-level parameters (e.g., stopping condition in LoopLogic). Finally, the agentic workflow is defined as a tuple , where is the total number of logic blocks in the workflow, and denotes the ordered sequence of logic blocks at the top level while each individual block may internally contain conditional or iterative control. This definition not only preserves the common logic patterns in code-represented workflows ensuring expressive diversity (Hu et al., 2025; Zhang et al., 2025b), but also enhances interpretability, including the explicit semantic characteristics of each logic block and the overall execution trajectory of the workflow facilitating subsequent optimization.
Given an input query from the dataset which is available to every block, the execution function processes workflow by sequentially applying its logic blocks along the execution order . Each block receives the state from the previous block, , and produces a new state, , formally defined as:
| (1) |
where is the execution function for block and . The final workflow output is obtained as , and then scored by the evaluation function against the ground-truth answer corresponding to . The objective of agentic workflow optimization is to find the optimal workflow that maximizes evaluation performance across the dataset:
| (2) |
where denotes the search space of candidate workflows.
3.2 JudgeFlow
A challenge in optimizing agentic workflows is credit assignment: identifying which component of a complex execution is responsible for failures and should be refined. Existing methods largely rely on coarse, end-to-end evaluation signals, making it difficult to perform targeted modifications. Building on the representation of workflow using logic blocks, JudgeFlow incorporates a dedicated Judge module and implements an iterative Evaluation-Judge-Optimization-Update pipeline for the efficient optimization of agentic workflows as shown in Figure 3.
3.2.1 Evaluation-Judge
The combined Evaluation-Judge stage, detailed in Algorithm 1, processes each input query from the dataset. If the workflow fails on a given query, the stage identifies and logs specific problematic block within . This provides targeted diagnostic signals for subsequent workflow optimization, enabling a more efficient and focused approach on refining these identified weak logic to improve overall optimization efficiency.
Specifically, for each input query (with a corresponding ground-truth answer ), we have , and score . The score is recorded in a list for later calculation of ’s overall performance. Providing a threshold that indicates successful execution, if , the instance is marked as successful, and the algorithm simply proceeds to the next input.
However, if , a quadruple is defined to encapsulate the full context of the failure. The Judge proceeds to examine the quadruple, assessing each block’s responsibility for the failure and ranking them accordingly. This procedure, guided by specific Judge prompts (detailed in Appendix C), yields a rank-based score vector (Liu et al., 2025b) for the blocks where refers to the block deemed most responsible for the failure and denotes the least responsible, each rank from to is assigned exactly once. These block scores are appended to . The function then utilizes this score vector to identify , the block deemed most problematic for the current instance (i.e. ) . Subsequently, the instance details are logged into , the dedicated log for , providing targeted few-shot examples for its potential future optimization.
Upon completion of all instances in , the accumulated diagnostic information is processed. The function analyzes all block rank-based score vectors in to identify , the block deemed the most consistently problematic over the whole dataset. This statistical filtering mechanism is designed to ensure robustness against noisy outputs. We follow the finding (Zhang et al., 2025c) that while individual LLM-based failure attribution might contain noise, the aggregated distribution across multiple failures is more consistent with the true causes. In practice, we aggregate rank vectors across all failing instances in by summing the scores assigned to each block , and then selects the block achieving the minimum sum (i.e. , where is the number of the failure executions). Concurrently, the overall performance of on is computed by . Finally, this stage returns , , and , providing actionable insights for subsequent optimization.
| Method | GSM8K | MATH | MBPP | HumanEval | Avg. |
| Single-agent System | |||||
| IO | 87.8 | 48.6 | 73.9 | 87.0 | 74.3 |
| CoT (Wei et al., 2023) | 87.0 | 48.8 | 74.2 | 88.6 | 74.7 |
| CoT SC (Wang et al., 2023b) | 86.9 | 50.4 | 73.3 | 91.6 | 75.6 |
| Hand-crafted Multi-agent System | |||||
| SELF-REFINE (Madaan et al., 2023) | 85.5 | 46.1 | 71.8 | 87.8 | 72.8 |
| LLM-Debate (Du et al., 2023) | 89.5 | 48.6 | 70.3 | 88.8 | 74.3 |
| LLM-Blender (Jiang et al., 2023) | 88.4 | 46.9 | 77.1 | 88.7 | 75.3 |
| DyLAN (Liu et al., 2024) | 90.0 | 48.5 | 77.3 | 90.4 | 76.6 |
| Autonomous Multi-agent System | |||||
| GPTSwarm (Zhuge et al., 2024a) | 89.1 | 47.9 | 77.4 | 89.3 | 75.9 |
| ADAS (Hu et al., 2025) | 88.4 | 43.2 | 77.1 | 84.2 | 73.2 |
| AFlow (Zhang et al., 2025b) | 90.1 | 52.8 | 81.7 | 90.1 | 78.7 |
| MaAS (Zhang et al., 2025a) | 91.5 | 52.2 | 82.2 | 91.6 | 79.4 |
| MermaidFlow (Zheng et al., 2025) | 92.4 | 55.4 | 82.3 | 92.9 | 80.8 |
| JudgeFlow (Ours) | 93.0 | 58.5 | 83.8 | 93.4 | 82.2 |
3.2.2 Optimization-Update
In the subsequent Optimization-Update stage, the LLM-based optimizer utilizes the insights from the previous stage and refines to produce an improved version guided by specific optimization prompts (detailed in Appendix D), which can be formally expressed as
| (3) |
where refers to few-shot samples drawn from the logs and , where is a predefined set of available modification actions as follows:
- •
Add Block : Introduce a new block with configuration , and connect it directly with the low-performing block ;
- •
Remove Block: Remove the low-performing block together with all of its incident edges while reconnecting its predecessor and successor to preserve sequential flow;
- •
Modify Block: Reconfigure the existing by updating its configuration .
In practice, the LLM-based optimizer selects adaptively based on the diagnostic signals in . Following Zhang et al. (2025b), the refined workflow is first evaluated to obtain its performance score . The pair is then added to the candidate pool , which retains at most workflows by keeping the top- highest-scoring entries:
| (4) |
At the beginning of the next iteration, the optimizer selects a starting workflow according to a softmax distribution:
| (5) |
where is the evaluation score of workflow .
4 Experiments
4.1 Experimental Setups
Benchmarks
We evaluate JudgeFlow on widely used benchmarks, covering math reasoning tasks (GSM8K (Cobbe et al., 2021), MATH (Hendrycks et al., 2021), AIME (Ye et al., 2025)) and code generation tasks (MBPP (Austin et al., 2021), HumanEval (Chen et al., 2021)). Following previous studies (Zhang et al., 2025b; Zhang et al., 2025a), each dataset is divided into training and test sets. We report the solve rate (%) on GSM8K, MATH, AIME, and pass@1 on MBPP, HumanEval to evaluate.
Baselines
We compare our JudgeFlow with a series of baselines, including (1) Single-agent System: Standard prompting (IO), Chain-of-Thought prompting (CoT) (Wei et al., 2023), and Self-Consistency (Wang et al., 2023b); (2) Hand-crafted Multi-agent System: MultiPersona (Wang et al., 2024c), SELF-REFINE (Madaan et al., 2023), LLM-Debate (Du et al., 2023), LLM-Blender (Jiang et al., 2023), and DyLAN (Liu et al., 2024); (3) Autonomous Multi-agent System: GPTSwarm (Zhuge et al., 2024a), ADAS (Hu et al., 2025), AFlow (Zhang et al., 2025b), MaAS (Zhang et al., 2025a), and MermaidFlow (Zheng et al., 2025). Compared with domain-specialized agents, these methods provide a more appropriate setting to evaluate the effectiveness of our block-level Judge in workflow optimization.
Implementation Details
In our main experiments, to keep consistent with prior literature (Zheng et al., 2025), we use gpt-4o-mini-0718 (OpenAI, 2024b), gpt-4.1-mini (OpenAI, 2025) as the optimization, Judge and execution LLM accessed via API. The number of iteration rounds is set to 20. When optimizing, we set , , and .
4.2 Experimental Results
As shown in Table 1, JudgeFlow achieves superior performance compared to several strong baselines across all the tasks. Notably, for some challenging benchmarks such as MATH and MBPP, JudgeFlow outperforms the strongest prior baseline by +3.1(5.6%) and +1.5(1.8%), respectively. At the same time, for relatively simpler benchmarks such as GSM8K and HumanEval, JudgeFlow still achieves consistent gains of +0.6 and +0.5. Taken together, JudgeFlow achieves the average score of 82.2, representing a +1.4(1.7%) increase. As shown in Figure 4, in significantly more challenging AIME benchmark, JudgeFlow achieves an average score of 44.67. The results highlight the effectiveness of our Judge-guided block-level optimization across both reasoning and code generation tasks.
4.3 Analysis
We take the MBPP dataset as an illustrative example to analyze JudgeFlow.
Best Performing Workflow
Figure 5 is the best-performing workflow found by JudgeFlow. First, a seq block b1 applies a generate operator to produce an initial candidate function. Second, a for block b2 repeatedly invokes the test operator until the stopping condition is satisfied. Finally, a cond block b3 runs the test operator to check correctness: if the candidate doesn’t pass, it routes the solution to a self_refine operator.
Ablation
The core of JudgeFlow is the synergy between logic blocks and the Judge module, where logic blocks provide well-defined execution boundaries that enable fine-grained failure attribution. To evaluate this design, we compare JudgeFlow and AFlow which lacks Judge on the block-level abstraction as shown in Figure 6. JudgeFlow exhibits performance gains within the first five optimization iterations, with both the training and testing curves showing rapid improvements. Beyond this early stage, JudgeFlow continues to achieve gains, ultimately converging to higher accuracy. In contrast, AFlow remains stagnant across most iterations and only shows noticeable improvements in the later stage, and its final training and testing performance remain consistently lower than those of JudgeFlow.
Impact of LLMs
According to Table 2, we keep gpt-4o-mini-0718 fixed as the executor LLM, while varying the optimization and Judge models. Particularly, we consider gpt-4o (OpenAI, 2024a) and Gemini-2.5-flash (Google-Cloud, 2025) as alternatives for these roles and report the resulting performance. The experiment confirms that increasing the capacity of optimization and Judge models consistently improves performance. While all models yield competitive results, gpt-4o attains the best score 84.5.
| Models | Score |
| GPT-4o-mini | 83.8 |
| GPT-4o | 84.5 |
| Gemini-2.5-flash | 84.4 |
Cross-benchmark Generalization
We evaluate the cross-benchmark transferability of JudgeFlow by optimizing the workflow using the MATH(MBPP) dataset and zero-shot evaluating on the GSM8K(HumanEval) dataset. The results show that JudgeFlow yields better transferability on both math transfer and code transfer as shown in Table 3.
| AFlow | JudgeFlow | |
| MATH GSM8K | 91.95 | 92.89 |
| MBPP HumanEval | 90.84 | 93.89 |
Optimization Cost
Although JudgeFlow introduces an additional Judge module for LLM calls, the dominant cost in agentic workflow optimization lies in the Evaluation phase rather than the Judge module in our proposed methods. We monitor the cost for a single optimization round on the GSM8K dataset, the Evaluation cost ($0.45) is considerably higher than the Judge cost ($0.01). The Judge/Evaluation cost ratio is approximately 2%, demonstrating that the fine-grained diagnosis provides significant optimization guidance at a marginal overhead.
4.4 Case Study
To illustrate how JudgeFlow works in practice, we present a case study of workflow optimization on the GSM8K dataset as shown in Figure 7. The initial workflow consists of two logic blocks: b1, a seq block consisting of one multi_generate_ensemble operator designed to generate and ensemble multiple candidate solutions (with num_solutions set to 3), and b2, a seq block consisting of one programmer operator, which takes the output from the previous block and generates the final answer using programming. When processing a batch of GSM8K instances, this workflow failed multiple times, triggering the Evaluation-Judge stage. The Judge module analyzed execution traces of these failures and assigned rank-based responsibility scores to each block. For example, in one failed run, it output {"b2": 1, "b1": 2}, attributing the primary blame to b2, while in another it output {"b1": 1, "b2": 2}, assigning higher responsibility to b1. By aggregating these rank-based scores across failures, the system identified b1 as the OverallWorst block, indicating that low-quality initial solutions from b1 were the main bottleneck, making it difficult for the workflow to generate correct final answers. In the Optimization-Update stage, the LLM-based Optimizer received this diagnostic signal and selected the Add Block action. It introduced a new logic block, b3, of type seq, with operator self_refine, which iteratively improves candidate solutions. This block was inserted between b1 and b2, producing the new workflow ["b1", "b3", "b2"]. The updated workflow first generates multiple ideas with b1, then refines them with b3, and finally produces the polished answer through b2. This case study demonstrates how block-level diagnostics enable targeted workflow improvements.
5 Conclusion
In this paper, we presented a novel Evaluation-Judge-Optimization-Update pipeline named JudgeFlow for automating agentic workflow optimization. By introducing reusable logic blocks as higher-level structural abstractions, JudgeFlow achieves a balance between the expressive flexibility of code-based workflows and the tractability of optimization. On top of this representation, the Judge module provides block-level diagnostic signals by analyzing execution traces and assigning responsibility to the problematic block, enabling more interpretable and fine-grained optimization. Through extensive experiments on mathematical reasoning and code generation benchmarks, we demonstrate that JudgeFlow consistently outperforms strong baselines. Future work may include exploring more robust Judge for agentic systems optimization.
Impact Statement
This paper presents work whose goal is to advance the field of Machine Learning. There are many potential societal consequences of our work, none which we feel must be specifically highlighted here.
References
- Program Synthesis with Large Language Models. arXiv (en-US). Note: arXiv:2108.07732 [cs] External Links: Link, Document Cited by: §1, §4.1.
- On the Opportunities and Risks of Foundation Models. arXiv. Note: arXiv:2108.07258 [cs] External Links: Link, Document Cited by: §1.
- Language Models are Few-Shot Learners. arXiv. Note: arXiv:2005.14165 [cs] External Links: Link, Document Cited by: §1.
- Evaluating Large Language Models Trained on Code. arXiv. Note: arXiv:2107.03374 [cs] External Links: Link, Document Cited by: §4.1.
- Training Verifiers to Solve Math Word Problems. arXiv (en-US). Note: arXiv:2110.14168 [cs] External Links: Link, Document Cited by: §1, §4.1.
- Improving Factuality and Reasoning in Language Models through Multiagent Debate. arXiv (en-US). External Links: Link, Document Cited by: §1, Table 1, §4.1.
- Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution. arXiv (en-US). External Links: Link, Document Cited by: §2.
- Gemini 2.5 flash— vertex ai. Note: https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flashAccessed: 2025-05-18 Cited by: §4.3.
- A Survey on LLM-as-a-Judge. arXiv (en-US). External Links: Link, Document Cited by: §2.
- Measuring Mathematical Problem Solving With the MATH Dataset. arXiv. Note: arXiv:2103.03874 [cs] External Links: Link, Document Cited by: §4.1.
- MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. arXiv (en-US). External Links: Link Cited by: §1, §2.
- Automated Design of Agentic Systems. arXiv (en-US). External Links: Link, Document Cited by: §1, §2, §3.1, Table 1, §4.1.
- Understanding the planning of LLM agents: A survey. arXiv. Note: arXiv:2402.02716 [cs] External Links: Link, Document Cited by: §2.
- Automated machine learning: methods, systems, challenges. 1st edition, Springer Publishing Company, Incorporated. External Links: ISBN 3030053172 Cited by: §1.
- LLM-blender: ensembling large language models with pairwise ranking and generative fusion. External Links: 2306.02561, Link Cited by: Table 1, §4.1.
- Scaling Laws for Neural Language Models. arXiv. Note: arXiv:2001.08361 [cs] External Links: Link, Document Cited by: §1.
- Compound AI Systems Optimization: A Survey of Methods, Challenges, and Future Directions. arXiv. Note: arXiv:2506.08234 [cs] External Links: Link, Document Cited by: §1.
- CAMEL: Communicative Agents for ”Mind” Exploration of Large Language Model Society. arXiv (en-US). External Links: Link Cited by: §1, §2.
- LLMs-as-Judges: A Comprehensive Survey on LLM-based Evaluation Methods. arXiv. External Links: Link, Document Cited by: §2.
- A Survey of Automatic Prompt Engineering: An Optimization Perspective. arXiv (en-US). External Links: Link, Document Cited by: §2.
- Advances and Challenges in Foundation Agents: From Brain-Inspired Intelligence to Evolutionary, Collaborative, and Safe Systems. arXiv (en-US). External Links: Link, Document Cited by: §1.
- Aligning with Human Judgement: The Role of Pairwise Preference in Large Language Model Evaluators. arXiv (en-US). External Links: Link, Document Cited by: §2, §3.2.1.
- A Dynamic LLM-Powered Agent Network for Task-Oriented Agent Collaboration. arXiv (en-US). External Links: Link, Document Cited by: §1, §2, Table 1, §4.1.
- Agentic Neural Networks: Self-Evolving Multi-Agent Systems via Textual Backpropagation. arXiv. Note: arXiv:2506.09046 [cs] External Links: Link, Document Cited by: §1.
- Self-refine: iterative refinement with self-feedback. In Thirty-seventh Conference on Neural Information Processing Systems, External Links: Link Cited by: Table 1, §4.1.
- GPT-4o — openai platform documentation. Note: https://platform.openai.com/docs/models/gpt-4o Cited by: §4.3.
- GPT-4o-mini — openai platform documentation. Note: https://platform.openai.com/docs/models/gpt-4o-miniAccessed: 2025-05-18 Cited by: §4.1.
- GPT-4_1-mini — openai platform documentation. Note: https://platform.openai.com/docs/models/gpt-4.1-miniAccessed: 2025-11-27 Cited by: §4.1.
- Automatic Prompt Optimization with “Gradient Descent” and Beam Search. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, H. Bouamor, J. Pino, and K. Bali (Eds.), Singapore, pp. 7957–7968 (en-US). External Links: Link, Document Cited by: §1, §2.
- Direct Preference Optimization: Your Language Model is Secretly a Reward Model. arXiv (en). External Links: Link Cited by: §1.
- A Systematic Survey of Automatic Prompt Optimization Techniques. arXiv (en-US). Note: arXiv:2502.16923 [cs] External Links: Link, Document Cited by: §2.
- AgentSquare: Automatic LLM Agent Search in Modular Design Space. arXiv (en-US). External Links: Link Cited by: §2.
- DebFlow: Automating Agent Creation via Agent Debate. arXiv. Note: arXiv:2503.23781 [cs] External Links: Link, Document Cited by: §2.
- LLM-based multi-agent decision-making: challenges and future directions. IEEE Robotics and Automation Letters 10 (6), pp. 5681–5688. External Links: Document Cited by: §1.
- Multi-Agent Collaboration Mechanisms: A Survey of LLMs. arXiv (en-US). External Links: Link, Document Cited by: §2.
- A survey on large language model based autonomous agents. Frontiers of Computer Science 18 (6) (en). External Links: ISSN 2095-2228, 2095-2236, Link, Document Cited by: §2.
- Large Language Models are not Fair Evaluators. arXiv (en-US). Note: arXiv:2305.17926 [cs] External Links: Link, Document Cited by: §2.
- How to Correctly do Semantic Backpropagation on Language-based Agentic Systems. arXiv (en-US). External Links: Link, Document Cited by: §1.
- Self-consistency improves chain of thought reasoning in language models. External Links: 2203.11171, Link Cited by: §1, Table 1, §4.1.
- Unleashing the emergent cognitive synergy in large language models: a task-solving agent through multi-persona self-collaboration. External Links: 2307.05300, Link Cited by: §4.1.
- Chain-of-thought prompting elicits reasoning in large language models. External Links: 2201.11903, Link Cited by: §1, Table 1, §4.1.
- AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv (en-US). External Links: Link Cited by: §2.
- AvaTaR: optimizing llm agents for tool usage via contrastive reasoning. External Links: 2406.11200, Link Cited by: §2.
- Self-Supervised Prompt Optimization. arXiv (en-US). External Links: Link, Document Cited by: §2.
- Large Language Models as Optimizers. arXiv (en-US). External Links: Link, Document Cited by: §2.
- HotpotQA: a dataset for diverse, explainable multi-hop question answering. External Links: 1809.09600, Link Cited by: §1.
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv. Note: arXiv:2305.10601 [cs] External Links: Link, Document Cited by: §1, §2.
- ReAct: Synergizing Reasoning and Acting in Language Models. arXiv. Note: arXiv:2210.03629 [cs] External Links: Link, Document Cited by: §2.
- AIME-preview: a rigorous and immediate evaluation framework for advanced mathematical reasoning. Note: https://github.com/GAIR-NLP/AIME-PreviewGitHub repository Cited by: §4.1.
- LLM-AutoDiff: Auto-Differentiate Any LLM Workflow. arXiv (en-US). External Links: Link, Document Cited by: §1.
- Gödel Agent: A Self-Referential Agent Framework for Recursive Self-Improvement. arXiv (en-US). External Links: Link, Document Cited by: §2.
- TextGrad: Automatic ”Differentiation” via Text. arXiv (en-US). External Links: Link, Document Cited by: §1, §2.
- Multi-agent Architecture Search via Agentic Supernet. arXiv (en-US). External Links: Link, Document Cited by: Appendix A, §1, §2, Table 1, §4.1, §4.1.
- AFlow: Automating Agentic Workflow Generation. arXiv (en-US). External Links: Link, Document Cited by: Appendix A, §1, §1, §2, §3.1, §3.1, §3.2.2, Table 1, §4.1, §4.1.
- Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems. arXiv (en-US). Note: arXiv:2505.00212 [cs] External Links: Link, Document Cited by: §2, §3.2.1.
- MermaidFlow: Redefining Agentic Workflow Generation via Safety-Constrained Evolutionary Programming. arXiv (en). Note: arXiv:2505.22967 [cs] External Links: Link, Document Cited by: Appendix A, §1, §2, Table 1, §4.1, §4.1.
- Symbolic Learning Enables Self-Evolving Agents. arXiv (en-US). External Links: Link, Document Cited by: §2.
- Language Agents as Optimizable Graphs. arXiv (en-US). External Links: Link, Document Cited by: §1, §2, Table 1, §4.1.
- Agent-as-a-Judge: Evaluate Agents with Agents. arXiv (en-US). External Links: Link Cited by: §2.
Appendix A Operators
Following Zhang et al. (2025b), Zhang et al. (2025a) and Zheng et al. (2025), we adopt the following set of operators:
- 1.
generate, a generation operator that produces candidate solutions based on the problem description and optional previous results.
- 2.
test, a testing operator that executes generated solutions against test cases and provides feedback for refinement.
- 3.
self_refine, a refinement operator that improves a given solution through self-refinement.
- 4.
multi_generate_ensemble, an ensemble operator that generates multiple solutions and combine them to the best one via self-consistency.
- 5.
programmer, a synthesis-and-execution operator that generates Python code for solving math problems, runs it in a restricted environment, and iteratively repairs errors.
Appendix B Logic Blocks
We implement three common logic types in code-represented workflows: SequenceLogic (seq), LoopLogic (for), and ConditionalLogic (cond), whose descriptions and interfaces are listed below.
Appendix C Judge Prompt
The user prompt provides the problem, correct answer, incorrect answer, workflow structure, execution trace in XML format, and the list of blocks to rank.