DyFlow: Dynamic Workflow Framework

Updated 14 July 2026

DyFlow is a dynamic workflow framework that models LLM agentic reasoning as an adaptive, state-dependent sequence of planning and execution steps.
It employs a hierarchical designer–executor architecture where the designer crafts stage-level plans and the executor dynamically instantiates context-aware operators.
Empirical results demonstrate that DyFlow outperforms static workflow methods across diverse domains by enabling runtime refinements and improved accuracy.

Searching arXiv for the exact "DyFlow" paper and closely related similarly named methods to ground the article. DyFlow is a dynamic workflow generation framework for LLM-based agentic reasoning that treats reasoning as an execution-adaptive process rather than as a fixed prompt chain or a one-shot precomputed workflow. Its central mechanism is a hierarchical designer–executor architecture in which the designer repeatedly constructs stage-level plans from the current execution state, while the executor instantiates and runs dynamic operators with context-aware parameterization and persistent memory. In current arXiv usage, the exact name “DyFlow” refers to "DyFlow: Dynamic Workflow Framework for Agentic Reasoning" (Wang et al., 30 Sep 2025).

1. Problem setting and motivation

DyFlow is defined against a class of LLM agent systems that rely on manually designed processes, fixed agent roles, or static execution graphs. The method is motivated by three recurring limitations: manually designed workflows limit adaptability across tasks; operations are often predefined and inflexible in practice; and intermediate feedback is used only weakly, which reduces robustness and reasoning depth. The paper situates these issues relative to systems such as CAMEL, MetaGPT, AutoGen, and OpenAgents, and also against automated workflow methods such as AFlow, ADAS, and MaAS, which it characterizes as being optimized largely before execution and often tied to particular datasets or query types (Wang et al., 30 Sep 2025).

The framework therefore models reasoning as a sequence of state-dependent planning and execution steps. A task is not assumed to admit a single fixed decomposition. Instead, the current plan can be revised after intermediate outputs, review verdicts, or error signals. This makes workflow generation conditional on the evolving execution state rather than only on the initial task description. A plausible implication is that DyFlow is aimed less at prompt engineering in the narrow sense than at runtime control of reasoning structure.

2. Designer–executor architecture

DyFlow consists of two core components: a designer and an executor. The designer is the strategic component. It decomposes a problem into a sequence of sub-goals defined by high-level objectives, summarizes the current state, and generates the next stage subgraph. The executor is the operational component. It carries out the planned operators, writes outputs into memory, and exposes those outputs to later planning stages (Wang et al., 30 Sep 2025).

A stage subgraph is a local plan for the current reasoning stage. DyFlow does not hard-code branching and looping as explicit workflow syntax in the manner of a fixed graph. Instead, branching, retry, refinement, and effective backtracking emerge from repeated replanning. After each stage is executed, the state is updated with newly produced artifacts such as partial answers, review decisions, or code-repair traces, and the designer generates the next subgraph from that updated context.

The operator library is finite but dynamically instantiated. The paper lists operator templates including DECOMPOSE_PROBLEM, GENERATE_ANSWER, REVIEW_SOLUTION, REFINE_ANSWER, GENERATE_CODE, REFINE_CODE, ORGANIZE_SOLUTION, ENSEMBLE, DEFAULT, and TERMINATE. DyFlow calls these “dynamic operators” because each operator instance is paired with a context-specific instruction and a context-specific set of memory inputs, rather than being used in a fixed role.

3. Formal workflow model and dynamic operators

The method formalizes a reasoning task as a trajectory over states and stage subgraphs. A task is written as

$p \in \mathcal{P},$

with execution state $s_t$ at step $t$ . The operator library is

$\mathcal{O} = \{O_1, \dots, O_N\}.$

At each step, the designer produces a stage subgraph

$G_t = (V_t, E_t, v_{\text{start}}^t, C_{\text{end}}^t),$

where $V_t$ is the set of operator instances, $E_t$ is the dependency structure, $v_{\text{start}}^t$ is the entry node, and $C_{\text{end}}^t$ is the end condition. An operator instance is defined as

$o = (O_k, \phi, \psi),$

where $s_t$ 0 is an operator template, $s_t$ 1 is a fine-grained instruction tailored to the current context, and $s_t$ 2 is a list of input keys referencing the global memory buffer $s_t$ 3 (Wang et al., 30 Sep 2025).

The full execution trajectory is

$s_t$ 4

Planning is state-conditioned through a summarizer:

$s_t$ 5

followed by

$s_t$ 6

The executor then retrieves the memory entries referenced in $s_t$ 7, executes the operator with the fixed executor policy, and stores the result back into $s_t$ 8. In algorithmic terms, the update loop is: summarize state, sample the next stage subgraph, execute the stage in topological order, update state, and stop when $s_t$ 9 holds or termination is emitted (Wang et al., 30 Sep 2025).

This formulation makes DyFlow neither a simple chain-of-thought scaffold nor a fully general symbolic planner. It is instead a stage-wise graph generator whose control signal is the summarized execution state.

4. Training procedure and theoretical framing

