DyFlow: Dynamic Workflow Framework for Agentic Reasoning
Authors: Yanbo Wang
Zixiang Xu
Yue Huang
Xiangqi Wang
Zirui Song
Lang Gao
Chenxi Wang
Xiangru Tang
Yue Zhao
Arman Cohan
Xiangliang Zhang
Xiuying Chen
Venue: NeurIPS 2025 poster ()
Keywords: Large Language Models
LLM Agent
Workflow Generation
Primary area: deep_learning

Abstract: Agent systems based on large language models (LLMs) have shown great potential in complex reasoning tasks, but building efficient and generalizable workflows remains a major challenge. Most existing approaches rely on manually designed processes, which limits their adaptability across different tasks. While a few methods attempt automated workflow generation, they are often tied to specific datasets or query types and make limited use of intermediate feedback, reducing system robustness and reasoning depth. Moreover, their operations are typically predefined and inflexible.
To address these limitations, we propose **DyFlow**, a dynamic workflow generation framework that adaptively constructs and adjusts reasoning procedures based on task requirements and real-time intermediate feedback, thereby enhancing cross-task generalization.
DyFlow consists of two core components: a designer and an executor. The designer decomposes complex problems into a sequence of sub-goals defined by high-level objectives and dynamically plans the next steps based on intermediate outputs and feedback. These plans are then carried out by the executor, which executes each operation using dynamic operators with context-aware parameterization, enabling flexible and semantically grounded reasoning.
We systematically evaluate DyFlow across diverse domains, including social reasoning, biomedical tasks, mathematical problem solving, and code generation.
Results demonstrate that DyFlow significantly outperforms existing baselines, achieving substantial Pass@k improvements and exhibiting robust generalization across diverse domains.

