MoFlow: Multi-Objective Agentic Workflow Generation

Yining Lu; Aurelie Lozano; Xi Yang; Naoki Abe; Yu Deng; Meng Jiang

cs.AISep 29, 2026

MoFlow: Multi-Objective Agentic Workflow Generation

Authors: Yining Lu, Aurelie Lozano, Xi Yang, Naoki Abe, Yu Deng, Meng Jiang

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	✗	✗	$O(NE)$	$O(NE)$ re-search
MaAS ( Zhang et al., 2025b )	Monolithic	2 $\to$ 1	✗	✗	$O(N_{\text{tr}}E)$	$O(N_{\text{tr}}E)$ retrain
FlowSteer ( Zhang et al., 2026a )	Constructive	1	✗	✓	$O(N_{\text{tr}}H\ell)^{\ddagger}$	$O(N_{\text{tr}}H\ell)$ retrain
SkillFlow ( Zhang et al., 2026b )	Constructive	1	✗	◗	$O(N_{\text{tr}}H\ell)^{\ddagger}$	$O(N_{\text{tr}}H\ell)$ retrain
EvoMAS ( Hu et al., 2026 )	Evolutionary	2 $\to$ 1	✗	✗	–	$O(NE)$ re-search
ADAS ( Hu et al., 2025 )	Evolutionary	1	✗	✗	$O(NE)$	$O(NE)$ re-search

Table 1: Comparison of MoFlow with the baselines.

2{\to}1

: two objectives scalarized into one.

D

: number of objectives (

D{=}5

in our experiments). Pareto : one run returns the Pareto front. Stepwise : the search builds workflows step by step.

E

is the cost of one full workflow evaluation (many LLM calls) and

\ell

that of a single call (

\ell\ll E

), over

N

search iterations,

N_{\text{tr}}

training episodes, or horizon

H

. ‡ 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

{\bm{w}}

and walks the tree as follows. At a decision node , the trial selects an action for

{\bm{w}}

; at a chance node , an LLM realizes that action into at most

N_{r}

distinct outcomes, each visited with empirical probability

p

estimating

T(s^{\prime}\mid s,a)

. 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 (

\hat{V}(s)

at decision nodes,

\hat{Q}(s,a)

at chance nodes), so a single tree can unroll different workflows for different preferences such as

{\bm{w}}_{1}

and

{\bm{w}}_{2}

( Inference panel).

Figure 3: Contextual zooming at one decision node over the preference simplex for

D{=}3

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 ${\bm{w}}$ , 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 $\pm$ 8.17
MaAS †	24.61	14.28	21.37	7.00	15.13	24.69	17.85 $\pm$ 6.97
FlowSteer †	18.47	17.34	19.86	4.06	12.58	9.68	13.66 $\pm$ 6.07
SkillFlow †	18.55	15.75	10.77	0.81	10.35	4.89	10.19 $\pm$ 6.59
ADAS †	27.71	19.84	26.50	6.84	20.17	28.89	21.66 $\pm$ 8.22
EvoMAS †	28.68	20.74	22.59	7.30	20.14	30.35	21.63 $\pm$ 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 $\pm$ 7.75	14.54
MaAS †	24.61	14.40	17.88	17.77	18.66 $\pm$ 4.28	14.40
FlowSteer †	18.47	15.78	28.75	13.61	19.15 $\pm$ 6.70	13.61
SkillFlow †	18.55	16.80	2.39	14.68	13.11 $\pm$ 7.32	2.39
ADAS †	27.71	16.02	29.19	22.90	23.95 $\pm$ 5.93	16.02
EvoMAS †	28.68	7.60	10.83	15.33	15.61 $\pm$ 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 $\uparrow$	Tokens (M) $\downarrow$
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)		$\rho_{\mathrm{HV}}$ ( $\uparrow$ )
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

Appendix

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.

\rho_{\mathrm{HV}}

is the hypervolume generalization ratio (Eq. 4 ). Query-level trees are cheaper to build, but the workflows they return spend up to 11.6

\times

the tokens and 6.6

\times

the calls per problem at inference. Query-level search overfits the inputs it was built on:

\rho_{\mathrm{HV}}

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

\hat{V}(s)

: 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

\hat{V}(s)

, while Eq. 1 backs up their average

\mathbb{E}[R]

. 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.

Construction MOMDP and search
Name	Value
Number of objectives $D$	5
Horizon $H$	6 (4 on SWE-Bench)
Trial cap $N$ (online)	100; from trial 40, stop once 10-trial HV gain $<\!1\%$
Trial budget $N$ (offline)	300, no early stop
Action proposals per visit $b$	4

Appendix

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.

Explore similar work

Jun 9, 2026cs.LG

FlowBank: Query-Adaptive Agentic Workflows Optimization through Precompute-and-Reuse

