$A^2Flow:$ Automating Agentic Workflow Generation via Self-Adaptive Abstraction Operators

1 Introduction

• Manual design and refinement of agentic workflows require substantial human effort and constrain scalability, adaptation to novel domains, and generalization across tasks.Agentic workflows are described as sequences of LLM invocations guided by human-designed instructions.Source: §1 · p. 1
• Its operator pipeline generates case-aware operators, clusters similar operators into preliminary abstractions, then uses deep reasoning and multi-path selection to refine task-aware operators.The introduction describes these reusable operators as enabling workflow construction without manual predefinition.Source: §1 · p. 2
• A2Flow is a highly automated workflow-generation framework that extracts self-adaptive abstraction operators rather than relying on manually predefined, task-specific operators.The stated goals are to reduce computational costs and improve generalization across diverse tasks.Source: §1 · p. 2
• The Operators Memory Mechanism gives operators access to accumulated historical outputs, supporting more context-aware execution and improving workflow search performance.A2Flow also reuses agents’ thought processes to reduce interaction steps during inference.Source: §1 · p. 2
• Across eight benchmark datasets in five domains, A2Flow is reported to consistently outperform state-of-the-art methods and exhibit strong generalization.The domains include code generation, mathematical reasoning, reading comprehension, games, and embodied tasks.Source: §1 · p. 2

2 Related Work

• Automated workflow optimization targets the full workflow structure, unlike prompt optimization within fixed workflows or hyperparameter tuning of preset parameters.The section characterizes full workflow optimization as having greater potential for automatic and generalizable workflow generation.Source: §2 · p. 2
• AFlow searches code-represented workflows with MCTS but relies on hand-crafted, task-specific operators, limiting automation and transfer to unseen or open-world tasks.The section also notes no clear evidence that AFlow’s operators are close to optimal.Source: §2 · p. 3
• Other approaches retain constraints: GPTSwarm struggles with conditional states, ADAS has a simple experience representation, and DebFlow inherits predefined operators.MermaidFlow is also described as struggling to generalize to some open-world tasks, including embodied and everyday scenarios.Source: §2 · p. 3
• A2Flow addresses the operator-design gap by adaptively extracting abstract operators from expert data without manual design or prior knowledge.The section links this approach to automatic discovery of effective operator sets for workflow automation and generalization.Source: §2 · p. 3

3.1 Preliminary

• A workflow is a sequence of LLM-invoking nodes connected by edges that define execution order, and optimization searches configurations to maximize task evaluation.Operators provide concise interfaces that unify nodes and edges.Source: §3.1 · p. 3

3.2 Overview

• A2Flow extracts task-aware abstract operators before search through case-based generation, clustering and abstraction, then multi-path refinement with Long CoT and self-consistency.The process uses expert training data to generate case-aware operators, groups similar functions, and refines abstractions into reusable execution operators.Source: §3.2 · p. 3

3.3 Self-Adaptive Abstraction Operators

• Initial operators are generated per expert-data case, represented as code-based workflow blocks, clustered by function, then refined across six reasoning paths with three iterative steps.An executor checks generated Python code for syntax and executability; errors trigger reflection and regeneration.Source: §3.3 · pp. 3–4

3.4 Operators Memory Mechanism

• The Operators Memory Mechanism accumulates prior operator outputs so each step can use historical results rather than depending only on the immediately preceding output.The authors state that combining task context with historical information supports more accurate operator execution and better cross-task generalization.Source: §3.4 · pp. 4–5

3.5 Automated Workflow Optimization

• Workflow optimization injects the self-adaptive operators and memory into an AFLOW-based search that expands and evaluates candidate workflows, jointly optimizing workflow structures and operator representations.The search uses a template workflow, validation-set evaluations, and backpropagated scores and historical experience.Source: §3.5 · p. 5

4.1 Experiments Setting

• Experiments cover eight benchmarks across five domains, using benchmark-specific metrics and tracking token usage to analyze cost–accuracy trade-offs.The domains are code generation, mathematical reasoning, reading comprehension, embodied tasks, and games.Source: §4.1 · p. 5

4.2 Experiments Results and Analysis

• A2Flow achieves state-of-the-art performance on primary task metrics except HumanEval, beating predefined-operator methods by 2.4% on average, AFLOW by 4.5% on DROP, and AFLOW by 4.1% on MATH.Table 1 reports mean performance over three trials using GPT-4o-mini as executor.Source: §4.2 · p. 5, Table 1 · p. 6
• A2Flow shows a 19.3% performance improvement on embodied and game tasks, while its gains are more modest on GSM8K and less effective against strong predefined-operator baselines on HumanEval and MBPP.The authors attribute the embodied and game improvement primarily to adaptive task suitability enabled by automated search deriving abstract execution operators from limited training data.Source: §4.2 · p. 6, Table 2 · p. 6
• Figure 3 compares total execution costs for A2Flow- and AFLOW-generated workflows on partitioned DROP using the same execution model, with colors identifying the executing LLM.A2Flow discovers cost-effectiveness Pareto-front workflows in which less capable models can outperform stronger ones.Source: Figure 3 · p. 5, §4.2 · p. 6

