Handing one complex job to a single AI, whole, is often too much. So we split up the roles. An AI that parses the request, an AI that plans the sequence, an AI that writes the code, an AI that reviews it — chained together. A work flow stitched together this way is called a multi-agent workflow.
The trouble starts when you try to make this team "better through training." Picture a company that hired a roomful of smart people and still gets no results. Usually it isn't for lack of people. It's because there's no sense of who owns what, and no way for the person who did well to get the credit. AI workflows are no different.
Yet the industry's training methods have leaned to one side. They taught only the "designer" — the role that lays out the order of work and the roles themselves (the Generator, in the paper's terms) — and left the rest of the roles, the ones that actually get their hands dirty following that plan, at their original skill level. As if the success or failure of a dish were the head chef's responsibility alone, which it never is.
FloWright breaks this asymmetry. Simply by grading the record left behind from a single run, it splits responsibility by role — designer or doer, no exceptions — using the same signal. No extra model to assign blame, no hand-labeled answer key, no re-running the workflow on the side. With this signal, obtained for free, it trains every role together — and the training itself is reinforcement learning, repeatedly rolling out each task and updating the policy. The result: on a small 4B model, an average gain of +5.03 percentage points over the pre-training baseline (when multiple roles were grown at once).
The most interesting part isn't the number — it's the method. The way it carves up the failures exposed in an execution trace, by role, for free.
Picture a multi-agent workflow as a kitchen. One station preps ingredients, one manages the heat, one plates, and the guest judges by the single finished plate. The dish comes out bland. Here's the genuinely hard question: who got the seasoning wrong? Licking the finished plate will never tell you.
A workflow is a graph of nodes and edges. Nodes are where work happens (agents, tools, skills); edges are the data and control flowing between them. FloWright uses this graph as the kitchen's scoring apparatus. The paper calls it the harness — think of it as the judging system that runs the workflow to the end to produce an answer and then grades that answer. The single score it emits serves as the evaluation metric, as the training signal, and as the objective for the test-time optimization described later. All three are drawn from one apparatus.
The key is how it traces failure backward. The harness leaves a record of which processes the dish went through and in what order, like footage of the cooking. This record is the execution trace — literally, the footprints of "who did what." And each role has the nodes it "authored": the designer owns every node it drew and wired, while an execution role owns the agent nodes it actually ran.
Let's follow one concrete scene. On some task, a single node threw an error mid-run and stopped, and the nodes hanging off it couldn't get their inputs and collapsed one after another. The final answer was wrong. Here the harness scans the trace for the failed node and its dependencies, drops the cascade failures that merely toppled afterward from the blame, and pins responsibility only on the node that slipped first. If the designer wired that node, the blame goes to the designer; if an execution role ran it, to that execution role. Nobody gets stuck with the whole thing — blame is divided only within the range of nodes each one authored. This is structure-aware credit.
That said, this rule only catches what the execution record exposes as a "failed node." A mistake that didn't surface as a failure — a node that ran without error but produced the wrong result, or a dropped line of a requirement — this apparatus can't single out; it leaves that to the global signal of the hierarchical reward described later (how correct is the answer?). And where one role's authored nodes overlap with another's, responsibility doesn't divide cleanly. So the precise claim is not "it automatically reveals every wrong spot" but "it divides the exposed failures by role."
Here's where the decisive saving comes in. That cooking footage is something the harness already left behind while grading. To assign blame, there's no need to attach a separate judge model or reward model, no need for human annotation, no need to re-run the workflow several times. Prior work spent exactly those extra costs trying to locate responsibility — and still often pinned it in the wrong place. FloWright merely reads the footprints that are already there.
The second apparatus measures "how far up it got": the hierarchical reward. Instead of flattening the outcome into pass/fail, it stacks rungs like a ladder. Does the output read in the right format? Is the contribution valid? Does the workflow run to the end and produce an answer? And how correct is that answer? The structure-based credit above attaches as a fifth rung. Thanks to this, even if the dish tips over midway, the signal "it got up to rung three" remains. Instead of a silent zero, it's feedback that points a direction. The weight of each rung is set differently per role.
Once these two apparatuses are in place, any role can pull its own share of the reward from the same single harness. That lets you widen the scope of training. You can self-evolve a single role, grow agents and skills together, grow the upstream that designs and the downstream that executes together, or grow multiple agents at once.
Growing several together produces something interesting. When one role improves, the very situation the next role faces changes. As the prep station gets more skilled, the heat station receives more evenly prepared ingredients and practices at a new level. Each becomes a practice workbook for the others. The paper calls this a mutual curriculum.
Training splits into two moments. At training time, reinforcement learning changes the model's weights themselves. At test time, without touching the weights, it distills reusable prior knowledge. Distillation means summarizing what was solved well into a short reference. It's like leaving a recipe card for a successful dish so the next team can consult it. The knowledge can be drawn from one's own experience, from a stronger teacher model, or from both.
Judging this properly required a proper problem set. Multi-agent workflows have been evaluated on data that a single agent can solve — single-question math, single-function coding. On such easy problems, re-measuring shows almost none of the advantage of putting many hands on the job. You can't see what a workflow accomplishes beyond a soloist.
That's where DataWright comes in. It reworks existing datasets to be harder, bundling several sub-questions into tasks that genuinely "require a workflow." The grading method is kept as-is; only the difficulty is dialed up.
Training was run on 4B and 9B models of the Qwen3.5 family, across four datasets. Evaluation was cast much wider. Beyond the two open-source models, it extended to a closed model as well, all measured on held-out test sets never used in training. Because one role can use a model of a different size than another, they also looked at a small upstream with a large downstream, and the reverse.
The evaluation sheet has three zones. The conditions used in training (in-distribution), the same datasets but with strategies and difficulties training never saw (out-of-distribution), and datasets not used in training at all (out-of-domain). What this design measures is clear: not "does it do well under the conditions it learned," but "how far does it spread to unseen strategies, difficulties, and domains." Equally clear is what this sheet cannot measure: real service traffic, live cost and latency, and interaction with human users are not in it.
The first thing that stands out comes before any training even begins. Just running a workflow built with the FloWright structure — even on a small 4B model — pulled far ahead of a single tool-equipped agent (32.09 vs. 20.70). It means that organizing work well beats racking a single brain, and the smaller the model, the more so.
| Setup (Qwen3.5-4B) | Overall accuracy (%) |
|---|---|
| Single agent (no tools/skills) | 7.42 |
| Single agent (with tools/skills) | 20.70 |
| FloWright (before training) | 32.09 |
| + single-role self-evolution | 34.92 |
| + upstream-downstream co-evolution | 35.15 |
| + agent-skill co-evolution | 36.15 |
| + multi-agent co-evolution | 37.12 |
More important is the direction. The more roles grown together, the larger the gain. Training a single role: +2.83pp. Growing upstream and downstream together: +3.06pp. Growing agents and skills together: +4.06pp. And at the far end, growing multiple agents at once was the largest (the bottom row of the table). What's more, this multi-agent co-evolution held a plus across all three zones — every dataset, strategy, and difficulty. In other words, it didn't rise in just one lucky condition.
Let's put the abstract's "up to +7.41pp" in its place. That number is not the overall average. It's the largest gain in one particular cell of conditions (39.32 vs. 31.91), so it should be kept distinct from the average improvement.
There was also an effect where a role refined on a small model keeps its benefit even when mixed with a large one. A role optimized at 4B was left at 4B while the rest ran at 9B, and dropped into that mixed combination it carried its benefit along — at times pushing accuracy above an all-9B baseline. Rather than transplanting the small model's learning into the large one, this opens a path where a cheaply refined small role is left as-is and large models are attached to the other roles. The direction holds for 9B on its own too: a pre-training 47.50% became 51.39% (+3.89pp) with single-role self-evolution.
Test-time optimization, which leaves the weights untouched, also delivered. But there's a point worth noting. The approach of summarizing successes into examples gave the biggest benefit when five cases were provided, whereas with just one it actually came in below the pre-training baseline. With a single case there isn't enough basis to generalize; the reference only helps once some amount of evidence has accumulated.
One last gauge. The absolute accuracies are low, in the 7–50% range. That's because these aren't an easy benchmark but tasks made deliberately hard with DataWright. These numbers are a yardstick not for "an AI that solves well" but for "what a workflow adds over a soloist."
Let's narrow it to one scene. A customer requests, "Build me an inventory-management dashboard." ONTLE's AI PM breaks this into intake → analysis → design → development → QA and assigns a specialist role to each stage. If the PM that splits up the request is FloWright's upstream, then the roles that actually carry out analysis, design, development, and QA are the downstream.
When improving this pipeline, the easy place to reach for is the PM's decomposition logic — the upstream. What FloWright says is: don't stop there. If you refine only the PM that splits the request well and keep the execution roles fixed, you structurally cap how much the whole can improve. Suppose that, in the case above, the analysis role missed a single requirement line — "alert on inventory threshold" — and the project collapsed at the development stage. This isn't because the PM split the work wrong; the analysis role slipped. Tinkering with only the PM, the same failure repeats.
This is where structure-based credit comes in. ONTLE already records its workflow as a git-graph (rails, nodes, parent_id) and retains execution traces. But the mere fact that a record exists does not, by itself, divide responsibility by role. Two more things are needed: knowing "which role authored each node," and a rule that follows the failed nodes in the execution record and their dependencies to clear the cascade failures and pinpoint the node that slipped first. Only with these two can a single completion score be split into feedback for the analysis, design, development, and QA roles.
That said, the line the original paper draws must be carried over to ONTLE intact. What gets divided by role this way is only the nodes exposed as "failures" in the execution record. A mistake like the missing "inventory-threshold alert" above — where the node ran fine but a requirement line was dropped — isn't caught as a failed node, so this rule alone won't automatically pin it on the analysis role. That share is borne by the global reward scored on the project's overall outcome, and where node authorship overlaps between roles, responsibility still doesn't divide cleanly.
The ladder-style reward can be ported over as well. Even if a project doesn't reach completion, leaving rungs for how far it got — "requirement parsing succeeded and the design was valid, but it stopped at development execution" — lets you adjust the next decomposition and assignment to steer around that spot. But let's be clear: this is a design implication portable to ONTLE, not a claim that it's implemented today.
The authors state a premise of their own. The in-distribution zone uses training difficulties for evaluation too, but with specific levels carved out — so that score is "a score within the training distribution."
The questions that remain, as I see them: the training backbone leans toward the Qwen3.5 family, and while evaluation is broad, training starts from the relatively narrow footing of four datasets. The conclusion that co-evolution is good is clear, but the operational trade-offs — training cost and convergence difficulty as the number of roles grows — are too early to judge from this table alone. It's also worth remembering that only one axis, benchmark accuracy, was examined. Cost, latency, and stability — no less important in a real service — have to be measured with other yardsticks.
It means that making a better workflow takes the whole workflow, not a swap of a single designer. The title captures the study's claim that the roles that compose and execute must co-evolve, pushing each other upward like practice problems.
No. FloWright is the method side — training every role together. DataWright is the problem-set-generation side, turning easy datasets into hard, "workflow-required" tasks so that method can be evaluated properly. Think of it as two axes: the method and the evaluation environment.
Training is cheaper and faster the smaller the model. You can refine one role on a small 4B model, then run that role at 4B while running the other roles on a large 9B model — a mixed setup. Rather than transplanting the small model's learning into the large one, you keep the cheaply trained small role and attach large models to the other roles. This study showed a case where a mixed combination built that way outran an all-large baseline, which demonstrates the possibility.
The paper is on arXiv, the summary and discussion are on HuggingFace, and the authors' project page is named in the abstract. Start from the links in the references below.