DynaFlow: teaching one agent to write the workflow, not the answer
DynaFlow fine-tunes only a main agent to write executable JavaScript workflows that coordinate frozen sub-agents, and reports 88.08% across six benchmarks. The idea is sound and the training signal is interesting, but the headline 10.9-point margin over baselines comes mostly from one benchmark where the baselines had no search access.
Most multi-agent systems I see in production have a fixed shape. Someone draws a planner, a few workers and a reviewer, wires them together, and every request flows through the same graph whether it needs to or not. DynaFlow: Learning Free-Form Multi-Agent Orchestration (Liu, Li, Wang and Wang, NUS) takes a different approach. It makes writing the workflow an action the agent can take, then trains the agent to take that action well.
The paper is worth reading for its mechanism and for the way it builds training data. The headline number needs more care than the abstract suggests, and I'll explain why below.
The mechanism
The main agent, Qwen3.5-27B, gets three kinds of action: answer directly, call an ordinary tool, or write a JavaScript program and hand it to a workflow runtime. The runtime exposes a small set of primitives (agent, parallel, pipeline, phase), and the program decides which sub-agents run, in what order, and which upstream outputs each one receives. Sub-agents see only what the program passes them. They do not inherit the main agent's history.
The runtime returns the program's output together with an execution trace. The main agent appends both to its history and decides what to do next: answer, call a tool, or write a follow-up workflow. That loop is the main difference from earlier work. Per the paper's related-work section, DyFlow builds plans from a finite set of operator templates, and MAS-Orchestra generates the whole coordination structure in one decision without seeing intermediate results. DynaFlow does neither: the topology is free-form code, and the agent can revise it after seeing what happened.
Only the main agent is trained. Every sub-agent is the untouched base Qwen3.5-27B checkpoint. I think this is the right experimental choice: the workers cannot get better, so any gain has to come from the main agent, through how it coordinates and, as I note below, through its own reasoning. It also matches how teams actually deploy these systems, since you rarely get to retrain every model you call.
The training signal is the interesting part
Training is two rounds of supervised fine-tuning with QLoRA, using about 69 H100 GPU-hours in total. Stage 1 distills first-turn trajectories from a GLM-5.3 Max teacher, keeping only those with correct final answers that actually delegate the solving to sub-agents. Stage 2 continues on a smaller curated subset: 712 examples selected by an LLM judge that looks for three specific defects in the workflow program:
- Premise injection: the main agent states claims that decide the answer, go beyond what the task gives, and are presented as established facts.
- Verification defects: the reviewer's instructions push it toward an expected answer or prevent it from revising.
- Information-flow defects: missing context, wrong references, or hard-coded values standing in for upstream outputs.
The judge has to quote matching excerpts from the program for every defect it reports, and the authors check those quotes against the program text. I have seen all three failure modes in production agent systems. The verification defect is the most common one: a reviewer prompt such as "confirm the answer is 42" is not verification. A correct final answer does not prove the coordination behind it was sound, and this paper treats orchestration quality as its own selection criterion.
The structural changes are large. Workflows that pass upstream outputs and explicitly tell downstream agents to use them rise from 12.6% (Base) to 97.7% after Stage 2. Hybrid parallel-plus-sequential programs rise from 3.4% to 85.6%. Workflows that review and refine intermediate results rise from 28.1% in Stage 1 to 35.9% in Stage 2, while the average number of sub-agents falls slightly, from 4.35 to 4.16.
Untrained orchestration mostly hurts
The result I would put first is not the headline number. An untrained main agent forced to orchestrate scores lower than the same model answering directly on five of the six benchmarks. HotpotQA is the exception, and its gain is large enough that Forced mode still comes out ahead on average, 75.87% against 71.51% Direct. In Dynamic mode, where the base model can choose whether to orchestrate, it scores 65.12% against 71.51% for answering directly. Outside the one retrieval-heavy benchmark, giving a capable model a multi-agent harness without training it to use one is a regression. That matches my experience, and it fits the Kim et al. (2026) finding the authors cite, that collaboration benefits depend on the task and the coordination structure.
After training, Forced mode reaches 88.08% and Dynamic mode reaches 87.94%. The Dynamic model also answers 47.1% of questions without launching a workflow, which cuts mean sub-agent usage by about 41%. A gap of 0.14 points between the two modes suggests the model has learned when collaboration is unnecessary, though a single run cannot establish that. For anyone paying for inference, that is the most useful result in the paper.
Where the 10.9 points come from
The abstract reports a 10.90-point lead over the strongest baseline, Self-Refine at 77.18%. The paper's own Table 1 shows how that gap splits across benchmarks.
I recomputed the split from the per-benchmark accuracies. On the 488 math and GPQA questions, DynaFlow Forced gets about 439 right and Self-Refine about 435, a difference of four questions. Almost all of the 10.9 points come from HotpotQA, where the tool-free baselines had no retrieval. The authors say so and add a Base + Web search baseline for that reason. Against that baseline, DynaFlow's HotpotQA margin is a more modest 6 points. On GPQA-Diamond, Self-Refine and AFlow both beat DynaFlow outright.
A few other points I would want addressed before relying on these numbers:
- Training data and evaluation overlap. According to Appendix C, the training trajectories come only from HotpotQA and BrowseComp, and HotpotQA is also an evaluation benchmark. The paper does not say whether the train and test questions are disjoint.
- Small samples, one run. Each AIME year has 30 questions, so one question is worth 3.3 points. Decoding uses temperature 1.0, and I found no variance across seeds.
- Part of the gain needs no workflow. With no tools or workflows at all, DynaFlow's own Direct mode improves from 71.51% to 77.18%. Some of the improvement is in the main agent's reasoning, not in orchestration.
- An internal inconsistency. Section 4 reports 2,031 Stage 1 examples, while Appendix C and Table 3 report 2,257.
The within-harness comparison holds up: same backbone, same frozen sub-agents, same runtime, with only the main agent changed. That takes Forced mode from 75.87% to 88.08%. I would cite that number rather than the baseline margin.
What I take from it
Code-based orchestration with a feedback loop is a better abstraction than a fixed topology, and this paper adds evidence that the policy writing that code can be trained cheaply with SFT. The broader lesson is about data. Filtering demonstrations for injected premises, leading verification and lossy handoffs is something any team building agents can do today, with or without fine-tuning. The same rubric works as a review checklist for prompts you write by hand.
What the paper does not yet show is that learned orchestration beats a strong single agent when both have the same tools. Settling that would take a search-enabled Self-Refine baseline and multi-seed runs.