Only the designer is trained; the executor is fixed. Training uses two phases. The first phase is supervised fine-tuning on successful planning traces, with dataset

$t$ 0

and loss

$t$ 1

The second phase is KTO-based self-play preference optimization on labeled successful and failed trajectories, using

$t$ 2

with

$t$ 3

The reference policy $t$ 4 is the SFT-initialized designer (Wang et al., 30 Sep 2025).

The reported implementation initializes the designer from Phi-4, trains with LoRA on 2 Nvidia A6000 GPUs, uses GPT-4.1 to generate SFT traces, and uses GPT-4o-mini as the state summarizer. The SFT stage uses 1.5k design results from MATH, PubMedQA, and LiveBench, with batch size 1, gradient accumulation 4, learning rate $t$ 5, cosine scheduler, warmup ratio 0.1, bf16, and 3 epochs. The KTO stage uses 2k design results, positive:negative ratio 1:1, batch size 1, gradient accumulation 8, learning rate $t$ 6, KL penalty $t$ 7, bf16, cosine scheduler, and 3 epochs. At inference, both designer and executor use temperature 0.01 (Wang et al., 30 Sep 2025).

The paper also gives a theoretical framing in which dynamic policies strictly subsume static policies:

$t$ 8

and, when feedback-driven replanning helps on at least one task,

$t$ 9

It further introduces Bellman-style one-step operators and a residual bound

$\mathcal{O} = \{O_1, \dots, O_N\}.$ 0

These results are presented as a conceptual argument for dynamic planning rather than as a direct training objective.

5. Empirical results, generalization, and limitations

DyFlow is evaluated on five domains: LiveBench for logical reasoning, MATH for math reasoning, PubMedQA for medical reasoning, HumanEval for code reasoning, and SocialMaze for social reasoning. The reported train:test split is approximately 1:3, with training performed only on MATH, PubMedQA, and LiveBench, while HumanEval and SocialMaze are held out for zero-shot generalization (Wang et al., 30 Sep 2025).

The main reported results with Phi-4 as executor are:

Domain	Metric	DyFlow
SocialMaze	Accuracy	17.18
PubMedQA	Accuracy	72.91
MATH	Accuracy	76.40
LiveBench	Accuracy	48.67
HumanEval	pass@1	92.07

The average score is 61.45, compared with 57.50 for AFlow and 57.74 for MaAS. The paper further reports that DyFlow outperforms CoT across all $\mathcal{O} = \{O_1, \dots, O_N\}.$ 1 in Pass@k evaluation, with HumanEval Pass@5 = 0.9817 (Wang et al., 30 Sep 2025).

Cross-designer and cross-executor experiments are central to the paper’s generalization claim. In the cross-designer setting, the trained DyPlanner is compared against Claude-3.7-Sonnet and GPT-4.1 and attains the best reported average, 61.45. In the cross-executor setting, DyFlow improves GPT-4o-mini, Phi-4, and GPT-4.1-mini relative to CoT; for GPT-4.1-mini, the reported scores are 42.75 on SocialMaze, 77.29 on PubMedQA, 92.80 on MATH, 71.33 on LiveBench, and 96.95 on HumanEval. The ablation study shows clear drops when removing KTO, SFT, dynamic operators, or dynamic planning, with the full model at 61.45 average and the w/o Dynamic Planning variant at 56.48 (Wang et al., 30 Sep 2025).

The paper identifies a major limitation: no strong integration with external tools/APIs in the current version. It also reports that inference token cost is moderately higher than AFlow and MaAS, about 1.4x–3x, due to the two-stage planner–executor structure, although still much lower than prompt-heavy baselines such as LLM-Debate and Self-Refine. This suggests that DyFlow trades some execution cost for adaptive control.

The name DyFlow is easily conflated with several unrelated or only loosely related arXiv methods. The exact title "DyFlow: Dynamic Workflow Framework for Agentic Reasoning" denotes the LLM-agent workflow framework described above (Wang et al., 30 Sep 2025). By contrast, "Generative Model with Dynamic Linear Flow" introduces DLF, a flow-based generative model with partially autoregressive structure; “DyFlow” is not the official name there, although the phrase “dynamic linear flow” makes confusion plausible (Liao et al., 2019). "Dflow, a Python framework for constructing cloud-native AI-for-Science workflows" refers to a workflow orchestration toolkit for scientific computing over Argo Workflows, Kubernetes, and HPC backends; it is a workflow system, but not an agentic reasoning framework and not spelled DyFlow (Liu et al., 2024). "DynaFlow: Dynamics-embedded Flow Matching for Physically Consistent Motion Generation from State-only Demonstrations" concerns robot motion generation via differentiable simulation, again under a distinct name and problem setting (Lee et al., 24 Sep 2025).

A further nearby name is "DynFlowDrive: Flow-Based Dynamic World Modeling for Autonomous Driving", which uses rectified flow in a latent world model for driving and is unrelated to agentic workflow generation despite the lexical similarity (Liu et al., 20 Mar 2026). The recurring “flow” terminology across these papers does not mark a shared method family. In the specific context of LLM-based reasoning workflows, the exact and official referent of DyFlow is the dynamic designer–executor framework of 2025.