Workflow Search
Better answer instructions have limited effect if the system still reaches conclusions before gathering information or forwards incorrect intermediate results without checking them. This chapter asks how execution results can guide the choice of operations, information flow, and conditions for repeating steps. A workflow connects large language model (LLM) calls, tool executions, aggregation, and related operations. Here, the editable components include not only prompt wording but also the number, order, branching, and repetition of operations.
“Dynamic workflow” has several meanings. Search may produce a shared program that branches according to its input, or a different graph may be generated for every input. Changing procedures in response to observations during execution also differs from updating the next trial’s configuration after a completed trial. Keeping these distinctions, we compare executable-structure search, joint prompt optimization, failure-localized revision, and adaptation by input or trial.
Making Executable Structures into Search Candidates
Changing connections does more than increase the number of agents. It changes whose outputs an operation can read, how errors propagate, and how independent solutions are aggregated. GPTSwarm represents agents as directed acyclic graphs (DAGs), with model calls or tool operations as nodes and information flow as edges. It combines multiple agents into a composite graph and optimizes inter-agent edges. Each possible connection has a probability, and execution utility from sampled graphs updates distribution parameters without enumerating every combination. At the node level, execution and evaluation feedback guide prompt improvement (Zhuge et al. 2024, secs. 2.3–2.4).
The updated connection distribution is not the answering model’s weights. Since the paper also includes online connection optimization, describing GPTSwarm as only constructing one fixed graph in advance is inaccurate. Its basic representation is nevertheless a DAG, not a direct representation of arbitrary loops or stateful control. Broader structural freedom requires specifying which execution rules become searchable.
AgentSquare uses standardized inputs and outputs for four module types: planning, reasoning, tool use, and memory. It alternates recombining modules from existing designs with evolutionary proposals for new modules. A performance predictor uses evaluated configurations and scores as context to skip unpromising executions. These constraints narrow the search space but enable reuse of components from separate implementations. Unlike GPTSwarm’s optimization of communication among multiple agents, AgentSquare searches one agent’s internal configuration (Shang et al. 2025, secs. 2–3). In Figure 2, recombination draws on the module pool while evolution proposes new modules, so the search changes reusable components as well as their combinations.
AFlow more directly uses executable code to represent structure. Nodes correspond to LLM calls, while operators such as Ensemble and Review & Revise package common processing patterns behind shared interfaces. Code calling these operators represents execution order, branches, and loops. The general formulation also includes model, temperature, and output format as node attributes, but the main search setting fixes these and primarily changes prompts and code-defined connections. It does not search every node attribute simultaneously (Jiayi Zhang et al. 2025, secs. 3–4).
Its search procedure is a variant of Monte Carlo tree search (MCTS). Each tree candidate is a workflow, not an intermediate answer state. Search selects a promising candidate and gives an LLM its code, past modification experience, and execution feedback to produce a child. New candidates run repeatedly on the validation set, recording scores, changes from the parent, and whether those changes improved results. “Backpropagation” here returns evaluations and modification experience to the search tree, not derivatives to model weights.
At the lower left of Figure 3, edges are code that includes conditional branches, not merely connecting lines. The modification experience in the center records revisions tried on one candidate for use in subsequent generation. The post-test branch at the lower right also appears concretely in the published MBPP code below.
The MATH search record in Appendix C.1 adds a Programmer operator to an initial candidate, calculates with Python, and uses a Custom operator to format the final answer. Later changes try aggregating multiple solutions, with both successes and failures recorded for similar modifications. This is not a general rule that adding aggregation improves results. It shows why evaluation must include how a change is added to a particular parent structure (Jiayi Zhang et al. 2025, Appendix C.1).
For a concrete example of structure expressed in code, the MBPP workflow in Appendix B generates several solutions, aggregates them, and revises according to test results. The following excerpt contains the branching portion of that published code. It is not a reconstructed search-time patch (Jiayi Zhang et al. 2025, Appendix B).
best_solution = await self.sc_ensemble(solutions=solutions, problem=problem)
test_result = await self.test(problem=problem, solution=best_solution['response'],
entry_point=entry_point)
if test_result['result']:
return test_result['solution'], self.llm.cost_manager.total_cost
else:
# If the test fails, try to fix the solution
fixed_solution = await self.custom(
input=f"Problem: {problem}\nFailed solution: {best_solution['response']}\nError: {test_result['solution']}",
instruction=prompt_custom.FIX_CODE_PROMPT)
return fixed_solution['response'], self.llm.cost_manager.total_costThe important point is that the condition invoking revision and the error information passed to it are part of the search result, alongside the revision instruction. Even so, the same program runs on each input after search. This differs from searching for a new workflow on every input.
Keeping Component Prompts and Overall Structure Together
Comparing structures alone can make a connection pattern appear ineffective because one component’s prompt is weak. Conversely, a strong standalone component may have an incompatible input format or role when connected to others. MASS and FlowBot address this dependency through different joint-optimization procedures.
MASS (Multi-Agent System Search) has three stages: component prompt optimization, structure search, and system-wide prompt reoptimization. It first improves a basic solver, then conditions on that solver to optimize instructions and demonstrations in minimal configurations for aggregation, reflection, debate, summarization, tool use, and related components. It uses each component’s relative validation performance against the basic solver as an influence measure that affects the probability of selecting structural search dimensions. It samples configurations within an agent-count limit and selects structures by validation performance. Finally, it jointly reoptimizes prompts under the selected overall structure (Zhou et al. 2026, sec. 3, Algorithm 1).
Figure 4 shows how progressively fixing conditions reduces combinatorial complexity instead of freely searching everything simultaneously. The structure is not an arbitrary graph either. Appendix C.3 uses a predefined order of summarization, reflection, debate, and aggregation and searches parallelism, iteration counts, whether an executor is present, and related choices. MASS therefore demonstrates the usefulness of a configuration space built from well-tuned components rather than unconstrained code search.
The paper’s Figure 2 relates the reason to improve components before adding structural complexity to inference-token consumption. Its MATH experiments with Gemini 1.5 Pro compare self-consistency aggregation, self-reflection, and debate with a solver whose instruction and one demonstration are optimized, and with that optimized solver plus self-consistency. The relevant setting in Appendix C.1 uses subsets of 60 validation and 100 test problems. The horizontal axis shows each configuration’s inference-time tokens per problem, not a single comparison imposing the same token cap on every method (Zhou et al. 2026, fig. 2, Appendix C).
In Figure 5, improving prompts before aggregating solutions gives a different cost–performance relationship from increasing calls with default prompts. This does not establish lower total cost including search. Many future inputs can amortize search cost, while a small number may lead to a different conclusion. The curves also investigate component effects, not the direct superiority of complete MASS over every search method.
Rather than proceeding through three stages once, FlowBot alternates an outer optimization of high-level workflow descriptions with inner optimization of detailed prompts for each call. It represents structure as a textual outline of call roles, not code. The inner loop propagates final-output feedback back to intermediate processing and generates natural-language suggestions for each node. The outer loop proposes adding, deleting, or merging calls. This is LLM-based distribution and application of textual feedback, not numerical differentiation. Updates use training data, and the workflow with the best validation performance is tested. It is not an online method updating the configuration on every execution. MASS emphasizes component preparation and alignment after structural selection, whereas FlowBot repeatedly adjusts structure and components (Yu et al. 2026, secs. 2–3).
Repairing Failures and Updating Search Strategies
Average performance helps select candidates but does not identify what to change. Calculation errors, missing intermediate results, and format violations require different revisions even when all yield incorrect answers. Failure-Driven Workflow Refinement at ICML 2026 introduces CE-Graph, which groups failures before proposing local graph edits (Jusheng Zhang et al. 2026).
CE-Graph accumulates failed executions as counterexamples and extracts the error-producing node and error content from each. It constructs a failure signature by concatenating a representation of the node identifier with a semantic embedding of the error message, then estimates recurring failure groups with a Gaussian mixture model. The basic setting prioritizes frequent groups, with severity weighting when appropriate. Rather than repairing only the latest example, it targets concentrated weaknesses (Jusheng Zhang et al. 2026, secs. 3.1–3.2).
The proposer conditions revisions on the targeted failure group. Executable edits revise existing node prompts, insert nodes with explicit inputs and outputs, or delete redundant nodes. After comparing candidates on examples from the targeted group, the procedure also checks validation performance for the entire workflow. Local repairs can break other problems, so these checks are not interchangeable. The main setting starts from a minimal answer node and verifier, allows at most 20 iterations, and stops according to convergence (Jusheng Zhang et al. 2026, Algorithm 1, Section 4.1).
AFlow also uses execution feedback, so the difference is not whether a method inspects failures. AFlow searches broadly with a candidate tree and parent-relative modification experience. CE-Graph explicitly aggregates failure locations and meanings and conditions edits on dominant groups. Its failure-density formulation does not imply that ordinary derivatives through edits can be computed. The paper’s improvement guarantees assume properties of local repairs, not that arbitrary LLM proposals always improve the whole system.
EvoMAS improves search efficiency differently. It has multiple evolutionary operations that change structure or roles and adjusts the choice between broadening search and refining promising candidates. Tasks progress from easy to difficult. Periodically, a meta-controller called Cyber Creator reflects on search history and updates rules for avoiding invalid structures and strategies for selecting operations. Whereas CE-Graph changes which failures receive concentrated edits, EvoMAS also changes candidate-generation rules and operation allocation. Evolution here primarily occurs during development search, not continuous learning of roles and connections on every deployment input (Wei et al. 2026, secs. 4.1–4.3).
Input-Specific Generation Differs from Inter-Trial Adaptation
A shared structure may allocate excessive processing to easy problems and too little to difficult ones. MaAS prepares an agentic supernet of available operators and connections, then samples a needed structure conditioned on the question. It selects operators at each layer and stops if an early-exit operator is chosen. During development, answer quality and execution cost update the structure distribution, while textual improvement suggestions adjust operator prompts, temperatures, and internal configurations. Learning the structure-selection distribution differs from updating the answering model’s weights (G. Zhang et al. 2025, sec. 3, Algorithm 1).
The distinction from MASS matters. MASS shares a structure selected for a dataset, whereas MaAS shares a structure-selection mechanism and changes the executed structure by question. Evaluation of the latter must therefore inspect how calls are allocated by difficulty as well as mean performance. More sophisticated fixed-structure search does not automatically produce this input dependence.
AdaptFlow uses an intermediate unit: subtasks grouping semantically similar inputs. An inner loop improves each subtask’s workflow, while an outer loop aggregates improvement feedback to update a shared initial structure. For unseen subtasks, it specializes structure using semantic descriptions made only from input questions. It does not continue inner-loop search using test answers. Although inspired by meta-learning, it performs symbolic updates in code space, unlike Model-Agnostic Meta-Learning (MAML), which learns initial model weights suited to adapting through a few gradient updates. This comparison concerns gradient-based meta-learning of model weights. It does not mean that every MAML variant requires second derivatives. AdaptFlow appeared in Findings of EMNLP 2025 (Zhu et al. 2025, secs. 3–4).
FlowSearcher shifts the shared artifact from a fixed overall structure to experience used in generating structures. It decomposes Web information-search questions into subgoals and synthesizes a graph of search, browsing, analysis, and related operations for each. Past experience at node, graph, and task levels supports both generation and execution. Since procedure depth, ordering, and tool combinations change with inputs and observations, its objective differs from selecting a final shared-workflow candidate. What matters is not merely hierarchical memory, but its use to condition new structural synthesis (Xiang et al. 2026, sec. 3). In Figure 11, memory feeds both workflow synthesis and execution, explaining how past experience can guide a new graph without fixing its topology.
EvoTest operates on a different timescale again. It repeats the same game task and passes the Actor’s complete execution history and rewards to an Evolver, which updates prompts, memory, hyperparameters, and tool-use procedures for the next trial. Selection from previous configurations uses an upper confidence bound. It adapts at test time without weight updates, but its focus is configuration evolution rather than necessarily topology search. Improving a shared graph for unseen problems must not be confused with improvement from repeatedly experiencing the same environment (He et al. 2026, secs. 3–4). The Act–Evolve loop in Figure 12 places configuration updates between episodes, not inside a weight-training loop.
These studies show that structural freedom alone is insufficient. AFlow specifies executability and modification history, MASS and FlowBot the dependence between components and structure, CE-Graph the location and recurrence of failures, MaAS and FlowSearcher input-specific processing needs, and EvoTest when experience feeds back into updates. The open question is whether improvements on unseen inputs or environments persist as these freedoms expand when search, structure generation, execution, and adaptation all count toward the same budget. Separating shared structures, input-specific generation, and inter-trial adaptation makes that question testable.
Figure Credits
Figure 1: (Zhuge et al. 2024). Original figure: published version, Figure 1. CC BY 4.0. Original figure cropped and rasterized.
Figure 3: (Jiayi Zhang et al. 2025). Original figure: ICLR 2025 public version, Figure 3. CC BY 4.0. Original figure cropped and rasterized.
Figure 3: (Zhou et al. 2026). Original figure: published version, Figure 3. CC BY 4.0. Original figure cropped and rasterized.
Figure 2: (Zhou et al. 2026). Original figure: published version, Figure 2. CC BY 4.0. Original figure cropped and rasterized.
Figure 1: (Yu et al. 2026). Original figure: published version, Figure 1. CC BY 4.0. Original figure cropped and rasterized.
Figure 2: (Jusheng Zhang et al. 2026). Original figure: published version, Figure 2. CC BY 4.0. Original figure cropped and rasterized.
Figure 3: (Wei et al. 2026). Original figure: published version, Figure 3. CC BY 4.0. Original figure cropped and rasterized.
Figure 2: (G. Zhang et al. 2025). Original figure: published version, Figure 2. CC BY 4.0. Original figure cropped and rasterized.
Figure 2: (Zhu et al. 2025). Original figure: published version, Figure 2. CC BY 4.0. Original figure cropped and rasterized.
Figure 3: (Shang et al. 2025). Original paper PDF, Figure 3. Cropped and rasterized.
Figure 1: (Xiang et al. 2026). Original paper PDF, Figure 1. Cropped and rasterized.
Figure 1: (He et al. 2026). Original paper PDF, Figure 1. Cropped and rasterized.