cs.AISep 29, 2026
SaveMoFlow: Multi-Objective Agentic Workflow Generation
Organizations: University of Notre Dame · IBM
Abstract
We study the generation of agentic workflows that jointly optimize multiple objectives, such as accuracy, cost, latency, robustness, and consistency. Existing methods for workflow generation typically optimize accuracy alone or a weighted sum of objectives, so each trained generator commits to one fixed trade-off and must be retrained from scratch when preferences change. To alleviate this, we propose MoFlow, which generates workflows optimized across varied preferences. Specifically, MoFlow formulates workflow generation as a multi-objective Markov decision process and solves it by leveraging Convex-Hull Monte Carlo Tree Search with optimistic set-valued backups, where every node stores a set of reachable trade-offs rather than one weighted score. A single search thus approximately covers the Pareto front, from which MoFlow can return a workflow for any preference by lookup without retraining. We evaluate MoFlow against six strong baselines on six benchmarks spanning mathematics, code, and question answering. Since the baselines are single-scalar optimizers by design, an apples-to-apples comparison is difficult. We instead adopt an evaluation setup that favors the baselines, in that they are rerun for each testing preference, which MoFlow never sees. Even under this stringent setup, MoFlow achieves the highest average hypervolume.
Figures & tables
Figure 1: Per-objective coverage on the six benchmarks: across eleven testing preferences, MoFlow matches or beats every baseline on all five objectives on most tasks. Each axis shows the best value a method attains across its eleven generated workflows, with cost and latency inverted so that outward is always better. Each baseline † is rerun once per testing preference, whereas MoFlow serves all eleven preferences from one search that never saw them.
| Method | Family | Objectives | Pareto | Stepwise | Training | Inference |
|---|---|---|---|---|---|---|
| AFlow ( Zhang et al., 2025d ) | Monolithic | 1 | ✗ | ✗ | re-search | |
| MaAS ( Zhang et al., 2025b ) | 2 1 | ✗ | ✗ | retrain | ||
| FlowSteer ( Zhang et al., 2026a ) | Constructive | 1 | ✗ | ✓ | retrain | |
| SkillFlow ( Zhang et al., 2026b ) | 1 | ✗ | ◗ | retrain | ||
| EvoMAS ( Hu et al., 2026 ) | Evolutionary | 2 1 | ✗ | ✗ | – | re-search |
| ADAS ( Hu et al., 2025 ) | 1 | ✗ | ✗ | re-search |
Table 1: Comparison of MoFlow with the baselines. : two objectives scalarized into one. : number of objectives ( in our experiments). Pareto : one run returns the Pareto front. Stepwise : the search builds workflows step by step. is the cost of one full workflow evaluation (many LLM calls) and that of a single call ( ), over search iterations, training episodes, or horizon . ‡ Plus LLM-policy gradient updates. Inference : cost to serve a new preference (a weight vector over the objectives) by rerunning the search or training. MoFlow instead answers any preference by lookup. EvoMAS has no training phase. Its search runs at test time as queries arrive, so a new preference reruns it in full. ✓ yes, ✗ no, ◗ partial.
Figure 2: Overall MoFlow framework. MoFlow searches once, then answers any preference by lookup. Each trial samples a preference and walks the tree as follows. At a decision node , the trial selects an action for ; at a chance node , an LLM realizes that action into at most distinct outcomes, each visited with empirical probability estimating . Decision and chance nodes alternate until a terminal action completes the workflow; MoFlow then executes it and backs the result up the visited path (faded nodes are branches the current trial does not visit). Every node therefore stores a convex coverage set ( at decision nodes, at chance nodes), so a single tree can unroll different workflows for different preferences such as and ( Inference panel).
Figure 3: Contextual zooming at one decision node over the preference simplex for objectives. Each ball ties one action (its color) to a preference region. The background marks the true optimal action the search never sees. Finer balls tell nearby preferences apart, so refinement drifts toward region boundaries while interiors stay coarse.
Figure 4: One MoFlow search on SWE-Bench. The y-axis shows the in-sample hypervolume of non-dominated workflows executed up to each trial. Each labeled example is a workflow generated from its sampled , with objectives listed as accuracy cost latency robustness consistency.
| Method | AIME 2026 | MATH-Hard | MBPP | SWE-Bench | GPQA-D | HotpotQA-H | Mean |
|---|---|---|---|---|---|---|---|
| AFlow † | 29.85 | 21.87 | 27.71 | 7.11 | 17.41 | 18.57 | 20.42 8.17 |
| MaAS † | 24.61 | 14.28 | 21.37 | 7.00 | 15.13 | 24.69 | 17.85 6.97 |
| FlowSteer † | 18.47 | 17.34 | 19.86 | 4.06 | 12.58 | 9.68 | 13.66 6.07 |
| SkillFlow † | 18.55 | 15.75 | 10.77 | 0.81 | 10.35 | 4.89 | 10.19 6.59 |
| ADAS † | 27.71 | 19.84 | 26.50 | 6.84 | 20.17 | 28.89 | 21.66 8.22 |
| EvoMAS † | 28.68 | 20.74 | 22.59 | 7.30 | 20.14 | 30.35 | 21.63 8.19 |
Table 2: Held-out hypervolume of the front served across eleven testing preferences. All methods use GPT-5 Mini. Each baseline † is adapted to the five objectives and rerun once per preference, targeting the exact weight it is later scored at. MoFlow instead serves all eleven preferences from a single search that never saw them. Even so, MoFlow attains the best hypervolume on four of six benchmarks and the best mean. Bold marks the best per column, underline the second best. Mean is reported with standard deviation across the six benchmarks.
| Method | GPT-5 Mini | Haiku 4.5 | Gemini 3 Flash | DeepSeek-V4-Flash | Mean | Worst |
|---|---|---|---|---|---|---|
| AFlow † | 29.85 | 14.54 | 30.33 | 19.86 | 23.64 7.75 | 14.54 |
| MaAS † | 24.61 | 14.40 | 17.88 | 17.77 | 18.66 4.28 | 14.40 |
| FlowSteer † | 18.47 | 15.78 | 28.75 | 13.61 | 19.15 6.70 | 13.61 |
| SkillFlow † | 18.55 | 16.80 | 2.39 | 14.68 | 13.11 7.32 | 2.39 |
| ADAS † | 27.71 | 16.02 | 29.19 | 22.90 | 23.95 5.93 | 16.02 |
| EvoMAS † | 28.68 | 7.60 | 10.83 | 15.33 | 15.61 9.27 | 7.60 |
Table 3: Held-out hypervolume under four base models, where MoFlow is the only method that ranks in the top two on all four. Each method is rerun end to end with the tested model.
| Action selection | In-sample HV | Tokens (M) |
|---|---|---|
| Chebyshev | 17.06 | 43.76 |
| Hypervolume-UCB | 17.87 | 61.01 |
| Pareto-UCB | 16.80 | 26.44 |
| CZT (ours) | 20.35 | 23.99 |
Table 4: Action-selection ablation on AIME 2026 with Claude Haiku 4.5. CZT attains the best in-sample hypervolume at the lowest cost.
Appendix figures & tables7 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 5: Accuracy-cost Pareto fronts on the six benchmarks. Test accuracy against tokens per problem under GPT-5 Mini (up and left is better). The dashed front combines all workflows generated by the six adapted baselines † , each rerun once per preference. Gray points are dominated workflows. MoFlow , from a single search that never saw the eleven preferences, matches or extends this combined baseline front on five of the six benchmarks , trailing only on MATH-Hard, where the baselines’ most accurate workflow stays ahead at roughly ten times the cost.
Figure 6: Per-objective performance of task-level versus query-level search. One tree per benchmark ( task-level ) against one small tree per query ( query-level ), under the same setting as § 4 . Each axis shows the best value a search mode attains across its eleven served workflows, with cost and latency inverted so that outward is always better. Task-level search matches or exceeds query-level search on nearly all objectives across the six benchmarks.
| Search cost (M tokens) | Inference cost (tokens) | Inference latency (calls) | ( ) | |||||
|---|---|---|---|---|---|---|---|---|
| Benchmark | Task | Query | Task | Query | Task | Query | Task | Query |
| AIME 2026 | 132.3 | 111.9 | 5.6k | 23.0k | 1.36 | 4.27 | 0.68 | 0.37 |
| MATH-Hard | 115.7 | 74.1 | 5.7k | 12.5k | 1.00 | 3.80 | 0.93 | 0.73 |
| MBPP | 134.9 | 85.4 | 2.1k | 20.1k | 1.19 | 7.89 | 0.87 | 0.28 |
| SWE-Bench | 597.2 | 452.1 | 102.7k | 115.3k | 6.53 | 7.36 | 0.66 | 0.63 |
| GPQA-Diamond | 232.0 | 162.7 | 2.8k | 32.5k | 1.00 | 6.25 | 1.95 | 0.93 |
Table 5: Cost comparison between task-level and query-level search. Search cost is the execution tokens spent building each tree. Inference cost and latency are the mean tokens and sequential calls per problem, averaged over the workflows returned for the eleven preferences. is the hypervolume generalization ratio (Eq. 4 ). Query-level trees are cheaper to build, but the workflows they return spend up to 11.6 the tokens and 6.6 the calls per problem at inference. Query-level search overfits the inputs it was built on: falls as low as 0.28 on unseen draws of the same query, against at least 0.66 for every task-level tree.
Figure 7: A complete query-level search tree on SWE-Bench, built with GPT-5 Mini. The tree contains 90 decision nodes (blue), 83 chance nodes (gold), and 20 evaluated terminals (green). The number in each circle is the size of the node’s CCS : a 1 means the node holds a single trade-off. Two terminals show a 2 because one of their three repeated runs solved the problem while another failed but used fewer tokens or calls, so neither run dominates. Each terminal stores these pruned per-run returns in , while Eq. 1 backs up their average . The tree thus records that a workflow can fail and fail cheaply.
Figure 8: A complete query-level search tree on MATH-Hard. It contains 156 decision nodes, 148 chance nodes, and 23 evaluated terminals. The root keeps five trade-offs, ranging from an accurate workflow at 10.8k tokens down to a single-call workflow at 1.0k tokens that fails, and the blue “2” at depth 1 shows that an interior node can also keep more than one trade-off. The search favors code execution, selecting StepProgrammer or Programmer in 45 of its 148 actions.
Figure 9: A complete query-level search tree on GPQA-Diamond. The tree contains 122 decision nodes, 116 chance nodes, and 20 evaluated terminals. The root spans the widest cost range of the three trees: its accurate workflow costs 82k tokens and 14 calls, while its two-call workflows stay under 9k tokens. Seven of the 20 terminals show a 2, each keeping both its cheapest accurate run and its cheapest failed run. The tree thus records that the same workflow can succeed, or fail at a slightly lower cost. The search is critique-driven, selecting the ReviewRevise operator in 42 of its 116 actions.
| Name | Value |
|---|---|
| Construction MOMDP and search | |
| Number of objectives | 5 |
| Horizon | 6 (4 on SWE-Bench) |
| Trial cap (online) | 100; from trial 40, stop once 10-trial HV gain |
| Trial budget (offline) | 300, no early stop |
| Action proposals per visit | 4 |
Table 6: MoFlow hyperparameters and reproducibility information. All settings are shared across the six benchmarks and four base models except the horizon and set sizes, noted in their rows.