---
title: 'DyFlow: Dynamic Workflow Framework'
url: https://www.emergentmind.com/topics/dyflow
type: topic
---

# DyFlow: Dynamic Workflow Framework

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" [2509.26062].

## 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 [2509.26062].

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 [2509.26062].

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 $O_k$ is an operator template, $\phi$ is a fine-grained instruction tailored to the current context, and $\psi$ is a list of input keys referencing the global memory buffer $\mathcal{M}$ [2509.26062].

The full execution trajectory is
$$
\tau = (s_0, G_0, s_1, G_1, \dots, G_{T-1}, s_T).
$$
Planning is state-conditioned through a summarizer:
$$
z_t = f_{\text{summary}}(s_t),
$$
followed by
$$
G_t \sim \pi_\theta(\,\cdot\,|\,f_{\text{summary}}(s_t)).
$$
The executor then retrieves the memory entries referenced in $\psi$, executes the operator with the fixed executor policy, and stores the result back into $\mathcal{M}$. 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 $C_{\text{end}}^t$ holds or termination is emitted [2509.26062].

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
$$
D_{\text{SFT}} = \{(f_{\text{summary}}(s_t), G_t^{\text{expert}})\},
$$
and loss
$$
\mathcal{L}_{\text{SFT}}(\theta; D_{\text{SFT}}) =
-\mathbb{E}_{(s, G^{\text{expert}}) \sim D_{\text{SFT}}}
\left[
\log \pi_\theta(G^{\text{expert}} \mid f_{\text{summary}}(s))
\right].
$$
The second phase is KTO-based self-play preference optimization on labeled successful and failed trajectories, using
$$
D_{\text{pref}} = \{(f_{\text{summary}}(s_t), G_t, l_t)\},
\qquad
l_t \in \{\text{preferred}, \text{discarded}\},
$$
with
$$
\mathcal{L}_{\text{pref}}(\theta; D_{\text{pref}}, \pi_{\text{ref}}, \beta) =
\mathbb{E}_{(s, G, l) \sim D_{\text{pref}}}
\left[
L_{\text{pref}}^{\text{single}}(p_\theta, p_{\text{ref}}, l; \beta)
\right].
$$
The reference policy $\pi_{\text{ref}}$ is the SFT-initialized designer [2509.26062].

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 $5 \times 10^{-6}$, 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 $2 \times 10^{-4}$, KL penalty $\beta = 0.1$, bf16, cosine scheduler, and 3 epochs. At inference, both designer and executor use temperature 0.01 [2509.26062].

The paper also gives a theoretical framing in which dynamic policies strictly subsume static policies:
$$
\max_{\pi\in\Pi_{\mathrm{DyFlow}}} J(\pi)
\;\ge\;
\max_{\pi\in\Pi_{\mathrm{stat}}} J(\pi),
$$
and, when feedback-driven replanning helps on at least one task,
$$
\max_{\pi\in\Pi_{\mathrm{DyFlow}}} J(\pi)
\;>\;
\max_{\pi\in\Pi_{\mathrm{stat}}} J(\pi).
$$
It further introduces Bellman-style one-step operators and a residual bound
$$
V^*_T(s_0)-V^{\rm Dy}_T(s_0)
\;\le\;
\sum_{k=1}^T \varepsilon_k
\;\le\;
T\,\max_{1\le k\le T}\varepsilon_k.
$$
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 [2509.26062].

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 $k=1,\dots,5$ in Pass@k evaluation, with **HumanEval Pass@5 = 0.9817** [2509.26062].

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 [2509.26062].

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.

## 6. Nomenclature and related uses of similar names

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 [2509.26062]. 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 [1905.03239]. **"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 [2404.18392]. **"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 [2509.19804].

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 [2603.19675]. 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.

Source: https://www.emergentmind.com/topics/dyflow