DynaFlow: the orchestrator that writes its own workflow, and where its 10.9 points come from

Every multi-agent system I have shipped had a graph that a human drew. A planner node, a few worker nodes, a reviewer, edges decided in a design meeting. DynaFlow, a paper from Ruhao Liu, Qi Li, Shizun Wang and Xinchao Wang posted on October 25, throws the drawing away. The main agent writes a fresh program for each task, the program calls frozen sub-agents, and only the main agent is trained. The headline is 88.08% overall accuracy against 77.18% for the strongest baseline, a gap of 10.90 points on the same Qwen3.5-27B backbone. I read the tables to see where those points come from, and the answer changes how I would use the idea.

What DynaFlow actually does

Workflow synthesis lives inside the main agent's action space. When it decides collaboration is worth it, it emits a JavaScript program built from four primitives: agent, parallel, pipeline and phase. Sub-agents can be asked for structured JSON, so information passes between steps as data rather than prose. Execution results and traces come back to the main agent, which can then answer, call tools, or launch another workflow.

Training is deliberately cheap. The main agent is Qwen3.5-27B fine-tuned with QLoRA. Stage one uses 2,257 first-turn examples distilled from GLM-5.3 Max on HotpotQA and BrowseComp. Stage two refines on 712 selected examples, filtered for three defect types: premise injection (the orchestrator sneaks an unsupported assumption into a sub-agent prompt), verification defects, and information-flow defects. Each flagged defect must be backed by an excerpt from the program itself. The whole run took about 69 GPU-hours. Sub-agents are the untouched base checkpoint, which is the point: orchestration skill is learned separately from executor skill.

There are two modes. Forced requires the first real action to be a workflow; Dynamic lets the agent choose between answering directly and orchestrating. Dynamic scores 87.94, almost the same, while launching 2.44 sub-agents per question against roughly 4.16 in Forced. That 41% cut in sub-agent calls is the most practically useful number in the paper, because it says a trained orchestrator can learn when not to orchestrate.

Where the 10.9 points come from

The overall score is micro-averaged over 688 questions: 30 each from AIME 2024, 2025 and 2026, 200 from PolyMATH, 198 from GPQA-Diamond and 200 from HotpotQA. A 10.90-point gap is about 75 questions. I did the arithmetic per benchmark against Self-Refine, the strongest baseline.

Seventy-one of the roughly 75 questions come from HotpotQA. Without it, my calculation puts DynaFlow at about 90.0% and Self-Refine at about 89.1%, under a point apart. The authors are upfront about why: "The tool-free baselines do not have the same retrieval access as the workflow settings." HotpotQA is multi-hop retrieval, and the baselines did not have search. The fairer row, base model plus web search, scores 74.71 overall, but that is a single agent with a tool, not a tuned multi-agent design with retrieval. HotpotQA also supplied training demonstrations. On GPQA-Diamond, Self-Refine and AFlow both stay ahead, and the paper traces the errors to wrong sub-agent conclusions misleading the verification step.

On reasoning-only tasks a learned orchestrator is roughly as good as a fixed loop. On retrieval tasks, the program it writes is what gives the model access to evidence at all.

Fixed graphs versus generated programs

So is this the end of drawing graphs in LangGraph? For me, no. A fixed graph gives you things a generated program does not: checkpointing at known nodes, human interrupts at known points, stable traces you can diff between runs, and tests that exercise a topology you know in advance. I wrote about when that structure is more cost than benefit, and the honest answer is that most production flows I see have three or four shapes, not a new one per request.

What DynaFlow offers is a stronger version of the supervisor pattern: the supervisor emits a whole plan as code instead of picking the next node, and the plan is an artifact you can log, replay and lint. The risks are the ones you would expect from executing model-written JavaScript. You need a sandbox, a hard cap on parallel fan-out, and a budget, because nothing in the paper reports tokens per question. Output limits were 81,920 tokens for the main agent and 65,536 per sub-agent, which multiplied by four sub-agents is a lot of headroom to pay for.

What I would take from it

I would not retrain an orchestrator on the strength of this paper. I would steal two pieces. First, restrict orchestration to a tiny vocabulary like agent, parallel, pipeline and phase, validate the generated program against it before execution, and store it with the trace. Second, reuse the defect taxonomy as an automatic review step: check every generated plan for injected premises, missing verification and broken information flow before it runs. Then measure your own version against a single agent that has the same tools. That comparison is the one this paper skipped, and it is the one that decides whether the extra agents earn their tokens.