Dy Dynamic Workflow Framework for Agentic Reasoning
Yanbo Wang', Zixiang Xu', Yue Huang?, Xiangqi Wang', Zirui Song' Lang Gao?, Chenxi Wang', Xiangru Tang", Yue Zhao Arman Cohan
Xiangliang Zhang?. Xiuying Chen
MMohamed bin Zayed University of Artificial Intelligence (MBZUAT) University of Notre Dame, Yale University, *University of Southern California
Email: uyf231870gmail.. com *Corresponding author
Abstract
Agent systems based on large language models (LLMs) have shown great potential in complex reasoning tasks, but building efficient and generalizable workflows remains major challenge. Most existing approaches rely on manually designed processes, which limits their adaptability across different tasks. While a few methods attempt automated workflow generation, they are often tied specific datasets or query types and make limited use of intermediate feedback, reducing system robustness and reasoning depth. Moreover, their operations are typically predefined and inflexible. To address these limitations, we propose DyFlow, a dynamic workflow generation framework that adaptively constructs and adjusts reasoning procedures based on task requirements and real-time intermediate feed- back, thereby enhancing cross-task generalization. DyFlow consists of two core components: designer and an executor. The designer decomposes complex problems into a sequence of sub-goals defined by high-level objectives and dy- namically plans the next steps based on intermediate outputs and feedback. These plans are then carried out by the executor, which executes each operation using dynamic operators with context-aware parameterization, enabling flexible and semantically grounded reasoning. We systematically evaluate DyFlow across diverse domains, including social reasoning, biomedical tasks, mathematical prob- lem solving, and code generation. Results demonstrate that DyFlow significantly outperforms existing baselines, achieving substantial Pass @k improvements and exhibiting robust generalization across diverse domains. The code is publicly http:///gghhtbbbooooo///////1///
available httpp::://gitub...... http:b/ccccoyyy3tm
Introduction
Large language models (LLMMs) have demonstrated remarkable abilities in language understanding. generation, and complex reasoning tasks 22 3. They support many applications, from dialogue systems and content generation to autonomous agents and multi-step decision-making [4] [ 77. Recently, there has been growing trend of deploying LLMs as agents, where multiple LLMs collaborate to tackle complex tasks. Debate-based systems enable agents to critique each other's solutions (8), and team-based agents distribute tasks across specialized roles [9] 10].
However, most existing multi-agent frameworks use static, pre-defined workflows, as illustrated in Figure [] Each agent's role and task sequence is fixed beforehand, proceeding rigidly without intermediate feedback. For instance, CAMEL [10] assigns agents pre-defined roles via system prompts, MetaGPT 9 enforces collaboration based on standard operating procedures, and AutoGen
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

Static
Dataset-specife
inestion-specifie
Execution-adaptive
Workflow
Workflow
Workflow
Workflow
Dataset1
Feedback
Environment
Dataset2
Question1
Question2
Designer
Subgoal
Dynamic Operations
sequence
Predefined operation
OP configuration
Figure 1: Paradigm shift in LLM-based reasoning workflows. From left to right: static workflows apply fixed sequences across all tasks; dataset-specific and question-specifie workflows allow more variation but rely on predefined operations (OP); DyFlow adopts an execution -arpuuiion-daavvveeee paradigm that dynamically adjusts the workflow based on intermediate feedback.
orchestrate agents through static communication graphs or APIs. When sub-task fails produces flawed output, these systems typically halt or propagate errors due to the lack of mechanisms for revising plans or goals. Recent frameworks introduce some adaptability
[5] and OpenAgents
but with limitations: AFlow [12] and ADAS [33 optimize workflows via offline search guided by dataset-level performance, still tied to specific training distributions. DyLAN [14] and MaAS [TS] offer query-specific agent configurations but do not adjust subgoals based real-time feedback.
To address these limitations, we propose DyFlow, a agents that dynamically adapts subgoal planning during execution. DyFlow is built on a hierarchical designer-executor architecture and operates sequenced manner: Given task, the high-level designer initializes the process by planning the first subgoal and its corresponding operator execution graph based on the task requirements. The low-level executor then carries out this subgoal, leveraging tools, APIs, or external functions as required. At each execution step, DyFlow collects intermediate outputs, tool feedback, and possible error signals. Based on this updated context, the designer generates revised subgoal plan tailored to the current state. This feedback loop continues throughout task, enabling DyFlow to adjust its reasoning trajectory in real time. encounters unexpected results, DyFlow can proactively revise the plan, retry the subgoal, or reassign suppsibbilieesssspppotnnn both high-level strategy shifts and fine- fine-grained execution corrections. Compared to prior methods such DyLAN [1]] and ReAct [16), which only adapt agent roles or individual actions, DyFlow enables dynamic restructuring at the subgoal level, offering greater robustness and flexibility in complex, real-world tasks.
framework for
subgoal fails or
While the executor does not require any additional training and can be directly instantiated using existing open-source proprietary LLMs, the designer is trained separately to acquire strong planning capabilities. To this end, we employ a two-phase learning strategy to empower lightweight models to function effective designers comparable to large proprietary models. In the initialization phase, designer trained via supervised fine-tuning on a collection of successful planning examples, allowing it acquire basic planning capabilities. This is followed by self-plat phase, where the designer interacts with the exccutor to generate its own exccution trajectories and iteratively refine its planning policy based on feedback. The resulting feedback trains the designer to favor successful plans and learn from failures. Unlike static expert demonstrations, this method internalizes the dynamic feedback loop for adaptive planning. Our approach does not impose additional training requirements on the executor, enabling direct use of existing open-source or proprietary LLMs.
We evaluate DyFlow across diverse reasoning domains, including causal, math, code, medical, and social reasoning. Experimental results demonstrate that DyFlow significantly outperforms strong baselines. Notably, it exhibits robust cross-domain generalization and adaptability to different executor models, even when deployed with unseen I.LMs.
Our contributions are summarized as follows:
We introduce DyFlow, dynamic planning framework for LLM-based agents that adaptively revises reasoning procedures based on real-time feedback. DyFlow consists of two key compo- nents: high-level designer that generates and revises subgoal plans, and low-level executor that carries out the subgoals.
We develop a designer training method that equips lightweight models with strong structured reasoning ability, achieving performance comparable proprictary LLMs.

---

We demonstrate DyFlow's robustness across diverse domains, models, and tasks through system- atic experiments covering generalization, efficiency, and ablation.
Related Work
2.1 Static and Dynamic Agentic Workflows
Many LLM-based agent systems are built upon static workflows, where agent roles, execution order, and interaction protocols are predefined and fixed throughout the task. For example, MetaGPT 9 fol- lows standard operating procedures (SOPs) encoded into prompt templates to coordinate collaborative coding, while AutoGen [5] orchestrates multi-agent dialogues through rigid communication graphs. CAMEL [10] and OpenAgents [II] further reinforce this paradigm by hard-coding agent roles or API usage. Although such designs facilitate structured cooperation, they lack the capacity to revise plans in response failures evolving context, resulting in limited robustness and adaptability.
To reduce reliance on manual design, a line of research has explored automated agent construction. AFlow 112 refines code-centric workflows using Monte Carlo Tree Search, ADAS [133] performs meta-search over agent architectures, and AgentSquare [77] evolves modular components via com- position. These systems automate workflow design, yet they still adopt one-shot planning: once constructed, the workflow remains fixed during execution. Other methods such as DyLAN [4] and MaAS [[5] dynamically configure agents select templates based task complexity, but lack mechanisms to adapt subgoal plans based on runtime feedback. More recently, ScoreFlow [18] and MaAS introduce continuous or conditional search spaces over workflows and agent architectures, offering more expressive design flexibility. However, they still treat planning as a pre-execution optimization problem, separated from the execution process itself.
2.2 Feedback-based Correction LLM Systems
Intermediate feedback has been explored for improving LLM reasoning ability across various settings. In single-agent systems, Reflexion [9] performs retrospective self-evaluation across episodes, while Tree of Thoughts (20) enables trajectory- level revision via search. DSPy [1] introduces assertion- based checks to detect and fix failures at the module level. multi-agent frameworks, AutoGen S supports retrying failed actions within fixed communication rounds.
However, these correction mechanisms have been underutilized in workflow planning. Effective correction at the workflow level requires more than recovering from execution failures, demands the ability to dynamically revise subgoal decomposition and operator selection in response to interme- diate signals. This poses stricter requirements for granularity and adaptability than existing designs can satisfy. DyFlow addresses this gap by directly integrating feedback into the planning loop. adjusts subgoal plans and operator configurations in real time based on contextual signals, enabling fine-grained and resilient reasoning workflows that evolve with task progress.
3 Methodology: DyFlow Framework
In this section, we introduce DyFlow, a reasoning framework that constructs dynamic workflows through iterative subgoal planning and feedback integration. At each step, a designer generates task-specific plan, represented as stage subgraph, which is conditioned on the current context and intermediate outputs. This design enables DyFlow to adapt its reasoning trajectory in response to execution results, offering greater flexibility than static or template-based workflows.
3.1 Formalization of DyFlow Planning
To support our dynamic workflow construction, this subsection formalizes DyFlow's planning mechanism, detailing its state representation, operator templates, and the structure of stage subgraphs.
DyFlow formulates complex reasoning tasks dynamic sequence of decision-making steps. Each task p E P requires a series of interdependent actions to reach a solution. At every step I, the system maintains state 8t, which captures the complete context necessary for planning and execution. 8 includes the original task specification, previously generated plans (Go....,G-.1. G,-1), intermediate

---

DyFlow Framework
Expert
Sample
Tasks P
Task p
Designer
Expert Trajectories
Replan
Camming K
Subgraph Gt
Distillation
SFT
Op Sequence
DyPlanner
Summarize
Generate
Iterate
play Preference
LKTO
Optimication
Op Template
Op Instance
State 85
Self-generate Trajectories
Save
V
Execution
A
Figure 2: DyFlow dynamically constructs reasoning workflows by generating stage subgraphs based on the current task state. A high-level designer plans operator sequences, while low-level executor executes them using memory. The designer is trained via supervised distillation and self-play preference optimization.
outputs such as partial answers or review verdicts, and any encountered errors. The process begins with initial state So, containing only the task itself, and this state is progressively updated the system executes each planning step.
DyFlow draws from finite set of operator templates O (O,,.... ON), each corresponding to a basic type of reasoning or execution step. These templates define reusable operations that can be instantiated according context. At each step, DyFlow constructs structured plan represented as stage subgraph G. = (V,, Ec, s Ctma). This directed graph specifies a set of actions to execute: Ve contains operator instances, each instantiated from template in O. Formally, an operator instance V, is defined as a tuple = (Ox, o, 2²), where On E O the template, & is a fine-grained instruction tailored to the current context, and is a list of input keys referencing global memory buffer M, which stores previous outputs as key-value pairs. This design allows operator instances to flexibly reuse information across reasoning steps. The edge set E, encodes dependencies between these operations, & marks the entry point execution, and C defines conditions for plan termination. A complete list of operator templates and their descriptions is provided in Appendix C
full task execution generates a trajectory T = (so: Go, 81, Gi,..,,GT-I. 8T), where each state transition 8, -> 8t+1 results from executing the corresponding plan G.. Execution halts when the system triggers a terminate action, reaches predefined step limit I max. or encounters an unrecoverable eπror. Through this formulation, DyFlow supports fine-grained, context-aware reasoning that can adaptively refine its strategy as execution unfolds. A formal theoretical analysis of DyFlow's performance under dynamic planning is included in Appendix B
3.2 Planning and Execution Process
Building on the formal definition of DyFlow's planning mechanism, this subsection describes the exccution process, focusing on the interaction between the high-level designer and the low-level exccutor during task solving.
DyFlow employs layered control structure that separates high-level planning from low-level execution, ensuring adaptability in task-solving. This design aligns broad objectives with precise actions, using the state's context to inform decisions.
The designer, implemented as a policy To with parameters 0, manages strategic planning. At step it obtains condensed state summary fsummary (8.) using GPT-4o-mini, then uses this summary determine a subgoal and generate a stage subgraph G., selecting and configuring operator instances (V)) achieve it. Formally, the designer generates:
Ge IT( fsummary
(I)

---

Algorithm DyFlow Framework for Complex Reasoning
Require: Task p, templates O, designer тo, executor Texec, budget max, summarizer faummary
Ensure: Final answer 8y and trajectory r
I: So { []; M < {
initial state, trace, and empty memory dictionary
2: for ( 0 Tmax - do
D summarize context and sample stage subgraph 4: for each = (Ox, Φ 15) E Ve (topological order) do
3: Zt + Ssummary (8e): G2 (. 2x)
5: Retrieve inputs [M]]] & b
> &b is list of keys. M is a dictionary
6: r- Texco (0, [M[k] k E +))
7:
Generate unique key k, for 8: M[k,] +
> e.g., by operator id or execution order >> store output in memory dictionary
9:
end for
10: Sc+1 t Uptate Gt, M); (sp, Gt))
D update state and record step
if C satisfied or TERMINATE then
12:
break
> stop if designer signals completion
13: end
14:
end for
15:
return ST. T
v where G. = (V1, Fe, Vatan Cema) and each operator instance o E V2 is defined as (Ox: Φ v) with O₂ E The graph structure is designed to guide step-specific reasoning toward subgoal resolution.
Unlike prior frameworks such as AFlow, MaAS [12 [5], which implement control structures like branching or looping via explicit edge logic in code-based graphs, DyFlow adopts designer-centric design. Instead of hardcoding control flow into the graph topology, we delegate all execution control to the designer. At each planning step, the designer observes the current state, including intermediate outputs, eтror signals, and planning history, and decides whether proceed, revise, backtrack. or terminate. This allows DyFlow to simulate conditional and iterative behaviors (such as if-else statements or while loops) through repeated subgraph planning, without relying on manually defined edge logic. As a result, dynamic workflows emerge naturally from context-aware decision making, which simplifies graph construction and enhances flexibility across tasks.
The workflow executor translates this plan into action. Given G, and st, it carries out the operator instances in V2 according to the dependencies in E,, beginning with v E Vv, For each operator (Ok, o, 2 the executor retrieves required inputs from the memory buffer M according to 1h executes the operation via Texee and appends the result back M. The updated memory is then used to construct the next state $t+1 = Executor Gt). This mechanism ensures both consistent information flow and persistent memory accumulation across planning steps. The full procedure is summarized in Algorithm [ which outlines the iterative interaction between the designer and executor.
3.3 Distilled Self-Play Learning
While the executor requires no additional training and can be directly instantiated using existing LLMs, the designer is trained separately to develop strong planning capabilities. We train the designer policy np using a two- wyo-phase method that combines knowledge distillation with self-play preference optimization [22 23 224]. The goal is to enable the designer to construct context-sensitive subgoal plans that improve execution outcomes. While the executor remains fixed throughout, the designer is trained to dynamically generate structured reasoning workflows.
The learning process begins by generating trajectories = (so, Gu, $1, GI...., Gr using the current or a past version of the policy To across diverse set of tasks. Each trajectory is executed by the workflow executor, and its outcome is compared to the correct solution to assess success. For successful trajectories, all stage-subgraph pairs (Ssummary(*;; ) G.) are labeled as "preferred," reflecting effective planning. For failed trajectories, the corresponding pairs are labeled as "discarded," capturing planning errors. All positive and negative examples are derived from these self-play trajectories, enabling the designer to learn from its own performance.
5

---

In the first phase, knowledge distillation initializes to generate reliable subgraphs. Using a dataset DSFT = ([ssumarry ($t), G)) }} of high-quality subgraphs from successful trajectories to optimize:
[ SSFT DSFT) = (= IT (G [
(2)
This process distills knowledge from successful trajectories, producing the reference policy Wee for the next phase.
In the second phase, self-play preference optimization refines To to favor subgraphs that lead to successful outcomes using KTO [23]. Using dataset pref = {(Ssummary( ( Gr,4); collected from self-generated trajectories produced by current or past policies, where 4 E {preferred, discarded) in- dicates whether the subgraph is positive or negative based on the trajectory's success, the optimization encourages effective planning:
Cerer (0; Drict. Tet. B) = Dear [Frict (pe, Pret. 1; .)
Here, E (preferred, discarded) indicates whether the subgraph is effective or not, and ,3 is hyperparameter controlling the strength of preference alignment. Here, Liper" is computed based on whether each subgraph G is labeled as preferred or discarded, with 3 controlling the alignment strength between my and Tee-- By leveraging feedback from self-generated trajectories, this off-policy self-play phase ensures the designer makes context-sensitive, adaptive decisions. This iterative self-improvement strategy equips DyFlow deliver robust and versatile reasoning capabilities across a wide range of applications.
Preference Optimization Strategy. We adopt trajectory-level supervision for preference optimiza- tion, using full execution success or failure as the training signal. Assigning fine-grained rewards to individual subgraphs unreliable in complex reasoning tasks, where even well-formed plans may fail due to executor variability. For similar reasons, we avoid DPO-style pairwise ranking [24], as it is often infeasible construct clear positive-negative plan pairs: execution outcomes depend on downstream decisions, and the better plan is not always evident from intermediate states. Online rein- forcement learning poses additional challenges, reward signals are typically sparse and delayed, and using LLM--bsed judges introduces high variance due to inconsistent evaluations across steps. [25 In contrast, our offline self-play setup with KTO (23 provides a more stable learning process, enabling effective designer refinement from diverse execution trajectories.
4 Experiments
We conduct comprehensive experiments to evaluate DyFlow across five reasoning domains. Our goals assess its performance advantage over existing agent planning frameworks, its generalization capabilities to unseen datasets and exccutor models, the contribution of each component through ablation studies, and qualitative behaviors through case analyses.
4.1 Experimental Setup
Datasets. We consider 5 diverse reasoning domains, each represented by a benchmark dataset: (1) Logical Reasoning using the LiveBench dataset [26]. (2) Math Reasoning using the MATH bench-
mark 27 (3) Medical Reasoning with PubMedQA 4 (4) Code Reasoning via HumanEval (28), and (5) Social Reasoning using the SocialMaze 29 benchmark. These datasets differ in their input
structures, intermediate reasoning steps, and solution formats, and together cover a broad spectrum of reasoning behaviors.
Implement Details. DyFlow trained only on MATH, PubMedQA, and LiveBench. HumanEval and SocialMaze are held out to assess zero-shot generalization to unseen reasoning domains. To avoid contamination and ensure valid knowledge separation between the designer and executor, we use Phi-4 [30] as the executor model, and train a designer we refer to as DyPlanner, which is initialized from Phi-4 and optimized using the DyFlow training framework. The initial distillation during pretraining is conducted using 1PT-4.1 [3I,, based on trajectories generated only from our training set. inference time, both the designer and the executor are run with temperature 0.01 to ensure stable and deterministic behaviors.

---

Table 1: Performance comparison across five reasoning domains. All methods use phi-4 as the executor. Bold marks the best score in each column. The figures in / indicate the absolute change with respect to the Vanilla baseline.
Method
SocialMaze
PubMedQA
MATH
LiveBench
HumanEval
Avg.
Vanilla
6.49
67.33
66.80
40.00
86.59
53,44
CoT
6.11..0.88
47.73
71.20p4.40
39.33.gm67
87.80
54,4310.99
SC 33
10.31 n3.82
28,53
71.60pa.0
42.00y200
87.20
55.93
L.-M-Debate
12.59 16110
1
72.40r560
41.33
64.15.22.4
55.80p2.6
Self Refine 34
10.69
1..
70.4013.60
35.67
81.71
53.36,0.08
ADAS 13
6. 10.38
67.3
66. 66.80
39.33
85.37
52.99
AFlow
11,45 14.96
69.72
74.00,7.00
43.33
89.0212.43
57.50p4.06
MaAS 13
13.3676.87
69.32
73.60
44.00
n8.8
57.74,4.30
DyFlow (Ours)
17.18110.69
72.91
76.40,9.00
48.67
92.07
61.45
Baselines. We compare DyFlow with comprehensive set of baselines across two categories: (1) Prompting caappting-based based methods, including Vanilla prompting, CoT [32]. Self-Consistency (SC) 33
LLM-Debate (8], and Self-Refine [34]. (2) Automated Agent frameworks, including ADAS [3] AFlow [12] and MaAS [15]. which introduce structured reasoning workflows with varying degrees of adaptivity. All methods use the same executor (Phi-4) and operator set for fair comparison, and are evaluated under consistent metries: accuracy for most tasks and pass @ for code reasoning.
4.1.1 Performance Comparison
Overall Performance Table I reports the performance of DyFlow and all baselines across five reasoning domains. DyFlow consistently outperforms prior methods, achieving the highest average accuracy (61.45) with improvements observed across logic, math, medical, code, and social reasoning tasks. Notably, while trained only on MATH, PubMedQA, and LiveBench, DyFlow generalizes robustly to the held-out HumanEval and SocialMaze benchmarks. These results highlight the trans- ferability of DyFlow's adaptive planning strategy across structurally diverse domains. In particular, DyFlow achieves 17.18 on SocialMaze, challenging multi-turn benchmark that requires high-level reasoning, substantially outperforming all baselines in this zero-shot setting. This strong performance demonstrates that DyFlow's 's feedback-driven, adaptive planning enables effective subgoal revision and robust reasoning, even on previously unseen, highly complex tasks.
Planning Upper Bound and Stability In addition to @ 1, we further evaluate the performance of DyFlow under the top-k setting. As shown in Fig- ure 3 DyFlow consistently outperforms CoT across all k values from to 5, with increasingly wider mar- gins at higher k. This indicates that DyFlow not only generates more accurate first predictions, but also demonstrates greater reasoning stability across mul- tiple completions, with a higher potential to produce strong solutions.
+
Dyflow
Average Score
0.69
0.59
Figure 3: Average pass @k comparisons be- tween DyFlow and CoT across 5 benchmarks.
Notably, DyFlow reaches a near-perte wear-perfect P of 0.9817 on Hvaa highlighting the framework's strong reasoning upper bound on code tasks. Moreover, consistent improvements medical, logical, and math domains suggest that DyFlow enhances both accuracy and diversity of reasoning paths. Per-task breakdowns of Pass curves are included in Figure which reveal similar trends across all domains.

---

Table 2: Performance of DyFlow with different designer models across five reasoning domains. All designers are trained using the same pipeline. Detailed cost of different designers is in Figure
Designer Model
SocialMaze
PubMedQA
MATH
LiveBench
HumanEval
Average
MaAS [S
13.36
69.32
73.60
44.00
88.41
58.40
Claude-3.7-Soonet
16.41
71.71
75.60
50.00
92.07
61.16
GPT-4.1
79
72.11
73.60
47.03
89.63
59.83
DyPlanner
17.18
72.91
76.40
92.07
61.45
GPT-4o-mini
Phi
GPT-4.1
Human
Live
MATH
+0.4
+0.3
+3.4
+20
Maze 10.0
0CT Syttem
111.1
Dytten
211
Figure 4: Cross-executor performance comparison between CoT and DyFlow across five reasoning tasks. DyFlow improves performance across all model scales, with larger gains for stronger models on more challenging tasks. Detailed results provided in Appendix D.5 Table I0
4.2 Generalization Analysis
This section evaluates DyFlow's generalization capabilities across three dimensions: designer models, execution models, and datasets. Each dimension demonstrates DyFlow's ability to maintain robust performance under varying conditions, leveraging its adaptive planning mechanisms.
Cross-Deste Cross-Designer Generalization To assess the robustness of our training framework across different designer architectures. apply the same DyFlow learning pipeline three backbone models: Claude-3.7-Sonne, GPT-4.1, and Phi-4. We include MaAS as the strongest existing baseline.
As shown in Table 2 DyFlow consistently outperforms MaAS across all designer backbones. More specifically, our DyPlanner is initialized from the 14B open-weight Phi-4 model. Despite its relatively small scale, DyPlanner achieves performance comparable to larger proprietary designers such as GPT-4.1 and Claude-3.7-Sonnce across most domains. This demonstrates that DyFlow's strong planning capability does not stem from model size alone, but also from dedicated two-phase optimization strategy. By combining supervised subgraph distillation with offline preference- based refinement, equip compact model with the ability perform high-quality structured planning across diverse tasks. As shown in Table 9 DyPlanner offers a more cost-efficient and scalable alternative without sacrificing performance. These results suggest that dynamic, feedback-aware designers can emerge from lightweight open models when trained with appropriate trajectory-level signals, making DyFlow well-suited for real-world deployment
cooource-constriinee settings.
Pross-Executor Generalization To further evaluate DyFlow's generalization capability across executor mod- els, we compare performance with CoT prompting using three different executors: GPT-4o-mini, Phi-4, and GPT-4.1-mimt All DyFlow variants in this setting use the same DyPlanner. As shown in Figure 4 DyFlow con- sistently improves performance across all exccutors and reasoning domains, demonstrating its compatibility with wide range of language models without requiring executor- specific adaptation.
Table 3: Cross-task generalization. Each test domain is excluded during training,
Test
Train
CoT
Dy Flow
SR
MR, QR, LR
6.11
17.18
CR
MR, QR, LR
87.80
92.07
MR
CR, LR, SR
71.08
75.20
QR
CR.
67.73
72.11
The gains are especially notable when DyFlow is paired with stronger executors and applied to more complex tasks. For instance, Phi-4 with DyFlow achieves performance close to GPT-4.1-mine with CoT, while incurring only half the cost. When applied to GPT-4. 1-mini, DyFlow brings further improvements, particularly SocialMaze and LiveBench. These results indicate that structured

---

planning from DyPlanner enhances reasoning quality and stability across a variety of executor backbones.
Cross-Task Generalization To evaluate cross-task generalization, we construct a series of held-out settings where the designer is trained on subset of three reasoning domains and tested on the remaining two. For each setting, we select three domains from SocialMaze, PubMedQA, MATH, LiveBench, and HumanEval for training, and evaluate performance on the two excluded domains. For example, when training MATH, PubMedQA, and LiveBench, we test SocialMaze and HumanEval. Similarly, other combinations ensure that each domain excluded from training in at least one setting. As shown in Table B DyFlow achieves strong performance across the held-out domains, demonstrating that its designer can generalize planning strategics to structurally diverse, unseen reasoning tasks without task-specific supervision.
Table 4: Ablation study on DyFlow using DyPlanner as the designer and Phi-4 as the executor. The full system outperforms all ablated variants across five reasoning tasks.
Variant
SocialMaze
PubMedQA
MATH
LiveBench
HumanEval
Avg.
w/o KTO
13.36
68.53
72.40
43.33
89.63
57.45
w/o SFT
15.65
69.32
73.20
45.33
91.46
59.00
w/o Dynamic Operator
12.21
68.92
72.80
40.67
90.24
56.97
woo Dynamic Planning
11.45
68.53
72.80
40.00
89.63
56.48
DyFlow (Full)
17.18
72.91
76.40
48.67
92.07
61.45
4.3
Ablation Study
To assess the contribution of DyFlow's core components, we conduct ablation experiments targeting both the designer training process and the execution-time mechanisms, as summarized in Table On the training side, we remove either the knowledge distillation (SFT) or the offline preference optimization (KTO). Both lead consistent drops performance, indicating that these two phases are complementary: SFT provides structural guidance for initializing the designer, while KTO enables refinement based on trajectory- selection forces the executor to follow fixed-stage template, reducing its ability to adjust reasoning based on intermediate results.
feedback. On the execution side, disabling dynamic operator
The largest degradation is observed when dynamic plan- ning is removed. In this setting, we prompt DyPlanner complete the entire problem in a single reasoning stage without receiving intermediate feedback. This design pre- vents the designer from iteratively refining subgoals in response exccution signals, undermining DyFlow's cen- tral mechanism of feedback-drive replanning. Together, these results demonstrate that DyFlow's gains emerge from the synergy between structured designer training and dy- namic subgoal adaptation during execution.
Question: Gives
whereb 10, sis compate the positice difference between two possibl values BC Graund Truth: 16
Decompase
Refine
Terminate
CoT
DyFlow
Stop Identity Angl Reeeggiee that 8.6, impbying B
Simplify
Compute Check
2 Step 2: Chorse Branch Prossed only with casfi-
4.4
Case Study
6.K, assuming one angle.
We conduct a qualitative comparison between FyFlow and standard reasoning baseline without error correction. The baseline generates fixed reasoning path based on initial inputs and executes it without revisiting intermedi- ate outputs, making it susceptible to early mistakes and incomplete solutions. As illustrated in Figure [5) DyFlow instead treats planning as an ongoing process. Guided by the designer, dynamically assigns operators based on intermediate feedback and task state. When execution produces partial or inconsistent outputs, DyFlow adapts its subgoal plan and invokes refinement operators to identify and correct reasoning errors during runtime. This includes dynamically selecting
Compute Only compute BC1, abtaining
Mix Gaps
Acrpp
Critiot Mirinn Samare
Finelize: Anewer
Figure 5: Case Study between CoT and DyFlow on MATH dataset.

---

the appropriate data inputs, adjusting instructions, and refining intermediate results using targeted operator calls.
Conclusion
In this paper, we presented DyFlow, a framework for dynamic workflow construction in LL-M-based reasoning systems. By modeling reasoning subgraph planning with modular operator execution, DyFlow enables flexible adaptation intermediate feedback and diverse task requirements. Our evaluations across five reasoning domains demonstrate that DyFlow improves task success rates and generalizes across diverse reasoning tasks. Future work may explore integrating richer error detection signals and expanding the operator set to support more complex interaction protocols.
References
[1] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.088 087777744 2023.
[2] Zirui Song, Guangxian Ouyang, Meng Fang, Hongbin Na, Zijing Shi, Zhenhao Chen, Yujie Fu, Zeyu Zhang, Shiyu Jiang. Miao Fang, et al. Hazards in daily life? enabling robots proactively detect and resolve anomalies. NAACI, 2024.
[3] Yuyang Song. Hanxu Yan, Jiale Lao, Yibo Wang, Yufei Li, Yuanchun Zhou, Jianguo Wang, and Mingjie Tang. Quite: A query rewrite system beyond rules with 1lm agents. arXiv preprint wrX1v:2506.07675, 2025.
[4] Qiao Jin, Bhuwan Dhingra, Zhengping Liu, William W Cohen, and Xinghua Lu. Pubmedqa: A dataset for biomedical research question answering. arXiv preprint
2019.
[5] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li. Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, et al. Autogen: Enabling next-gen Ilm applications via multi-agent conversation. arXiv preprint arXiv: arXiv:2308.0815.. 2023.
[6] Zirui Song, Bin Yan, Yuhan Liu, Miao Fang, Mingzhe Li, Rui Yan, and Xiuying Chen, Injecting domain-specific knowledge into large language models: comprehensive survey. arXiv preprint arXiv:2502. 10708, 2025.
[7] Chenxi Wang. Tianle Gu, Zhongyu Wei, Lang Gao, Zirui Song, and Xiuying Chen. Word form matters: Lims' semantic reconstruction under typoglycemia. arXiv preprint arXiv:2503.01714 2025.
[8] Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. Improv- ing factuality and reasoning in language models through multiagent debate. In Forty-first International Conference on Machine Learning, 2023.
[9] Sirui Hong, Xiawu Zheng, Jonathan Chen, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, et al. Metagpt: Meta programming for agent collaborative framework. arXiv preprint arXiv:2308.00 00352, 3(4):6, 2023.
[10] Guohao Li, Hasan Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. Camel: Communicative agents for" mind" exploration of large language model society. Advances in -20008 2023.
Neural Information Processing Systems,
[11] Tianbao Xie, Fan Zhou, Zhoujun Cheng, Peng Shi, Luoxuan Weng, Yitao Liu, Toh Jing Hua, Junning Zhao, Qian Liu, Che Liu, et al. Openagents: An open platform for language agents in the wild. arXiv preprint arXiv:2310 10634, 2023.
[12] Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xionghui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, et al. Aflow: Automating agentic workflow generation. arXiv preprint 211112241 2024.
10

---

[13] Shengran Hu, Cong Lu, and Jeff Clune. Automated design of agentic systems. arXiv preprint Sttt:22008.084333. 2024.
[14] Zijun Liu, Yanzhe Zhang, Peng Li, Yang Liu, and Diyi Yang. Dynamic Ilm-agent net- work: An Ilm-agent collaboration framework with agent team optimization. arXiv preprint arXiv:2310.02170, 2023.
[15] Guibin Zhang, Luyang Niu, Junfeng Fang, Kun Wang, Lei Bai, and Xiang Wang. Multi-agent architecture search via agentic supernet. arXiv preprint arXiv:2502.04/800 2025.
[16] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR), 2023.
[17] Yu Shang, Yu Li, Keyu Zhao, Likai Ma, Jiahe Liu, Fengli Xu, and Yong Li. Agentsquare: Automatic Ilm agent search in modular design space. arXiv preprint arXiv:2410.06/53 2024.
[18] Yinjie Wang, Ling Yang, Guohao Li, Mengdi Wang, and Bryon Aragam. Scoreflow: Mastering IIm agent workflows via score-based preference optimization. arXiv preprint arXiv:2502.04300
2025.
[19] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems, 36:8634-8652 2023.
[20] Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models. Ad- vances in neural information processing systems, 36: 1809-11882, 2023.
[21] Omar Khattab, Arnay Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T Joshi, Hanna Moazam, et al. Dspy: Compiling declarative language model calls into self-improving pipelines. arXiv preprint arXiv:2310.03714, 2023.
[22] Long Ouyang, Jeffrey Wu, Xu Jiang, Diogo Almeida, Carroll Wainwright, Pamela Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Slama, Alex Ray, et al. Training language models to follow instructions with human feedback. Advances in neural information processing systems, 35:27730-27744, 2022.
[23] Kawin Ethayarajh, Winnie Xu, Niklas Muennighoff, Dan Jurafsky, and Douwe Kiela. Kto: Model alignment as prospect theoretic optimization. arXiv preprini arXiv:2402.01 3166, 2024.
[24] Rafael Rafailov, Archit Sharma, Eric Mitchell, Christopher D Mamning, Stefano Ermon, and Chelsea Finn. Direct preference optimization: Your language model is secretly reward model. Advances in Neural Information Processing Systems, 36:53728-53741, 2023.
[25] Jiayi Ye, Yanbo Wang, Yue Huang, Dongping Chen, Qihui Zhang, Nuno Moniz, Tian Gao, Werner Geyer, Chao Huang, Pin- Yu Chen, et al. Justice or prejudice? quantifying biases in llm-as-a-judge. arXiv preprint 1rxiv:2410.007336 2024.
[26] Colin White, Samuel Dooley, Manley Roberts, Arka Pal, Ben Feuer, Siddhartha Jain, Ravid Shwartz-Ziv, Neel Jain, Khalid Saifullah. Siddartha Naidu, et al. Livebench: A challenging, contamination-frre 11m benchmark. arXiv preprint arXiv:2406.199 193144 2024.
[27] Dan Hendrycks, Collin Burns, Sauray Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. Measuring mathematical problem solving with the math dataset. NeurIPS, 2021.
[28] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 2021.
[29] Zixiang Xu, Yanbo Wang, Yue Huang, Jiayi Ye, Haomin Zhuang, Zirui Song, Lang Gao, Chenxi Wang, Zhaorun Chen, Yujun Zhou, et al. Socialmaze: A benchmark for evaluating social reasoning in large language models. arXiv preprint 20ox.::25055.711333 2025.
11

---

[30] Marah Abdin, Jyoti Aneja, Harkirat Behl, Sébastien Bubeck, Ronen Eldan, Suriya Gunasekar, Michael Harrison, Russell Hewett, Mojan Javaheripi, Piero Kauffmann, et al. Phi-4 technical report. arXiv preprint arXiv:2412008905, 2024.
[31]
OpenAl. Gpt-4.1 technical overview. http:://ppeeaa.ccoon/nne////--- 2024.
[32] Jason Wei, Xuezhi Wang. Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoe V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems, 25:24724-24837, 2022.
[33] Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. Self-consistnncy improves chain of thought reasoning in language models. arXiv preprint arXiv:2203.11121 2022.
[34] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah W, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. Self-refine: Iterative refinement with feldaake, Advances in Neural Information Processing Systems, 36:46534 46594, 2023.
[35] Karl Johan Äström and Richard Murray. Feedback systems: an introduction for scientists and engineers. Princeton university press, 2021.
[36] Sirui Hong, Yizhang Lin, Bang Liu, Bangbang Liu, Binhao Wu, Ceyao Zhang, Chenxing Wei, Danyang Li, Jiaqi Chen, Jiayi Zhang, et al. Data interpreter: An Ilm agent for data science. arXiv preprint uxXiv2442.188779 2024.
[37] Edward Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen, et al. Lora: Low-rank adaptation of large language models. ICLR, 1()):3, 2022.
[38] Siru Ouyang, Zhuosheng Zhang, Bing Yan, Xuan Liu, Yejin Choi, Jiawei Han, and Lianhui Qin. Structured chemistry reasoning with large language models, arXiv preprint arXiv:2311.00 1.00666, 2023.
12

---

NeurIPS Paper Checklist
1. Claims
Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Question:
Answer: [Yes]
Justification: The abstract and introduction clearly state the proposed DyFlow framework, its hicrarchical designer-executor structure, its feedback-driven planning strategy, and its performance across multiple reasoning tasks, all of which align with the main contributions.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made the paper and important assumptions and limitations. A No or NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification: The Limitation section in the Appendix explicitly discusses current limitations of DyFlow, including its symbolic-orienter operator set and the need for extension to support tool-using embodied reasoning tasks. Additional limitations are also discussed in the conclusion.
Guidelines:
The answer NA means that the paper has limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution low or images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed not penalize honesty concerning limitations.
3. Theory assumptions and proofs
13

---

Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [Yes]
Justification: Theoretical guarantees, including Theorem and Theorem 2 (Appendix B), stated with clear assumptions and complete proofs that compare DyFlow to static baselines and analyze Bellman residual bounds.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged provide short proof sketch to provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Answer: [Yes]
Justification: The Experiments section and Appendix D (Experiment Details) disclose all necessary information for reproducing the main results, including dataset specifications, model initialization, LoRA A-based tuning configurations, training and inference parameters, and evaluation metrics.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily the architecture clearly and fully.
model architecture, the paper should describe
(c) the contribution a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
14

---

(d)
We recognize that reproducibility may be tricky in some cases, in which case authors are welcome describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
Question: Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Answer: [Yes]
Justification: Appendix C (Modular Operators) and Appendix D (Experiment Details) provide the full operator list, training procedure, and inference setup. anonymized version of the code and detailed reproduction instructions will be included in the supplemental material.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips... cc/
public/uuides/Ceee
for more details.
While we encourage the release of code and data, we understand that this might be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
/ ctaips.cc/publcc/gu.d.oo
for more details.
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the proposed method and baselines. only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing much information possible in supplemental material (appended the paper) is recommended, but including URLs to data and code is permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
The Experiments section and Appendix D provide detailed training and evaluation setups, including dataset splits, hyperparameters (e.g., learning rate, batch size, number of epochs), LoRA adaptation, optimizer choice, and inference- decoding configurations.
Justification:
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
15

---

Answer: [No]
Justification: Formal error bars (e.g., standard deviation or confidence intervals) are not explicitly reported in the main experimental tables due the significant computational cost associated with running multiple trials across all diverse experimental configurations. including various datasets and executor models. However, the paper presents detailed performance breakdowns across different domains and executor models (Tables 1, 4. 10 and Figures 3, 4, 7), and the consistency of the observed improvements provides empirical evidence for the robustness and significance of DyFlow's contributions.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by enror bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula,
call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
should be clear whether the error bar is the standard deviation the standard error of the mean.
It is OK to report I-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Question:
Answer: [Yes]
Justification: Appendix D.2 (Designer Training) and D.3 (Inference and Evaluation) specify compute resources used in the experiments, including the use of NVIDIA A6000 GPUs for training and Phi-4 model for inference, along with batch size, sequence length, and runtime settings.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported the paper (e.g., preliminary or failed experiments that didn't 'i make it into the paper).
9. Code ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurlPS Code of Ethics
Answer: [Yes]
Justification: The research does not involve human subjects, personally identifiable informa- tion, or sensitive data. All datasets used are publicly available and cited appropriately, and the study fully adheres to the NeurlPS Code of Ethics.
16

---

Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g.. if there is special consid- eration due to laws or regulations their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification: The paper primarily highlights the positive societal impacts of DyFlow, such as contributing to more robust, generalizable, and controllable Al reasoning systems (Intro- duction). However, we acknowledge that, like other advanced LLM-based agentic systems, DyFlow could potentially be misused not deployed responsibly. Potential negative im- pacts could include the generation of convincing but incorrect biased information if the underlying LLMs or feedback mechanisms have flaws, or the inadvertent reinforcement of societal biases present in the training data. Furthermore, the increasing capability of autonomous agents raises broader socictal questions regarding accountability and potential misuse in sensitive applications. While DyFlow itself is foundational framework aimed at improving reasoning, responsible development and deployment practices are crucial to mitigate these risks.
Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deploymentt of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Answer: [NA]
The paper does not release models or datasets that carry high misuse potential. The DyPlanner model is trained on standard reasoning datasets and does not involve private, offensive, or uncontrolled data sources.
Justification:
Guidelines:
17

---

The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards challenging, and many papers do not require this, but encourage authors to take this into account and make best faith effort.
Licenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: All datasets and base models (e.g.. Phi-4, GPT-4.1) used in the paper publicly available and cited in the main text. Each is used in accordance with its license or public usage terms, as provided by the respective platforms publications.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset used and, possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (c.g.. website). the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, wwpppswiptchooeo thcode. com/ datasets has curated licenses for some datasets. Their licensing guide can help determine the license dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if has changed) should be provided.
this information is not available online, the authors are encouraged to reach out to the asset's is creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: We introduce modular operator set and dynamic planner model (DyPlanner), documented Appendix C and Appendix D. The supplemental material will include instructions for using these components. An anonymized version will be provided at submission time.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create anonymized URL or include anonymized zip file.
14. Crowdsourcing and research with human subjects
18

---

Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?
Answer: [NA]
Justification: The paper does not involve any crowdsourcing tasks or experiments with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included the main paper.
According to the NeurIPS Code of Ethics, workers involved in data collection, curation, other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification: No human subjects were involved in the research, so IRB approval was not required.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing research with human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, formatting purposes and does not impact the core methodology, scientific rigorousness, originality of the research, declaration is not required.
Question:
Answer: [NA]
Justification: LLM is used only for writing, editing, or formatting purposes.
Guidelines:
The answer NA means that the core method development in this research does involve LLMs as any important, original, or non-standard components.
Please refer to our LLM policy hettps//hearrrss..ccoaoeeerereee for what should or should be described.
19

---

A
Notations
We summarize the key notations used throughout the DyFlow framework in Table These notations cover the planning state space, operator structure, execution dynamics, and training objectives for optimizing the designer policy.
Table 5: Key notations used in the DyFlow framework.
Symbol
Definition
p
reasoning task sampled from a task distribution.
St
Full system state discrete step including task inputs and execution history. A fixed set of operator templates specifying reusable functional behaviors.
G
Stage subgraph constructed at step t: G, (V,, Ee, tiuns Cend)-
An operator instance, formally represented as (Ox, Φ, v)) with O₂ E O.
Ø
Fine-grained instruction string instantiated from template Oş based on context. Input reference list indexing outputs from memory buffer M.
M
Global memory storing intermediate outputs generated hy executed operators. Learnable planner (designer) policy that generates G. from current state summary. Parameters of the planner policy He trained via SFT and KTO.
0
[summary (st)
Function that summarizes full state 8; into condensed representation.
Summarized context at step t: 21 faumnary (8t).
Texe
Fixed executor policy used to run operator instances during workflow execution. Full execution trajectory: T = (so, Go, $1, Ci...., 87).
T
LSPT
Supervised fine-tuning loss used to initialize the planner xo-
DAFT
Dataset of successful planning trajectories used for supervised training.
Wee
Reference planner derived from SFT, used during preference optimization.
Lpee
Preference optimization loss (e.g.. KTO), aligning we with effective plans.
Dyne
Labeled trajectory set used for preference-based policy refinement.
B Theoretical Analysis
DyFlow is never worse than static method We consider a distribution D over reasoning tasks p. Each task is solved by executing sequence of stage subgraphs {Gr [T-1 yielding return R(p; T))
Define Equation 4 as objective function.
((T) = Epor [(pp)))
Each reasoning task p is modeled as finite-horizon decision process (8, O, P.r,, T') with bounded rewards, finite state space S, and operator set O. A static policy ssttt applies the same subgraph Gix throughout regardless of context (i.e. Tstat(s:) = Gáx), while the DyFlow policy Dy chooses G, as described in Eqquaiin 5] based on the full state st, including intermediate outputs and error signals.
G.
= DyFloow (Feummary
(5)
Lemma 1 (Static Policies as Special Case). Tgtat C HDyPlow. any static wstat can be imple- mented by DyFlow by ignoring & and always returning Gix-
Theorem (DyFlow Is Never Worse Than Static).
max
((x) 2
J(T).
(6)
rEllpyFlow
wEll
Moreover, if there exists a lask po, for which feedbuck-driver replanning strictly improves return, then
max nellnyFlow
J(x)
max
J(T)-
(7)
nEllass
Proof 1. Since 1ssta C IIDyFlow by Lemmal 7 optimizing over the larger set IlDw only increase (or match) the best static return like Equation
max
((T)
2
max (TT)
(8)
HellpyFlow
Hc Hlaas
20

---

In stochastic error-prone environments, a closed-looy DyFlow policy can correct deviations in real time-e.g. via peglanning-yielddinn strictly higher return on some task Po [35]. Hence the inequality becomes strict.
Convergence proof of DyFlow We model each reasoning task p as finite-horizon MDP of length T. For L .., let (s); v.D(s) denote the optimal and DyFlow value functions when there are steps remaining from state At step I, DyFlow observes 8t, computes the summary 2t [summary (8t), and samples a subgraph G. ~ #DyFlow 2t) Executing G. yields reward (5rr, G+) and transitions to Sc-1-
One-step Bellman operator can be operated for such MDP process with DyFlow one-step lookup feature denoted as Equation 9
(s; G() + Bs>PPHa,,)(((
and quantify DyFlow's ' per-step suboptimality by the Bellman residual
6z max max T.V T.V ()
T.V
(10)
DyFlow's hackup step
optimal backup step
Let 6t 2 5, be uniform upper bound this residual.
Lemma 2 (Error propagation). For any t = 0, o......, T and state s, the gap between the optimal and DyFlow value functions with steps remaining satisfies EEquation 17]
(8)
V.
&k
(11)
R=1
Proof. Case 1. With zero steps remaining, both Vi (s) and Vo (s) equal the terminal reward (here normalized to 0), so the inequality holds.
Case 2. Assume the claim for - 1. Then for horizon t,
(i) Dy (s) max 1s; (s; Split into parts:
max TVV - TVV + max 1 G) max Te TVV (s: G).
S8.5Er
Ssup, (=')((1)-1) (1
By the inductive hypothesis, sup,r (52((5) (s)) 5 - Ek. Hence
t-1
(s)) - 1/ (8) S Et +
Σ
k=1
1=1
completing the induction.
Theorem (DyFlow performance bound). Starting from initial state so with horizon T along with Lemma 2
(su) VT V>Dy(su)
(su)
S
Ek S T
max Ek. 1SKST
C Operators
DyFlow employs modular and reusable operator templates to support flexible reasoning workflows. Each operator defines specific functional role and is instantiated dynamically by the planner during execution. We summarize all templates used DyFlow and analyze their usage patterns across reasoning domains.
21

---

C.1 Operator Templates
Table 6 summarizes all operator templates used by DyFlow. Each template corresponds modular and reusable functional unit. During execution, the designer instantiates these templates with fine- grained instructions (() and dynamic inputs (1)) based on the current context.
Table DyFlow operator templates and their functional roles.
Template Name
Description
GENERATE_ PLLA
Propose a high-level plan for solving the current subgoal.
DECOMPOSE_ PROOBEEM
Break a complex goal into subgoals.
GENERATE, GENERATE_ANSWER ANSWER
Produce answer candidate for the current task.
REVIEN_SOLUTION
Evaluate correctness or completeness of a prior answer.
REFINE_ ANSWER
Modify or improve a previously generated answer.
GENERATE_CODE
Write code to solve the current subgoal.
REFINE_CODD CODE
Improve or debug previously generated code.
ORGANIZE_ SOOUUTION
Summarize or structure the final answer for output.
ENSEMBLE
Aggregate multiple reasoning paths using voting.
DEFAULT
General-purpose fallback operator. End the workflow once the solution is complete.
TERMINATE
C.2 Operator Usage Analysis
Figure 6 summarizes the frequency of operator usage different reasoning domains. We observe that operators like REVIEM_SOLUTION, TERMINATE, and ORGANIZE_ appear fre- quently across all tasks, reflecting their general-purpose utility. In contrast, operators such as DECOMPOSE, PROBLEM, REFINE WNSWER, and GENERATE, PLAN are more selectively used in complex domains like LiveBench and SocialMaze, where dynamic adaptation and structure restructuring are more critical.
250
MATE:
Livebaao
PubMeedo
SuctadRissccning
Hunusbral
150
Coun:
100
SOLUTIOO
ANSWER
SOLAITION
PROBLEM
ANSWER
PLAN
DODE
DODE
Figure 6: Operator usage frequency across reasoning domains. Task-specific patterns reflect how DyFlow dynamically adjusts workflow structure based on domain complexity and intermediate feedback.
22

---

D Experiment Details
D.1 Dataset Statistics
Table 7 summarizes the dataset statistics used in our experiments. We adopt a default TRAIN:TEST
split ratio of approximately 1:3 across all datasets to balance supervision and evaluation coverage. For the MATH benchmark, follow the setting MaAS [36]. selecting problems at difficulty level 5 across four representative categories: Combinatorics & Probability, Number Theory, Pre-algebra, and Pre-calculus. For HumanEval, when it is not included in the training set, we evaluate on the full 164 problems to ensure consistency with prior work.
Table 7: Train/test statistics for each dataset.
Domain
Dataset
#Train
#Test
Metric
Social Reasoning
SocialMaze
87
262
Accuracy
Medical Reasoning
PubMedQA
84
251
Accuracy
Math Reasoning
MATH
84
250
Accuracy
Logic Reasoning
LiveBench
50
150
Accuracy
Code Reasoning
HumanEval
55
109
pass @1 1
D.2 Designer Training
We use Phi-4 [30] as the designer policy trained on 2 Nvidia A6000 GPUs with LoRA-based parameter-efficient tuning (37). Training proceeds in two stages. First, supervised fine-tuning is performed on 1.5k design results from MATH, PubMedQA, and Livebench, using a cutoff length of 2048, batch size with gradient accumulation steps of 4, learning rate 10 10-6 cosine learning rate scheduler with warmup ratio 0.1, bf16 precision, and 3 training epochs. The validation split is 10%.
Second, we apply KTO 23 for preference-basee refinement using 2k design results with 1:1 positive-to-negative ratio, labeled based on task success. This stage uses a cutoff length of 4096, batch size with gradient accumulation steps of 8, learning rate 10-4, KL. penalty 3 0.1, bf16 precision, cosine scheduler, and 3 epochs. Validation performed every 500 steps. Each trajectory includes task description, the planned subgraphs, intermediate operator outputs, and the final answer.
D.3 Inference and Evaluation
At inference time, both the designer and executor are run with temperature 0.01 to ensure deterministic outputs. All methods use Phi-4 ensure fair comparison.
D.4 Cost Analysis
We report the cost of DyFlow in both training and inference, and compare with baseline systems using proprietary or open-weight models. As shown in Table 9 DyPlanner achieves the lowest inference cost across all domains while maintaining comparable or superior performance to larger proprietary designers such as GPT-4.1 and Claude-3.7. Despite being based on the compact Phi-4 model, DyPlanner enables DyFlow to match or outperform these stronger backbones in structured reasoning tasks. This confirms the effectiveness of our training pipeline, which distills high-quality planning behavior into a lightweight designer with minimal runtime cost.
We further analyze the full pipeline cost in Table 8 including both designer and executor token usage during training and inference on the MATH benchmark. Although DyFlow incurs additional training cost due to initial distillation from 1 it achieves the highest performance among all methods. During inference, DyFlow's 's total token cost moderately higher than AFlow and MaAS (approximately 1.4x to 3x), owing to its two-stage designer- executor structure. However, this cost remains substantially lower than prompt-based methods such as M. and Self-Refine, which lack structural planning. These results suggest that DyFlow offers favorable trade-off: higher
23

---

HumanEval
SocialMaze
PubMedQA
0.99
0.33
0.82
CdT
0.95
0.23
0.77
Average
0.91
0.14
0.72
0.87
0.05
0.67
Live
MATH
Average Score
0.76
0.70
Figure 7:
Per-benchmark Pass@k comparisons between DyFlow and CoT across five reasoning domains. DyFlow consistently achieves better accuracy under k values each task.
Table 8: Cost and performance comparison on the MATH dataset. DyFlow is trained only on MATH, PubMedQA, and LiveBench; Dyflow training cost is computed using only the MATH portion. Bold marks the best (lowest for cost/tokens, highest for accuracy).
Training
Inference
Method
Acc. (%)
Prompt
Comp.
Cost ($)
Prompt
Comp.
Cost ($)
LLM- Debate
1, 1,449,574
4,859,777
0.78
72.40
Self Relf-Refine
2,498,569
1,768,407
0.42
70.40
AFlow
13,773,792
13,240,624
2.82
1,208.683
895,017
74.00
MaAS
1,445,257
1,011,317
0.24
528,145
419,009
0.10
73.60
DyFlow (D.)
788,910
297,669
3,96
773,625
225,737
0.09
76.40
DyFlow (E.)
617,560
452,044
0.11
1,288,918
881,452
0.21
reasoning accuracy and generalization, with only modest overhead compared to other workflow-basd systems.
D.5 Cross-Executor Performance Details
We provide detailed performance comparisons of CoT and DyFlow across three executor models and five reasoning tasks in Table 10 DyFlow consistently improves performance over CoT under all configurations, demonstrating its robustness to executor variation. The gains are particularly notable for more lightweight models such as Phi-4 and GPT-4o-mini, where CoT struggles with reasoning consistency. In contrast, DyFlow's 's explicit planning compensates for executor limitations, leading to substantial improvements domains such as SocialMaze and MATH.
E
Limitations
Although DyFlow demonstrates strong generalization and reasoning stability across a variety of tasks, its current design has a notable limitation: the lack of integration with external tools and APIs. Specifically, DyFlow's operator set is primarily built for symbolic reasoning (e.g.. mathematical derivation, code execution) and textual reasoning (e.g., question answering). and does not yet support operations such as search engine access, database queries, or environment interaction. This limitation can lead to performance bottlenecks in tasks that require complex tool-assisted reasoning.

---

Table 9; Input tokens, output tokens, and computational costs of DyFlow with different designer models across five reasoning domains.
Benchmark
Designer
Input Tokens
Output Tokens
Cost (USD)
GPT-4.1
517575
211600
2.73
HumanEval
Claude-3.7-Sonnct
511347
205813
4.62
DyPlanner
505603
199355
0.06
GPT-4.1
815952
275565
3.84
LiveBench
Claude-3.7-Somnet
803211
271937
6.49
DyPlanner
791525
300402
0.10
GPT-4.1
788910
297669
3.96
MATH
Claude-3.7-Sonnc
781589
253471
6.15
DyPlanner
773625
225737
0.09
GPT-4.1
911364
302684
4.24
PubMedQA
Clande-3.7-Somnct
887653
289117
7.00
DyPlanner
588259
213749
0.07
GPT-4.1
1499141
436371
6.49
SocialMaze
Claude-3.7-Sonect
1387923
412689
10.35
DyPlanner
905088
300554
0.11
Total
GPT-4.1
4532942
1523889
21.26
Claude-3.7-Soneet
4371723
1433027
34.61
DyPlanner
3564100
1239797
0.42
Table 10: Detailed scores of CoT and DyFlow across three executor models and five reasoning tasks. Best results in each column are highlighted in bold.
Model
SocialMaze
PubMedQA
MATH
LiveBench
HumanEval
GPT-4o-mini (CoT)
3.05
69.72
64.80
32.67
87.20
GPT-4o-mini (DyFlow)
3.82
70.52
65.20
32.67
91.46
Phi-4 (CoT)
6.11
67.73
71.08
39.33
87,80
Phi-4 (DyFlow)
17.18
72.91
76.40
48.67
92.07
GPP-441-mim (CoT)
20.99
75.30
89.20
66.00
94.51
GPT-4. 1-mini (DyFlow)
42.75
77.29
92.80
71.33
96.95
It is worth noting, however, that in most of the tasks we evaluate, performance bottlenecks arise mainly from subgoal planning or logical reasoning errors rather than from missing external knowledge or tool usage, which is consistent with observations in prior research (38). As such, within the scope of our current evaluation, DyFlow's structured planning and feedback mechanisms already lead to significant performance gains, and the lack of tool integration has only limited impact.
Nevertheless, tasks continue to expand into more complex domains-sure as web-based question answering, embodied interaction, and multimodal reasoning- demand for external tool use is expected to increase. Future work may explore abstracting tool operations as special operator types and extending the executor interface, thereby enhancing DyFlow's generality and applicability in real-world, complex environments.
F
Case Study
25

---

Case Study (MATH)
Problem Description
Task: Given AB 10, AC where b > 10, and sin B B. compute the positive difference between the two possible values of BC.
CoT Answer by Phi-4
Step 1: Recognize that sin B = cos B = +
Step 2: Proceed with cos B (acute angle).
Step 3: Apply Law of Cosines to compute BC1 and output result.
Critical Flaw: The solution ignores the second case (cos B } which leads to incomplete answer.
Final Answer: 6
Incorrect
DyFlow Answer by Phi-4
Stage 1: Planning and Decomposition
Operator: DECOMPOSE_ PROBLLEM
Output: Identifies cos B F two geometric branches
Stage 2: Partial Answer Generation Initial Review
Operator: GENERATE_ANSHAN ANSWER Computes BC₁ for cos B
Operator: GENERATE ANSWER Computes BC₂ for B
Operator: SEVIEW_SOLUTION
Aggregates both results, checks completeness
Stage 3: Refinement and Re-evaluation
Operator: REFINEAANSWER Corrects inconsistency or adds missing branches
Operator: REVIEW_SOLUTH
Validates the refined answer
Stage 4: Finalization
Operator: SOLUTIO,,,L TERMINATE
Final Answer: 16
Correct
26

---

Case Study (Livebench)
Problem Description
Task: How many ordered pairs of positive integers (m,n) satisfy ged(m, n) and lcm[m, n| 108?
Ground Truth: 4
CoT Answer by Phi-4
Steps:
Use identity mn ged(m,, n) Iem (m, n| mn 216.
Let 2a, 26 with ged b) = 1 - ab 54.
Only considers (a, b) (1, 54), (54, 1), which gives (m, m)) = (2, 108), (108 2).
Flaw: Misses other coprime factorizations of 54, such as (2, 27) and (27, 2). leading to incomplete counting.
Final Answer: 2
Incorrect
DyFlow Answer by Phi-4
Stage 1: Decomposition and Initial Attempt DECOMPOSE_ DECOMPOSE_PROOLEEEK,
REVIEW_SOLUTION Uses mn 2a, 2b with (a, b) and ab = 54, and systematically identifies all valid
PROBLEM, GENERATE, ANSWER, REVIEW SOLUTION
(a, b) pairs by distributing the prime powers 2 and 3 disjointly between and Valid (a, 6) pairs: (1, 54), (2, 27), (27,2) 2), (54,
Corresponding (m, r2): (2, 108), (4, 54), (54, 4), (108, 2)
Stage 2: Finalization
ORGANIZE, SOLUTION, DRGANIZE_SOLLTTION, TERMINATE
Verifies all pairs meet both ged 2 and lem 108.
Final Answer: 4
Correct
27

---

Case Study (Logic Puzzle)
Problem Description
Task:
In this question, assume each person either always tells the truth or always lies. [Details of people, locations, and statements are given]. Does the person at the farm tell the truth? Does the person at the restaurant tell the truth? Does the person at the observatory tell the truth? Output answer as a list of three words: yes or no.
Ground Truth: yes, yes, no
CoT Answer by Phi-4
Steps:
Identifies known truth/lie statuses (Jake at airport, Jaxon at amusement park, Devika at observatory).
Lists statements made by target individuals (Farm, Restaurant, Observatory).
Correctly deduces Devika (Observatory) lies.
Correctly deduces Luna (Restaurant) tells the truth because her statement about Devika is true.
Analyzes Max (Farm): Notes Elowen and Liam say Max lies, but fails to fully leverage the crucial deduction that Luna (Restaurant) tells the truth.
Instead of using Max's statement "The person the restaurant tells the truth" (which is true, as Luna tells the truth) to prove Max is a truth-teller, it focuses on other statements and concludes Max is "likely lying".
Flaw: Missed key logical step. It correctly deduced Luna the Restaurant is truth-teller. Max at the Farm states that the person the Restaurant tells the truth. Since Max statement about Luna is true, Max himself must be truth-teller. The CoT failed to make this final deduction about Max, leading to an incorrect conclusion for the Farm. Final Answer: no, yes,
Incorrect
DyFlow Answer by Phi-4
Stage 1: Decomposition and Planning DECOMPOSE, PROBLEM, CROOMPOSE_PROBLE,,, GENERATE, PLAN
Breaks down the complex puzzle into explicit constraints, person-location mapping, and generates a systematic plan for logical deduction. This ensures all pieces of information are organized for analysis.
Stage 2: Solution Generation and Review GENERATE_ ANSWER, REVIEW DIVIIE_SSOUUTOO
Generates step-by-step solution using the structured information. Crucially, during the deduction phase (as seen in the final organized solution), it correctly identifies:
Devika (Observatory) lies (known).
Luna (Restaurant) tells the truth because she correctly states Devika lies.
Max (Farm) tells the truth because he states the person the Restaurant (Luna) tells the truth, and Luna has been correctly deduced to be truth-teller. This the critical deduction missed by COT.
The REVIEW_SOLUTIEE step confirms the logical consistency and completeness of the de- ductions against all constraints.
Stage 3: Finalization
ORGANIZE, ORGANIZE_SOLUTION TERMINATE Organizes the verified, correct solution and presents the final answer in the required format.
Final Answer: yes, yes, no
Correct
28

---

Case Study (LiveBench)
Problem Description
Suppose have regular heptagon, and can make four straight cuts. Each cut cannot pass through any of the vertices of the heptagon. Also, exactly three of the cuts must intersect at single point within the heptagon. What the maximum number of resulting pieces? Output answer single integer. Ground Truth: 10
Task:
CoT Answer by Phi-4
Steps:
Identifies constraints (4 cuts, no vertices, concurrent).
Mentions general formula for maximum regions by lines in plane: R(n)
a(n-1)
2
Notes three concurrent lines form regions instead of (correct for lines plane).
"Initial regions formed by three intersecting lines: 6". This is likely referring the plane, not pieces in the heptagon (3 concurrent divide convex shape into 5 pieces).
Attempts calculation:
States "The maximum number of regions formed by four lines, with three intersect- ing point, 11". This is incorrect. The maximum regions in the plane for 4 lines with 3 concurrent is 10 (R(4) - (3 () 2)/2 11 - = 10). More importantly, it misapplies plane region logic to pieces within a bounded shape under concurrency. A line crossing & existing segments adds k: + pieces.
Flaw: Miscalculated the maximum number of regions the plane for 4 lines with concurrent (states 11, should be 10). More fundamentally, failed to correctly reason about how cuts add pieces within the bounded heptagon, especially under the concurrency constraint. It seems confuse total regions in the plane with pieces within the shape, and incorrectly handles the impact of the fourth cut. Final Answer: 11
Incorrect
DyFlow Answer by Phi-4
Stage 1: Decomposition, Solution Generation, and Review DECOMPOSE, PROBLEM, DyFlow begins by decomposing the task into fundamental constraints: cuts, 3 of which must intersect at single point, and none of which may pass through vertices. The planner generates solution by correctly reasoning that three concurrent cuts form regions inside the heptagon, and the fourth cut, intersecting all three, adds 4 new regions (1 for each segment crossed). This leads to total of 6
CCCCMMESE_PROBBLMM,, CENERATE_ ANSWER, REVIEW_SOLUTIN
10 pieces.
The WEVIEW_SOLUTIN operator verifies this reasoning, ensuring that the concurrency con- straint and the incremental piece count are correctly applied. It confirms that no logical or constraint violations are present and that the plan internally consistent.
Stage 2: Finalization
ORGANIZE_ TRGANIZE_SOLUTTONN TERMINATE The final verified solution is organized for presentation. The planner concludes the task by outputting the answer the required format.
Final Answer: 10
Correct
29

---

Case Study (SocialMaze)
Problem Description
Task:
Deduce the criminal and Player I's role in a 6-player social deduction game (3 Investi- gators, Criminal, Rumormonger, Lunatic) after rounds of statements, Player told they are the Criminal. Investigators always tell the truth about the Criminal. Rumormongers believe they are Investigators but may be incorrect. Lunatics believe they are Criminals and may be truthful false. Output format: Final Criminal Is Player [X]. My Role Is [Y or Unknown]. (Only provide part of the problem description due limited space.) Ground Truth: Final Criminal Is Player 4. My Role Is Lunatic.
CoT Answer by Phi-4
Steps:
Summarizes rules and statements per round.
Notes P6 accuses PI in R1, P5 denies P1 in R1,
Notes P2,3,4,6 deny P1 in R2/R3 (mostly).
Notes P2,3 accuse P4 in R3.
Flawed Deduction on Player 1: Concludes Player is "likely the Criminal" because they were told they are the Criminal and their statements are inconsistent. This ignores the rule that Lunatics are told they are Criminals and also make inconsistent statements, and more importantly, contradicts the evidence from multiple players denying PI is the criminal.
Flawed Deduction on Player 6: States P6 is "likely an Investigator, as they consis- tently accuse Player 1". This is false; P6 accuses Pl (R1), denies Pl (R2), accuses P3 (R3). P6 is inconsistent.
Attempts role assignment based on these flawed deductions, leading to P1 as Crimi- nal and 6 Investigators (which contradicts P2,3,4,6 denying P1 in R2/R3). Incorrect
Final Judgment: Final Criminal: 1, My role: Criminal
DyFlow Answer by Phi-4
Stage 1: Initial Deduction and Review
GENERATE, AORSER Analyzes the statements and role rules to produce an initial answer: Player 4 is the Criminal; Player I's role remains uncertain. Checks the consistency the deduction. Confirms that Player 4 is
REVIEW REVIEW_SOLUTION SOLUTION strong candidate for Criminal but flags the ambiguity in Player I's role as minor issue.
Stage 2: Refinement and Re-Review
Reevaluates Player I's status using rule-based reasoning: being told they are the Criminal while evidence contradicts that claim aligns with the definition Lunatic. NEVIEW_SOLUTHH
Validates the refined answer. Confirms that all constraints are satisfied and the role assignment is consistent and complete.
Stage 3: Finalization BRGANIZE_SOLUTTIN TERMINATE -Formass and outputs the final answer.
Key Deductions:
1. P2 and P3 consistently accuse Player 4. Since Investigators always speak truthfully about the Criminal, this supports P4 the true Criminal.
2. Player Under the game rules, this behavior corresponds to the Lunatic role.
told they are the Criminal, but all external evidence contradiets this.
Final Judgment: Final Criminal Is Player 4. My Role Is Lunatic.
Correct
30

---

Case Study (Code Generation Simple Parsing)
Problem Description
Task:
Write a Python function fruit_distribee wwdddiiiiuuiionee (s, n) that takes a string ("X apples and Y oranges") and total fruit count n, and returns the number of mangoes (n Y). Examples provided.
Ground Truth: Code that correctly parses the string s to extract X and Y, and returns Y.
CoT Answer (Original Code) by Phi-4
The generated code extracts the number of apples correctly using parts [0], but incorrectly attempts to extract oranges using parts [4], which results in a ValueError when parsing the word "oranges". Result:
Summary:
Code fails at runtime due to incorrect parsing.
Incorrect
DyFlow Answer by Phi-4
Stage 1: Initial Generation Review
GENERATE, CODE produces first draft, likely with the same parsing flaw. REVIEW_SOLUUE SOLUTION identifies issue via failed test cases. (Status: Minor Issues)
Stage 2: Test Construction & Refinement
DEFAULT Dynamically constructs targeted test cases to diagnose parsing behavior and edge failures.
REFINE_CODE CODE Uses the generated tests to revise the parsing logic. Attempts an improved implementation.
Reviews the revised code. Some issues remain unresolved in edge cases. (Status: Minor Issues)
Stage 3: Further Refinement & Final Review REFINE_CODE Performs another round of refinement. This time adopts robust parsing (e.g.. regex).
NEVIEW_SOLUTION- Validates that all test cases pass. (Status: Accept)
Stage 4: Finalization
ORGANIZE_ SOLUTIONOOOOONNNNOOOO Formats and documents the final code. TERMINATE Outputs the final result and concludes the workflow.
Result: Code passes all tests and produces correct output.
Correct
31

---

G
Prompt Template
GENERATE_COME CODE
You are an expert solving coding problems. Generate Python code based on the following context and guidance.
Context: {context]
Guidance: (guidance)
Your code must:
1. Define function named solve that calculates and returns the final result.
Clearly comment each computational step.
3. Obtain necessary inputs from within the function global variables (no function parameters).
Output Format:
"*. python
# Your generated code here (use the main function name 'solve')
<<<
GENERATE ANSWER
ANSSER
You expert in solving reasoning problems. Think step by step to solve the problem using the context and guidance.
Context: [context]
Guidance: (guidance)
Output Format:
Reasoning: <You should think step by step to solve the problem.>
Answer:
REVIEW SOLUTION
You are a careful reviewer trained to detect logical and mathematical errors. Your job is to critically evaluate the solution for correctness, soundness, and completeness.
Context: [context]
Guidance: (guidance)
Instructions:
-Tr to find mistakes at every step the given answer.
Bring the answer back to the original question and check if there is anything that does not meet the requirements.
Output Format:
Review Details: <step-by-step review>
Overall Verdict: <accept/minor, http://mmnor_sssuus/mmjjjooooooo jaapes//mmjjoissuuuseeeeeeeee
32

---

DECOMPOSE PROBLEM
You are an expert in decomposing problems. Break down the original problem into clearly defined, structured sub-tasks.
Context: [context]
Guidance: (guidance)
Instructions:
Clearly outline each distinct sub-task.
Do not attempt to solve any sub-task.
Maintain logical completeness.
Decompose the problem into 2-4 steps at most.
Output:
<your_ doou_ddcomppeed cactommpoeed_pobblm->
HENERATE_PLAY
You are an expert in generating step-by-step executable plans. Generate step-by-step executable plan to approach the given problem.
Context:
[context]
Guidance: (guidance)
Instructions:
-Clerrly number each step.
Ensure each step is actionable and logically sequenced.
Do solve the problem here, only provide the plan.
Give 2-4 steps at most.
Output Format:
Solution Plan:
<step_id> sep__dd>:<> <description>
<step_id>: <description>
REFINE CODE
You are an expert in refining Python code. Refine the existing Python code based context and guidance.
Context: |context]
Guidance: (guidance)
Instructions:
Coorrctt errors or inefficiencies identified.
Clearly comment important logic corrections.
Maintain the main function name as solve.
Output Format:
*** pyyhhnn
# Your refined code here (use the main function name 'solve")
'<<
33

---

SEFINE_ANSWER
You are an expert in refining answers. Refine the existing answer based on context and guidance.
Context: [context]
Guidance: (guidance)
Output Format:
Answer: <your refined answer>
ORGANIZE SOLUTION
You are expert in organizing solutions. Clearly organize the final solution for presentation based on the provided context and guidance.
Context: {context]
Guidance: (guidance)
Instructions:
-Clarlly present final reasoning steps and results.
Ensure alignment with the problem's 's required formatting.
Omit irrelevant or incorrect previous attempts.
Output:
<your_ cectuu_orgniied_sllel solution
ENSEMBLE
You are an expert in generating multiple valid and diverse solutions using distinct logical approaches.
Context: (context]
Guidance: (guidance)
Instructions:
-Each solution must independently satisfy all constraints. Cllarly separate each distinct reasoning path and solution.
Output:
<your_ente ceteembleeoutpur
DEFAULT
You are an expert in executing actions strictly according to the given context and guidance.
Context: [context]
Guidance: (guidance)
Instructions:
Follow every detail of the instructions carefully. Ensure output exactly matches the requested format.
Output:
syour_output>
34


Reviews:
[{"review_id": "gk9qumyiiq", "reviewer": "Reviewer_E5YQ", "summary": "The paper introduces DyFlow, a two-level framework that allows large-language-model (LLM) agents to build and revise reasoning workflows on the fly. A high-level Designer turns the current task state into a small “stage sub-graph” that specifies (i) a sub-goal and (ii) a sequence of operator instances (e.g. DECOMPOSE_PROBLEM, GENERATE_ANSWER, REVIEW_SOLUTION, TERMINATE). A low-level Executor (any LLM) runs those operators, pushing intermediate outputs into a shared memory. After each stage, the updated state—including tool outputs, error flags and prior plans—is summarised and fed back to the Designer, which may keep, refine, back-track, or abandon the plan.", "questions": "1. How does performance degrade when the operator set is reduced or automatically expanded?\n2. What fraction of tasks require a second or third re-planning step, and how often does re-planning fix an error vs cause thrashing?\n3. Can the Designer trained under DyFlow self-play transfer to an executor of a different architecture (e.g., Mistral-7B) with zero additional tuning?\n4. What are the worst observed failures (e.g., infinite loops, irrelevant operator sequences) and how are they detected or mitigated?\n5. Could DyFlow be integrated with retrieval-augmented tool calls by treating search as an operator, and if so, how would the preference signal distinguish relevant from spurious retrievals?", "limitations": "The authors note the absence of external tools; I would add (i) potential brittleness to summariser quality, if fsummary misses salient errors, the Designer cannot fix them, and (ii) difficulty in scaling preference labels beyond binary success/failure, which may under-train fine-grained planning choices.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\n1. The Designer is queried every stage, letting DyFlow abandon or rewrite entire sub-goal trees when intermediate checks fail—something one-shot planners and static graphs cannot do.\n2. Training a 14 B open-weight Phi-4 with SFT + KTO yields performance on par with 70–>100 B proprietary models, at ≤ 2 % of their dollar cost (Table 9).\n3. Five domains, including two that are completely unseen during training, demonstrate cross-task generalisation. DyFlow is zero-shot on SocialMaze yet triples CoT accuracy (17 % vs 6 %).\n4. Eleven operator templates (generate, decompose, review, refine, code, ensemble, terminate, …) achieve good coverage without exploding search space; Figure 6 shows domain-specific usage patterns.\n5. The authors avoid unstable RL and noisy per-step judges; instead they use trajectory-level success/failure, which yields a tractable, low-variance preference loss.\n6. Removing dynamic planning, dynamic operators, SFT or KTO each harms performance, isolating where the gains come from (Table 4).\n7. Token-level budget for Designer vs Executor and for training vs inference lets practitioners reproduce or adapt the system.\n\nWeaknesses\n1. All tasks are single-modal textual problems requiring symbolic or numerical reasoning; no experiments involve web search, database queries, images, or embodied actions—yet tool-use is a selling point of agentic frameworks.\n2. The preference phase is fully offline. The system does not adjust the Designer on-the-fly when facing new domains (e.g. SocialMaze), missing a chance to demonstrate continual improvement.\n3. The paper proves DyFlow is “never worse” than a static policy by inclusion, but supplies no bound on performance loss due to planning error, nor on sample complexity of the KTO phase.\n4. Safety claims (e.g. all generated code runs, MI > 40) are anecdotal; there is no quantitative report of crashes, hallucinated file paths, or malicious prompt injections.\n5. Adding new capabilities still requires designing templates and writing prompt instructions; the paper’s “dynamic operator” claim is limited to parameter instantiation, not operator induction.\n6. Critical settings (planner temperature 0.01, step cap T_max) are fixed ad hoc. Sensitivity plots would clarify robustness.\n\nFor more detail:\n1. Incorporating environments such as HotpotQA (search + multi-hop) or TabMWP (table look-ups) would test DyFlow’s operator abstraction and executor interface.\n2. A small-variance, in-run critic (even heuristic) could supply incremental rewards and perhaps close the remaining gap to SOTA GPT-4-based solvers.\n3. The memory dictionary M is key to DyFlow; exploring keyed vs vector memory, or pruning strategies, could reveal scalability ceilings.\n4. Dynamic, self-revising agents might mask provenance or increase automation risks; the paper should add a short ethics or safety outlook.", "was_revised": true, "final_justification": "The authors provided comprehensive responses that addressed most of my technical concerns:\n\nScope Clarification: The intentional focus on symbolic/numerical reasoning rather than tool-augmented tasks was well-justified, demonstrating that dynamic re-planning alone yields significant benefits.\nSafety and Code Generation: Quantitative evidence showed 99.4% execution success rate (163/164 HumanEval tasks) with proper sandboxing, addressing my concerns about code safety and reliability.\nOperator Set Analysis: The ablation study comparing full vs. core operators (5-template subset) effectively demonstrated the importance of operator diversity, with consistent 3-5% performance drops across domains when higher-level operators were removed.\nRe-planning Effectiveness: Analysis of 100 SocialMaze trajectories showed that re-planning successfully corrects errors (9 cases) with minimal thrashing (2 cases), validating the feedback mechanism.\nCross-Architecture Transfer: Confirmation that the Designer transfers to different executors (GPT-4o-mini, etc.) without additional tuning demonstrates the framework's modularity and practical value.\n\nRemaining Limitations:\n\nDomain Scope: Evaluation remains limited to single-modal textual reasoning tasks, lacking validation on multimodal or tool-augmented scenarios that are central to modern agentic systems.\nTheoretical Foundations: While practical convergence was demonstrated, formal guarantees about planning error bounds and sample complexity remain absent.\nHyperparameter Sensitivity: Critical settings (temperature 0.01, step cap) were set ad hoc without sensitivity analysis, limiting understanding of robustness.\n\nWeight Assignment:\nI assign high weight to the technical innovation in dynamic workflow generation and the strong empirical results across five diverse domains, including impressive zero-shot generalization (SocialMaze: 17% vs 6% CoT baseline). The cost efficiency (≤2% of proprietary model costs while achieving comparable performance) represents significant practical value.\nHowever, I assign moderate weight to the limited scope concerns, as the restriction to symbolic reasoning limits immediate applicability to broader agentic AI scenarios requiring tool integration.", "rebuttal": "We sincerely thank the reviewer for the detailed and thoughtful comments. We have carefully revised the paper based on your suggestions, and we address each point below.\n\n---\n\n**$Q_1:$ All tasks are single-modal textual problems requiring symbolic or numerical reasoning**\n\n$A_1:$​ We agree with the reviewer that DyFlow, in its current form, operates over a symbolic and code-centric action space, and does not yet interface with tools such as search engines, databases, or APIs. This was an intentional scope choice: *our focus in this work was to test whether dynamic re-planning mechanisms alone, in the absence of external resources, could bring significant gains in reasoning performance*. As shown in our experiments (e.g., Table 1), this setup already reveals strong benefits over static or prompt-based workflows.\n\nThat said, we recognize that enabling richer tool integration and expanding beyond single-modality is essential for building more capable agentic systems. Incorporating such functionalities would involve not only extending the operator template space, but also developing mechanisms for handling noisy or partial tool outputs, and possibly adopting finer-grained credit assignment during training. We will include this point clearly in the revised Limitations section and consider it a core direction for future research.\n\n**$Q_2:$ The preference phase is fully offline.**\n\n$A_2:$ We thank the reviewer for this insightful observation. Our use of offline self-play preference optimization was intentional, as noted in Lines 202–211. We prioritized stability and reproducibility: online RL in this setting often suffers from sparse rewards and unstable convergence, which can obscure the true effect of dynamic planning.\n\nDespite being trained offline, the Designer shows strong zero-shot generalization. As shown in Table 1 and Table 3, it significantly improves performance on unseen domains like **SocialMaze** and **LiveBench**, demonstrating that DyFlow generalizes well without online adaptation.\n\nThat said, we agree that continual improvement via online preference refinement or incremental self-play is a valuable future direction. We will note this explicitly in the revised *Limitations* section.\n\n**$Q_3:$ The paper proves DyFlow is “never worse” than a static policy by inclusion, but supplies no bound on performance loss due to planning error, nor on sample complexity of the KTO phase.**\n\n$A_3:$ We appreciate the reviewer’s suggestion. Our main focus is on demonstrating the practical effectiveness of dynamic workflow planning, rather than providing a tight theoretical bound. Nevertheless, as shown in Theorem 2 (Appendix B), DyFlow’s policy is guaranteed to be no worse than a static policy. A tighter, high-probability bound could indeed be derived by relating the per-step error $\\epsilon_k$ to the probability of selecting a suboptimal subgraph (e.g., via Hoeffding-type concentration inequalities), but we leave such theoretical refinements to future work, as our contributions are primarily empirical.\n\n**$Q_4:$ Safety claims are anecdotal**\n\n$A_4:$ We thank the reviewer for highlighting this important point. All generated code was run in a controlled sandbox to ensure safety: (i) execution occurred in an isolated namespace, (ii) high-risk libraries (e.g., `os`, `sys`, `subprocess`) were blocked, and (iii) only a predefined `solve()` function was executed, with outputs and errors captured.\n\nOut of 164 HumanEval tasks, **163 ran successfully (99.4%)**. The one failure was due to infinite recursion, not unsafe or malicious behavior. We observed no hallucinated paths, unauthorized system calls, or prompt-injection attacks.\n\nWe will clarify these quantitative results in the revision and note that broader stress testing (e.g., adversarial inputs, resource monitoring) is a valuable future direction.\n\n**$Q_5:$ Adding new capabilities still requires designing templates and writing prompt instructions**\n\n$A_5:$ We thank the reviewer for this constructive comment. We use dynamic operator to refer to the system's ability to adaptively compose and parameterize existing templates at runtime. This dynamic control over the workflow, as validated by the ablation in Table 4, is a core contribution. We agree that automatic operator induction is an important future direction and will clarify this in the Limitations section.\n\n**$Q_6:$ Critical settings (planner temperature 0.01, step cap $T_{\\max}$) are fixed ad hoc. Sensitivity plots would clarify robustness**\n\n$A_6:$ We thank the reviewer for raising this point. The planner temperature was set to **0.01**. This choice follows common practice in reasoning agents and was adopted mainly to ensure deterministic decoding across different APIs. As some implementations internally treat 0 as a special case (allowing minimal stochasticity or fallback sampling in rare scenarios), using 0.01 enforces a strictly low-temperature regime while avoiding such implementation-dependent behavior.\n\nFor the step cap $T_{\\max}$, we chose **10** as a conservative upper bound. Among 164 HumanEval tasks, none required more than 7 stages (6 tasks used 6 steps, 2 used 7). Thus, $T_{\\max} = 10$ safely covers all observed cases without incurring unnecessary computation.\n\n**$Q_7:$ How does performance degrade when the operator set is reduced or automatically expanded?**\n\n$A_7:$ We thank the reviewer for this valuable suggestion. To evaluate the contribution of each operator family, we ran an ablation using a simplified DyFlow with only five core templates (`REVIEW_SOLUTION`, `GENERATE_ANSWER`, `DECOMPOSE_PROBLEM`, `ORGANIZE_SOLUTION`, `TERMINATE`). We sampled 100 examples per benchmark and used the same Phi-4 executor.\n\n|Task|Full|Core|Δ|\n|----|----|----|--|\n|SocialMaze|17%|12%|−5%|\n|PubMedQA|71%|70%|−1%|\n|MATH|75%|71%|−4%|\n|LiveBench|48%|44%|−4%|\n|HumanEval|93%|90%|−3%|\n\nRemoving higher-level operators consistently degrades performance, especially in tasks requiring flexible planning (e.g., **SocialMaze**). Automatic operator induction is beyond the scope of this work, and we will mention it as a key future direction in the revised *Limitations* section.\n\n**$Q_8:$ What fraction of tasks require a second or third re-planning step, and how often does re-planning fix an error vs cause thrashing?**\n\n$A_8:$ We thank the reviewer for this insightful question. In DyFlow, re-planning is triggered when the `REVIEW_SOLUTION` operator flags an intermediate error. To assess its impact, we manually reviewed 100 sampled trajectories on the most challenging benchmark, **SocialMaze**:\n\n- **Frequency:** 67 cases had one review, 25 had two, and 8 had three.\n\n- **Effectiveness:** 9 cases corrected an initial error; 2 introduced a new error after re-planning.\n\nGiven SocialMaze’s difficulty (17% accuracy) and the limitations of the base Phi‑4 model, these results suggest that DyFlow’s re-planning mechanism is effective and introduces minimal thrashing. We will clarify this analysis in the final version.\n\n**$Q_9:$ Can the Designer trained under DyFlow self-play transfer to an executor of a different architecture with zero additional tuning?**\n\n$A_9:$ We thank the reviewer for this question. Yes, we have conducted such experiments, as shown in **Figure 4** and detailed in **Appendix D.5 (Table 10)**. The Designer trained under DyFlow self-play transfers to executors of different architectures (e.g., GPT-4.1-mini) with zero additional tuning and consistently improves performance over CoT baselines.\n\nThis transferability is a direct consequence of DyFlow’s **decoupled architecture**: the Designer is responsible only for planning and data-flow orchestration, not for solving subproblems itself. Thus, it can treat any LLM as a black-box Executor, making zero-shot adaptation to new executors straightforward.\n\n**$Q_{10}:$ What are the worst observed failures and how are they detected or mitigated?**\n\n$A_{10}:$ We thank the reviewer for raising this important point. The worst failure we observed occurs when the Executor-generated code enters an **infinite or excessively long loop**. This was extremely rare (**1 out of 164 HumanEval tasks**) and was safely handled by our sandbox, which terminates execution upon timeouts.\n\nMoreover, we strictly prohibit high-risk libraries (`os`, `sys`, `subprocess`, etc.) and run all generated code in an isolated execution environment, ensuring that no OS-level crashes or security breaches can occur.\n\n**$Q_{11}:$ Could DyFlow be integrated with retrieval-augmented tool calls by treating search as an operator, and if so, how would the preference signal distinguish relevant from spurious retrievals?**\n\n$A_{11}:$ We thank the reviewer for this insightful comment. In our current setup, a **trajectory-level success/failure signal** is sufficient, as operators perform mostly deterministic reasoning and final outputs reliably reflect plan quality. This keeps preference optimization stable and low-variance.\n\nHowever, retrieval-augmented reasoning requires finer control. Trajectory-level feedback alone cannot distinguish useful from spurious retrievals. To support such cases, DyFlow would need **step-level quality signals** to reward relevant evidence and penalize noise—an important direction for future work.\n\n**$Q_{12}:$ Potential brittleness to summariser quality**\n\n$A_{12}:$ We appreciate the reviewer’s point. DyFlow’s summariser serves a narrowly scoped role: it condenses intermediate outputs into a concise state for the Designer, without performing complex reasoning. This summarization task is reliably handled by modern LLMs, and we observed very few cases of misleading or incomplete summaries. Even when minor omissions occur, DyFlow’s **multi-stage planning** allows later steps to detect inconsistencies and self-correct. In practice, such issues rarely impact the final outcome.\n\n---\n\nThank you again for your valuable time and suggestions and we would greatly appreciate your kind support during the discussion phase."}, {"review_id": "UVj6lMnLnw", "reviewer": "Reviewer_y5j8", "summary": "This paper introduces a designer-executor framework for agentic workflow that performs dynamic reorganization of task subgoals to overcome the issues with static or rule-based based agentic workflows. The designer agent observes the current task state and plans the next step of the reasoning process. This plan occurs in the form of subgraph of ops. The executor model then executes the operations in this subgraph. The proposed designer, the main contribution of this work, is trained using a combination of policy distillation and self-play to significantly improve its design capabilities.  The feedback framework allows the designer to rethink the workflow steps in a task to avoid terminating errors as an output. They show that DyFlow is able to perform much better than prompt-based methods and automated agent frameworks for different reasoning domains, one-shot generalization across other held-out domains, better evaluation on coding benchmarks, robust across different designer models. They also highlight the importance of the dynamic planning agent using the ablation, where they remove dynamic planning and only generate a static workflow.", "questions": "My questions are bundled with the limitations stated above.", "limitations": "Please see weaknesses section", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 4, "significance": 4, "originality": 4, "strengths_and_weaknesses": "+ The idea of moving from one-shot workflow generation to feedback-driven subgoal re-planning paradigm is highly significant\n+ The authors provide rigorous benchmarking across multiple reasoning domains\n+ It appears that the learned agents achieve true generalization based on the cross task results in Table 3\n+ SFT + KTO seems to work very well on an open source model compared to propietary models\n+ The ablation clearly shows the importance of the planner as an important contribution of this work\n\n- How does the adaptive workflow affect latency or, equivalently, real time nature of the response or speed of task execution. Is there a trade-off study of speed of completion vs quality of task execution?\n- How vital is the diversity of the operator templates available for the work?", "was_revised": true, "final_justification": "I am maintaining my final score for the paper. I am satisfied with the existing rebuttal from the authors. The work, is a novel contribution in designer-executor framework for agentic workflow and having the interesting discussion especially from the other reviewer W8Cr, I am going to maintain my current rating", "rebuttal": "We sincerely thank the reviewer for the detailed and thoughtful comments. We have carefully revised the paper based on your suggestions, and we address each point below.\n\n---\n\n**$Q_1:$ How does the adaptive workflow affect latency or, equivalently, real time nature of the response or speed of task execution? Is there a trade-off study of speed of completion vs quality of task execution?**\n\n$A_1:$ We thank the reviewer for raising this important point. As detailed in Appendix D.4 and Table 8, we provide a full analysis of DyFlow’s pipeline cost, including token usage from both the Designer and Executor during inference on the MATH benchmark.\n\nWhile DyFlow introduces modest computational overhead due to its multi-stage planning structure, the total token cost remains within a reasonable range. As shown in Table 8, DyFlow consumes slightly more tokens than MaAS or AFlow (approximately **1.4×–3×**), but achieves a **2.0–2.8% improvement** in accuracy. This suggests that DyFlow’s adaptive workflow introduces a moderate but controlled cost, which is justified in settings where reasoning accuracy is prioritized.\n\nMoreover, DyFlow remains much more efficient than prompt-based agents like LLM-Debate and Self-Refine, which incur substantially higher inference costs without dynamic planning. Overall, DyFlow offers a balanced trade-off between efficiency and planning quality, particularly in tasks that benefit from structured reasoning.\n\n**$Q_2:$ How vital is the diversity of the operator templates available for the work?**\n\n$A_2:$ We appreciate the reviewer’s question. Empirically, we find that the diversity of operator templates plays a crucial role in DyFlow’s performance. While the core operators (e.g., `DECOMPOSE_PROBLEM`, `GENERATE_ANSWER`, `TERMINATE`) handle basic reasoning, many tasks benefit significantly from higher-level planning and refinement operations.\n\nTo verify this, we conducted an ablation study comparing the full DyFlow system against a reduced variant using only five core templates. The simplified version omits templates responsible for iterative optimization, plan construction, and ensemble voting. Evaluation on 100 random examples per task yields the following results:\n\n| Task       | Full | Core | Δ    |\n| ---------- | ---- | ---- | ---- |\n| SocialMaze | 17%  | 12%  | −5%  |\n| PubMedQA   | 71%  | 70%  | −1%  |\n| MATH       | 75%  | 71%  | −4%  |\n| LiveBench  | 48%  | 44%  | −4%  |\n| HumanEval  | 93%  | 90%  | −3%  |\n\nThese drops highlight that template diversity is not merely auxiliary—it **directly contributes** to DyFlow’s ability to correct mistakes, explore alternatives, and handle structurally diverse tasks. In particular, tasks like SocialMaze and LiveBench, which require multi-step re-evaluation and flexible planning, are disproportionately affected by the removal of these advanced operators.\n\nWhile this study focuses on hand-designed templates, we agree that learning or inducing new operator templates dynamically is an important direction. We will include this explicitly in the revised *Limitations* section as a target for future research.\n\n---\n\nThank you again for your valuable time and suggestions and we would greatly appreciate your kind support during the discussion phase."}, {"review_id": "DXeEejxUzu", "reviewer": "Reviewer_FEBY", "summary": "This paper presents a novel dynamic agentic workflow generation framework, named DyFlow, designed for reasoning tasks. It consists of two core components: a designer to decompose the task into sub-goals and refine the plan generation given the intermediate output and feedback; an executor to execute each operation initialized from the operator templates. The designer is trained using a two-phase learning strategy with knowledge distillation and self-play preference optimization. The proposed framework outperforms the existing baselines on different reasoning benchmark datasets.", "questions": "* Could the authors explain the motivation that only the designer is trained in the proposed framework? Why is the executor excluded from training? And have the authors considered an end-to-end training including both the designer and executor?\n* In Figure 2, could the authors annotate where the executor is in the diagram? The current diagram only includes a designer component.\n* In Algorithm 1, could the authors explain what the content is in the memory? What is a list of keys? And how are the inputs retrieved from the memory?", "limitations": "Yes.", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 3, "significance": 4, "originality": 3, "strengths_and_weaknesses": "**Strengths**\n* This paper proposes a novel framework built on a hierarchical designer-executor architecture that dynamically decomposes the task into sub-goals instead of relying on a static workflow.\n* The proposed framework DyFlow uses the feedback and outputs from the executor to revise the plan, retry the sub-goal to support fine-grained execution corrections.\n* The designer is trained using a novel two-phase learning strategy with knowledge distillation and self-play preference optimization without relying on human-annotated labels.\n* DyFlow achieves consistent and significant improvements over the existing baselines across multiple reasoning tasks.\n\n**Weakness**\n* The designer instantiates the operators from a finite set of operator templates to construct the workflow graph, which only consists of symbolic decomposition and code execution. The executor doesn't support tools or APIs for more complex reasoning tasks.\n* The designer constructs the sub-graph given the task and feedback; however, it is not guaranteed that the constructed sub-graph is valid and optimal for the task. For example, the designer might generate redundant and inefficient workflows.\n* The proposed framework needs to use another LLM to generate a condensed state summary to determine the subgoal and a stage subgraph. During the summarization, it is not guaranteed that no information will be lost.", "was_revised": true, "final_justification": "This paper introduces the designer-executor architecture to dynamically decompose the tasks into sub-tasks. Although the entire architecture is not new, it introduces a novel two-stage training strategy to train the designer and executor executes a set of high-level operators to execute the task. I believe this is an interesting work that could provide insights on the dynamic agentic workflow generation.", "rebuttal": "We sincerely thank the reviewer for the detailed and thoughtful comments. We have carefully revised the paper based on your suggestions, and we address each point below.\n\n---\n\n**$Q_1:$ The designer instantiates the operators from a finite set of operator templates to construct the workflow graph, which only consists of symbolic decomposition and code execution. The executor doesn't support tools or APIs for more complex reasoning tasks.**\n\n$A_1:$ We appreciate the reviewer for pointing this out. We agree with the reviewer that DyFlow, in its current form, operates over a **symbolic and code-centric action space**, and does not yet interface with tools such as search engines, databases, or APIs. This was an intentional scope choice: our focus in this work was to test whether dynamic re-planning mechanisms alone, in the absence of external resources, could bring significant gains in reasoning performance. As shown in our experiments (e.g., Table 1), this setup already reveals strong benefits over static or prompt-based workflows.\n\nThat said, we recognize that enabling **richer tool integration** and expanding beyond single-modality is essential for building more capable agentic systems. Incorporating such functionalities would involve not only extending the operator template space, but also developing mechanisms for handling noisy or partial tool outputs, and possibly adopting finer-grained credit assignment during training. We will include this point clearly in the revised *Limitations* section and consider it a core direction for future research.\n\n**$Q_2:$ The designer constructs the sub-graph given the task and feedback; however, it is not guaranteed that the constructed sub-graph is valid and optimal for the task. For example, the designer might generate redundant and inefficient workflows.**\n\n$A_2:$ We thank the reviewer for raising this insightful point. It is true that DyFlow does not guarantee the generated subgraphs are **globally optimal or minimal** in size. However, this is an intentional aspect of our learning-based design. Our goal is to train the Designer to produce **empirically effective subgraphs**—those that work well in practice, even if not theoretically minimal.\n\nTo this end, our two-stage training procedure plays a crucial role. The SFT phase provides strong initial patterns, while the KTO phase encourages the Designer to favor subgraphs that lead to success and penalizes those that result in failures or redundant reasoning. This allows the model to iteratively refine its planning behavior based on trajectory-level feedback.\n\nAlthough optimality is not explicitly enforced, the consistent improvements across tasks and benchmarks, as shown in Table 1 and Table 3, demonstrate that the Designer learns to generate workflows that are both effective and efficient for the reasoning problems at hand.\n\n**$Q_3:$ The proposed framework needs to use another LLM to generate a condensed state summary to determine the subgoal and a stage subgraph. During the summarization, it is not guaranteed that no information will be lost.**\n\n$A_3:$ We appreciate the reviewer for raising this point. In DyFlow, the summarizer serves a **well-scoped and lightweight** role: it condenses intermediate outputs and operator results into a structured state for the Designer to process. It does not perform complex reasoning or decision-making. This task is effectively a summarization problem, which current LLMs handle with high reliability.\n\nIn our experiments, we observed very few instances where the summarizer omitted critical information. Furthermore, DyFlow’s **multi-stage planning architecture** enables self-correction: even if a salient detail is missed in one stage, it can often be recovered or revised in subsequent ones. In practice, we found that summarization imperfections rarely impact the final outcome, thanks to this built-in robustness.\n\n**$Q_4:$ Could the authors explain the motivation that only the designer is trained in the proposed framework? Why is the executor excluded from training? And have the authors considered an end-to-end training including both the designer and executor?**\n\n$A_4:$ We thank the reviewer for this insightful question. The core motivation for training only the Designer lies in the **modular nature** of our framework. In DyFlow, the Designer is responsible for planning and organizing the reasoning workflow, while the Executor focuses on carrying out operator-level actions based on those plans. Since the Executor is treated as a black-box solver, we do not require it to be trained jointly with the planner.\n\nThis separation brings several practical benefits. First, it allows the trained Designer to transfer seamlessly across different Executors without any additional tuning. As shown in Figure 4 and Appendix D.5 (Table 10), a Designer trained via DyFlow self-play consistently improves performance when paired with new executors such as GPT-4o-mini or GPT-4.1-mini. Second, avoiding fine-tuning of the Executor significantly reduces training cost, while maintaining compatibility with off-the-shelf LLMs. Finally, this architectural modularity enables clearer debugging, reuse, and **system interpretability**—advantages that would be compromised in an end-to-end setting.\n\nWhile it is possible in principle to jointly train both components, doing so would increase optimization complexity and compromise the generality of the approach. Our results demonstrate that learning to plan is sufficient to achieve strong performance across a wide range of tasks.\n\n**$Q_5:$ In Figure 2, could the authors annotate where the executor is in the diagram? The current diagram only includes a designer component.**\n\n$A_5:$ We thank the reviewer for pointing this out. In our current diagram, the Executor is **implicitly represented** within each instantiated operator in the subgraph. Specifically, each operator node (e.g., Op Instance) corresponds to a call to the Executor, which performs reasoning or code execution based on the given operator definition and input.\n\nTo keep the figure concise, we abstracted away the Executor as part of the operator execution process. We agree that **explicitly annotating** the Executor component would improve clarity, and we will revise the figure accordingly in the final version to make this architectural separation more transparent.\n\n**$Q_6:$ In Algorithm 1, could the authors explain what the content is in the memory? What is a list of keys? And how are the inputs retrieved from the memory?**\n\n$A_6:$ We thank the reviewer for this detailed question. In DyFlow, the memory $\\mathcal{M}$ is implemented as a **global key–value dictionary** that records all intermediate outputs produced by operator executions throughout a session. Each result is written back into the memory under a unique key—typically based on the operator’s ID. This enables downstream operators to reuse prior outputs without recomputation and allows the Designer to access the full task history when replanning.\n\nIn each operator instance $(O_k, \\phi, \\psi)$, the list $\\psi$ denotes the **ordered list of memory keys** whose values serve as inputs to that operator. During execution, the Executor retrieves inputs via simple dictionary lookups: for each key $k \\in \\psi$, it queries $\\mathcal{M}[k]$, constructs the input, and applies the operator logic accordingly. This memory-based design ensures stateless, traceable execution and transparent data flow across reasoning stages. We will clarify this point in the revised version of the paper.\n\n---\n\nThank you again for your valuable time and suggestions and we would greatly appreciate your kind support during the discussion phase."}, {"review_id": "wjWElHqTHu", "reviewer": "Reviewer_w8CR", "summary": "This paper introduces DyFlow, a dynamic workflow framework for LLM-based agents that adaptively constructs and updates subgoal plans during execution. It addresses a key limitation in existing agent frameworks—namely, their reliance on static, predefined workflows that cannot respond effectively to intermediate execution failures or evolving task contexts.\n\nDyFlow features a two-tier architecture:\n- A Designer, which generates structured stage subgraphs (subgoal plans) based on the current task state\n- An Executor, which runs the subgraphs using parameterized operator templates\n\nThe Designer is trained using a two-phase strategy:\n- Supervised Fine-Tuning (SFT) on high-quality subgraphs, followed by \n- KL-regularized Trajectory Optimization (KTO), where the model learns from its own successes and failures.\n\nThe system is evaluated across five reasoning domains—math, code, medical, logic, and social—showing strong gains in accuracy, Pass@k stability, and cross-task generalization. Ablation studies and case analyses show the importance of dynamic planning and the self-play optimization loop.", "questions": "### Questions\n\n- How does DyFlow differ empirically and conceptually from OctoTools, which also supports dynamic, feedback-aware planning through a planner–executor loop?\n- Why does PubMedQA performance improve in the cross-task generalization setting (75.20 in Table 3) compared to the task-specific training setting (72.91 in Table 1)?", "limitations": "The paper includes only a brief mention of future work. It would benefit from a more thorough discussion of its limitations, a clearer positioning of its contributions in relation to recent work, and a more detailed exploration of future research opportunities.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "### Strengths\n\n- Clear Motivation & Scope: Addresses a key limitation in LLM agents—static workflows—with a modular, dynamic planning architecture.\n- Clean Design: The planner–executor–memory framework is well-structured, extensible, and easy to interpret.\n- Strong Empirical Results: Demonstrates consistent gains across diverse reasoning domains, with good ablations and generalization tests.\n- Open-Model Compatibility: Shows that dynamic planning and planner refinement work well even with lightweight open models like Phi-4, supporting practical deployment.\n\n### Weaknesses\n\n- Limited Novelty in Dynamic Planning: The planner–executor loop closely resembles recent frameworks like OctoTools, which also support step-wise, feedback-based replanning. The paper lacks a detailed conceptual or empirical comparison to such systems.\n- Weak Medical Evaluation (Table 1): PubMedQA is not an ideal benchmark for medical reasoning due to its limited diagnostic complexity and constrained answer format (yes/no/maybe). The paper does not evaluate on other more common medical reasoning datasets (e.g., MedQA, MedMCQA, MedXpert).\n- Missing Baselines (Tables 1 & 2): The paper omits a key SFT-only baseline (e.g., Phi-4 with simple question-answer SFT), which is needed to isolate the effect of planning and complicated agentic framework. Additionally, Table 2 does not include a direct baseline using the untrained Phi-4 model, unlike GPT and Claude.\n- Incomplete Executor Analysis (Table 4): All evaluations use Phi-4 as the executor. It remains unclear whether DyFlow still provides meaningful gains with stronger executors like GPT-4o or Claude-3.", "was_revised": true, "final_justification": "The authors have adequately addressed the majority of my concerns in the rebuttal. However, the lack of direct comparison with OctoTools—a closely related, training-free framework with overlapping domains—remains a gap.\n\nOverall, while I see clear strengths in the submission, especially in its practical relevance, the remaining issues justify maintaining my original score.", "rebuttal": "We sincerely thank the reviewer for the detailed and thoughtful comments. We have carefully revised the paper based on your suggestions, and we address each point below.\n\n---\n\n**$Q_1:$ Limited Novelty in Dynamic Planning: The planner–executor loop closely resembles recent frameworks like OctoTools, which also support step-wise, feedback-based replanning. The paper lacks a detailed conceptual or empirical comparison to such systems.**\n\n$A_1:$ We thank the reviewer for drawing a connection to OctoTools. While both DyFlow and OctoTools adopt planner–executor paradigms with feedback, their **core design goals and planning mechanisms differ substantially**.\n\nFirst, the target domains differ: OctoTools is designed for multimodal, tool-augmented reasoning (e.g., vision combined with API queries), whereas DyFlow focuses on symbolic and numerical reasoning tasks such as math, coding, logic, and medical QA, where dynamic workflow restructuring is central to performance.\n\nSecond, the planning granularity differs: OctoTools selects one tool at a time for each step, while DyFlow’s Designer generates an entire subgraph of symbolic operators per stage and re-plans after execution. This enables more structured adaptations, such as inserting or retracting subgoals when needed.\n\nThird, DyFlow trains its planner explicitly, while OctoTools relies on a zero-shot, frozen planner. Our Designer undergoes two training phases, which enable it to internalize complex preferences and learn robust control behaviors.\n\nWe appreciate the reviewer’s suggestion and will add a discussion section to clarify these distinctions. We also view OctoTools as an elegant and impactful system, and we are excited to explore how some of its design principles (such as flexible tool interfacing) can inform future iterations of DyFlow.\n\n**$Q_2:$ Weak Medical Evaluation (Table 1): PubMedQA is not an ideal benchmark for medical reasoning due to its limited diagnostic complexity and constrained answer format (yes/no/maybe). The paper does not evaluate on other more common medical reasoning datasets.**\n\n$A_2:$ We appreciate the reviewer’s thoughtful feedback. Our primary goal in selecting PubMedQA was not to fully capture the complexity of clinical diagnosis, but to demonstrate DyFlow’s ability to generalize across **diverse reasoning domains**, including biomedical literature, within a unified planning framework.\n\nPubMedQA offers a controlled, domain-specific benchmark that still requires models to extract and verify factual claims from noisy, technical abstracts. While the answer space is limited, it provides a useful proxy for evaluating dynamic planning under high-stakes, text-intensive conditions. Notably, recent works such as [1] and [2] have continued to adopt PubMedQA due to its relevance and robustness.\n\nThat said, we agree that more comprehensive benchmarks like MedQA, MedMCQA, or MedXpert offer deeper diagnostic and multi-hop challenges. Extending DyFlow to these richer settings is a promising direction for future work.\n\n[1] Towards Medical Complex Reasoning with LLMs through Medical Verifiable Problems\n\n[2] EvoBench: Towards Real-world LLM-Generated Text Detection Benchmarking for Evolving Large Language Models\n\n**$Q_3:$ Missing Baselines (Tables 1 & 2): The paper omits a key SFT-only baseline (e.g., Phi-4 with simple question–answer SFT), which is needed to isolate the effect of planning and complicated agentic framework. Additionally, Table 2 does not include a direct baseline using the untrained Phi-4 model, unlike GPT and Claude.**\n\n$A_3:$ We thank the reviewer for highlighting this important baseline. To isolate the effect of dynamic planning, we added a Phi-4 baseline trained purely with SFT on GPT-4.1-labeled question–answer pairs, without any workflow structure or subgoal decomposition. As shown below, this SFT-only model performs competitively, but **DyFlow still consistently outperforms it** across all domains:\n\n| Method        | SocialMaze | PubMedQA | MATH  | LiveBench | HumanEval |\n| ------------- | ---------- | -------- | ----- | --------- | --------- |\n| Phi-4 (SFT)   | 11.45      | 67.73    | 69.60 | 40.67     | 88.07     |\n| DyFlow (Ours) | 17.18      | 72.91    | 76.40 | 48.67     | 92.07     |\n\nThese results demonstrate that DyFlow’s improvement comes from its **structured, multi-stage planning**.\n\nRegarding the reviewer’s suggestion to include a zero-shot Phi-4 baseline: in our pilot experiments, an untrained Designer using raw Phi-4 generated valid subgraphs in fewer than 5% of the cases, primarily due to Phi-4’s limited capability. As such, it could not serve as a meaningful or informative baseline. We will clarify this rationale in the revised version.\n\n**$Q_4:$ Incomplete Executor Analysis (Table 4): All evaluations use Phi-4 as the executor. It remains unclear whether DyFlow still provides meaningful gains with stronger executors like GPT-4o or Claude-3.**\n\n$A_4:$ We thank the reviewer for this insightful question. Yes, we have conducted extensive cross-executor evaluations to test DyFlow’s generality beyond Phi-4. As shown in **Figure 4** and detailed in **Appendix D.5 (Table 10)**, the Designer trained with DyFlow self-play transfers seamlessly to stronger executors such as GPT-4o-mini and GPT-4.1-mini, without any additional tuning. In all settings, DyFlow consistently outperforms CoT-style prompting.\n\nThis ability to generalize arises from DyFlow’s **decoupled architecture**: the Designer is trained to orchestrate workflows and manage information flow, while treating the Executor as a black-box reasoning module. Since the Designer itself does not perform the reasoning, it can easily interface with a wide range of LLMs, enabling plug-and-play compatibility and strong zero-shot transfer.\n\n**$Q_5:$ Why does PubMedQA performance improve in the cross-task generalization setting (75.20 in Table 3) compared to the task-specific training setting (72.91 in Table 1)?**\n\n$A_5:$ We thank the reviewer for raising this point and sincerely apologize for the confusion caused by the use of abbreviations in Table 3. Specifically, the row labeled **QR corresponds to PubMedQA** (question answering), not MR, which stands for MATH (mathematical reasoning). The full mapping is as follows:\n\n- SR: SocialMaze (social reasoning)  \n- CR: HumanEval (code reasoning)  \n- MR: MATH (mathematical reasoning)  \n- **QR: PubMedQA (medical Question answering)**  \n- LR: LiveBench (logical reasoning)\n\nAccordingly, the correct cross-task performance for PubMedQA is **72.11**, as shown in the QR row, which aligns closely with the task-specific performance of 72.91 in Table 1. We will revise the table in the final version by adding a clear legend with these task categories to prevent misunderstanding.\n\n---\n\nThank you again for your valuable time and suggestions and we would greatly appreciate your kind support during the discussion phase."}]

Author rebuttal:

Meta-review: The submission proposed a workflow optimization solution. Basically, it includes two parts, 1). the designer to propose step wise plan, which is trained by SFT, self-play and KTO, and 2). the executor that can be any existing open or closed sourced LLM. The major contribution is to let the step-wise enviroment signal to guild the evolution of plans and thus effect the executor.
In summary, I do think it is an interesting work with solid contribution.
In the discussion period, all the reviewers agree to accept. As the agentic workflow automation and optimization are getting popular in the community, I thus champion the acceptance.
Decision: Accept (poster)