Large Language Model (LLM)-based multi-agent systems are increasingly powerful, but current agentic workflow optimization paradigms make an unsatisfying trade-off. Task-level methods spend substantial offline compute yet deploy only a single workflow, leaving complementary candidates unused, while query-level methods synthesize a new workflow per query at substantial inference cost. Our motivating analysis shows these paradigms are more complementary than competing: workflows discovered during offline search often solve different subsets of queries, and many queries handled by expensive query-level generation can already be solved by cheaper precomputed workflows. This suggests a different objective: rather than searching for one universally best workflow or regenerating one per instance, we should build a compact bank of reusable, complementary workflows and select among them adaptively at inference time. Doing so requires solving three coupled problems: generating complementary rather than redundant candidates, compressing them into a small deployable portfolio, and assigning each query to the right workflow under a performance-cost trade-off. To this end, we present FlowBank, a three-stage framework for portfolio-based agentic workflow optimization. Diversifying proposes DiverseFlow to steer search toward under-covered queries and produce a high-coverage candidate pool. Curating proposes CuraFlow to compress this pool into a compact portfolio with minimal redundancy. Matching casts deployment as edge-value prediction on a query-workflow bipartite graph and routes each incoming query to the portfolio member with the best predicted utility. Across five benchmarks, FlowBank achieves the highest average score among the evaluated methods while remaining cost-competitive, improving over the strongest automated and handcrafted baselines by 4.26% and 14.92% relative, respectively.

Lingzhi Yuan, Chenghao Deng, Fangxu Yu +3

University of Maryland, College Park · Amazon

Agentic Workflows Agentic Workflow Design

Ask PDF

Sep 16, 2026cs.AI

Designing Agentic AI Workflow Portfolios under Imperfect Selection and Compute Cost

Agentic AI systems often approach the same task through multiple workflows that differ in reasoning strategy, verification structure, and compute cost. A natural deployment policy is to use the workflow with the highest average performance, but this can be suboptimal because different workflows may succeed on different instances. We study a portfolio-and-selector paradigm in which a firm runs multiple workflow executions and selects the final answer after observing their outputs. Additional executions may uncover correct answers that the best standalone workflow misses, but they consume compute and introduce plausible distractors that complicate final selection. We formulate this as a workflow portfolio problem in which the firm jointly chooses run size and allocation across workflow types. We summarize selector quality through an odds-lift index and derive sharp bounds on the value of workflow variety. For finite workflow pools, we develop exact formulations, linear programming relaxations, randomized rounding procedures, and computable performance certificates. For large implicit workflow classes, we derive a finite-dimensional dual and an ellipsoid method using a pricing oracle to identify workflows with high weighted accuracy net of recurring compute cost. Under a weak condition, the method obtains a near-optimal solution to the relaxation with polynomially many oracle calls. We evaluate the framework on three datasets: ABCD, Schema-Guided Dialogue, and HotpotQA. Relative to the best standalone workflow, portfolio optimization improves held-out selector accuracy by 3.1, 7.5, and 0.9 percentage points, respectively. Dual-guided workflow generation adds 3.5 points on ABCD and 24.1 on HotpotQA, with no additional gain on Schema-Guided Dialogue.

Mojtaba Abdolmaleki, Stefanus Jasin, Boyu Wang

Ross School of Business, University of Michigan, United States

Agentic Workflows Agentic Workflow Design Portfolio Construction

Ask PDF

Oct 4, 2026cs.AI

Fusion is the New Mutation: Bandit-Guided Evolution on Workflow Graphs

Automated agentic workflow optimization relies on costly evaluations, making it essential to allocate a limited evaluation budget effectively. Multi-parent fusion can reuse designs from previously discovered workflows, but identifying promising parent combinations requires learning from limited fusion feedback. We introduce DAGO (Directed Acyclic Graph Optimization), a contextual-bandit-guided framework that learns which parent workflows to fuse under a limited evaluation budget. DAGO formulates each candidate parent combination as an arm, represented by pretrained embeddings of its constituent workflows' code and prompts. A diagonal LinUCB policy learns a shared reward model across arms and balances exploitation of arms with high predicted offspring quality against uncertainty-driven exploration. After an arm is selected, an LLM generates a child workflow through summary-guided fusion, and the child's validation score serves as the reward for updating the bandit. A shared directed acyclic graph maintains discovered workflows and their multi-parent lineage, providing an expanding pool of parents for subsequent arm proposals. Across six benchmarks covering mathematical reasoning, code generation, and question answering, DAGO achieves the highest macro-average score among the evaluated baselines. Under matched validation-evaluation budgets, it improves over AFlow from 80.3 to 81.7 while reducing aggregate search expenditure by 11.2%. Ablation studies show that LinUCB-guided arm selection outperforms both random selection and its exploration-free variant, supporting the value of feedback-driven selection and exploration-exploitation balance.

Zhiwei Shang, Jiahang Sun, Mingrong Gong +9

School of Data Science, The Chinese University of Hong Kong, Shenzhen, China · College of Computing and Data Science, Nanyang Technological University, Singapore · Huawei Technologies Co., Ltd., China +1

Agentic Optimization

Ask PDF