4.3 Ablation Study

• A2Flow’s full MATH model scores 58.5% (∆+4.1); removing operator memory lowers the score to 53.9% (∆−4.1), while removing initial operators, clustering, or deep extraction yields 49.6%, 54.5%, or 51.6%, respectively.The ablation results indicate both modules matter, with self-adaptive abstraction operators providing slightly larger gains.Source: §4.3 · p. 6, Table 3 · p. 6

4.4 Case Study

• The ALFWorld case study generates case-specific operators, clusters them into abstractions, and uses multi-path long-CoT generation to produce Planner, Executor, and Validator operators before MCTS workflow search.During search, the optimizer adjusts operators or workflow edges, and operator memory stores node-to-node transformation messages when workflows contain more than two operators.Source: §4.4 · pp. 6–7, Figure 4 · p. 7

• A2Flow extracts operators by generating case-specific operators from expert examples and LLM reasoning, clustering similar operators, and refining them with deep chain-of-thought reasoning into general-purpose execution operators.The resulting reusable components support workflow construction without manual definitions.Source: §5 · p. 7
• A2Flow’s operator memory stores past outputs to improve node-level decision-making.Source: §5 · p. 7
• Across general and embodied tasks, A2Flow improves performance by 2.4% and 19.3% and reduces resource usage by 37% over leading baselines.Source: §5 · p. 7

A.1 LLM-based Abstract Operator: Prompt for Operator Generation

• LLM-driven execution operators are generated from task-specific problem descriptions and resolutions, then related operations are clustered, non-essential ones pruned, and generalized into abstract operations.The deep-extraction stage targets reusable workflow nodes such as execution and validation across similar tasks.Source: §A.1 · pp. 10–11

A.2 LLM-based Expansion: Prompt for LLM Optimizer

• The optimizer prompt asks an LLM to reconstruct and modify a graph and its prompts, while limiting graph complexity to 10.It may add, modify, or delete nodes, parameters, or prompts and requires necessary context to be included.Source: §A.2 · p. 12

A.4 Abstract Operators

• Task-specific abstract operators include analyzers, validators, executors, and planners for benchmarks such as HotpotQA, HumanEval, GSM8K, ALFWorld, and TextCraft.The listed operators also include data extraction, code processing, math processing, and resource management roles.Source: §A.4 · p. 15

A.5 Mapping Workflow from Operators to Code

• Each operator is a one-input, one-output program unit, and the optimizer builds or modifies node flows that pass responses through accumulated history.The illustrated math workflow includes solution generation, verification, conditional correction, and a formatted final answer.Source: §A.5 · p. 16

B.1 The Dataset Statistics

• A 1:4 validation-to-test ratio is used for each benchmark dataset.For embodied and game tasks, the selected portion of the training dataset satisfies the validation ratio.Source: §B.1 · p. 16
• The ALFWorld validation set contains 33 samples, while the TextCraft validation set contains 20.Source: §B.1 · p. 16
• Workflow optimization runs for 10 rounds on embodied and game tasks and 20 rounds on other tasks.Source: §B.1 · p. 16

B.2 Cost Analysis

• 1.62% higher accuracy than AFLOW with GPT-4o accompanies computational resource use of 51.37% of AFLOW’s, a 48.63% cost reduction.The analysis selects the top three workflows from the validation set for detailed comparison.Source: §B.2 · p. 16
• Equivalent efficacy to AFLOW with DeepSeek-v3 is achieved at 43.02% of AFLOW’s operational expense in the optimal workflow configuration.Source: §B.2 · p. 16
• The cost-performance comparison is conducted on DROP under varied executors using top-three validation workflows.Source: §B.2 · p. 16

C.1 The optimization process for the embodied task

• The ALFWorld example illustrates iterative workflow improvement through search over abstract operators.Source: §C.1 · p. 16
• 0.3030 to 0.3333 score improvement from rounds 2 to 7 accompanies iterative planning refinement in the ALFWorld workflow.The account describes this change as bolstering solution robustness and facilitating embodied task planning and executable action.Source: §C.1 · p. 18
• 0.2121 to 0.3030 score improvement from rounds 1 to 2 follows adding a Planner to a two-stage planning-and-execution workflow.Source: §C.1 · p. 18
• 0.2121 to 0.0909 score decline from rounds 1 to 6 follows adding a Validator, while replacing iterative refinement with parallel execution accompanies a 0.3333 to 0.1515 decline from rounds 7 to 9.The account attributes the validator decline to self-model judgments rather than environmental feedback, and the parallel strategy to ungrounded decisions from overthinking and error accumulation.Source: §C.1 · p. 18

D More Details of Ablation Study

• The MATH benchmark has a list of abstract-operator names, but the supplied passage does not include the names.The passage introduces the list without showing its contents.Source: D More Details of Ablation Study · p. 19
• Table A4 examines three components: initialization operators, clustering operators, and deep execution operators.The supplied caption identifies the components but does not report ablation outcomes.Source: Table A4 · p. 19
• The table presents a selected subset of initial operators and the first reasoning path for the deep-merging process.The caption does not specify the selection criteria or provide the full process.Source: Table A4 · p. 19