Say a project lands at ONTLE: "Research our competitors' prices and turn it into a summary report." The job breaks into three pieces. Gathering the material, analyzing the data, writing the report. A workflow where several AIs split up the roles and handle a single job together like this is called a multi-agent workflow (a work pipeline where several AI agents divide the labor).
The weakness of this approach shows itself the moment one step goes wrong. When the data analysis spits out a nonsense result, the usual move is to run the whole thing again from scratch. You pay twice even for the material-gathering that already finished cleanly. It's like rebuilding the entire house because one faucet is leaking.
A paper called InFlowOp doesn't rebuild the house. It fixes only the leak. And it does so without waiting for the run to finish — mid-stream — and without an "answer key" (a standard written out in advance saying what the correct answer is). This article follows that one report from start to finish and looks at three things. How it decides who should handle the analysis step, what it looks at to rule that something "went wrong," and how far back it rewinds.
Let me tip off just one thing in advance. The most interesting part of this paper isn't how it repairs. Behind that repair technique hides a more important question, and the answer will be told to you directly by the numbers at the end of the article.
At the heart of InFlowOp sits a single scale. It measures how to divide the work and whom to assign it to, by converting the odds of success (confidence) and the time it takes (latency) into a single combined score. And the path with the lowest score wins.
Let me put up a scene so it lands right away. There are two candidates for the analysis step. One is a large model that's accurate but slow; the other is a small model that's fast and cheap but often wrong. The large model has high confidence but high latency; the small model is the opposite. The scale puts both on the same ruler and picks whichever lowers the total score more. In effect, it pits "how well does this fill what the job demands" against "how much does it cost to run."
Just remember that "cost" here is not money printed on a bill, but a score for choosing a design. This distinction gets used again later when we read the numbers.
So how are the candidates that go on the scale chosen in the first place? For that, the work has to be cut into pieces first. InFlowOp doesn't fix the number of pieces in advance. The finer you split, the narrower and more trustworthy each piece becomes — but the number of AIs you have to run grows, slowing things down and multiplying the junctions where things can go wrong. So it first breaks the work all the way down to the smallest indivisible units, then merges back together only when merging lowers the score. Even how finely to divide is decided by the score, not by taste.
Once the pieces are set, candidate AIs go on the scale for each piece. The criterion for judging is the key here — and it is not whether the output matches the correct answer. The items that must appear in the deliverable are written out in advance, and each candidate is scored on how many of those items it can fill. It works by matching each candidate's self-declared capabilities and its accumulated track record against what the piece demands.
This is the clever point of the paper. Because it looks only at "does it have the required items" rather than "does it match the answer," the evaluation works even when the answer is unknown.
If no candidate clears the baseline, that piece reveals itself as "a seat with nobody to fill it." Only then is a penalty charged to create a new AI and add it to the candidates. The important thing is that the choice to force-assign and the choice to create anew compete on the same scale. So creating something new happens only when truly no one can take it.
No matter how well you planned it, a design is in the end a prediction. The real weakness shows its first face only when you run it.
Back to the report. On running it, the data analysis step put out an unusable table. But the report-writing step is already writing sentences on the premise of that table. What do you look at to rule that something went wrong?
Here too, InFlowOp doesn't compare against the correct answer. Instead it hangs a "contract" on each step before it starts. The conditions for the input this step should receive, and the conditions for the output it should produce.
Let me make it concrete with the analysis step of the price report. The input condition is, for instance, "the table handed over by the material-gathering step must have each competitor's price filled in with no blanks, and the currency unit must be unified into one." The output condition is something like "the analysis result must have as many comparison rows as there are competitors, and each row must contain a price and a rank as numbers." The correct answer (who the real market leader is) can only be known once the whole project is done, but these conditions can be written out before the step even starts. That's how it pinpoints the spot that went wrong mid-run, without finishing the whole thing.
The judgment goes one step further. Which side of the contract was broken is what divides responsibility. If the output condition wasn't met — say, all the comparison rows are there but the rank cells are empty — then the work was laid out properly but the assigned AI fell short. Conversely, if things went off from the input condition onward — if the price cells of the handed-over table were empty to begin with — then it never even received the materials it needed. The latter can't be fixed by swapping the person in charge. The very way the work was divided has to be reworked.
Once the judgment is done, execution halts at only that broken step. The progress already accumulated is left untouched. The repair moves are pulled out cheapest-first.
The cheapest move is to swap the assignee only. The step and the dependency structure stay as they are; only the assigned AI is replaced. The candidate that just failed is dropped and the next-best is brought up. This is the move used when the output falls short.
If that doesn't work, it goes up one more level. It turns that step into a smaller workflow by cutting it into finer pieces. It costs the price of running the decompose-and-assign we saw earlier one more time, just at that spot. This is the move used when the input was deficient from the start.
Every move has a budget attached. When it's used up, things revert to their original value. A changed result is reflected only when it passes verification; otherwise it's discarded. Thanks to this, repair can make the workflow better, but it won't let it become worse than what was already built.
After repairing, how far does it re-run? The only things that need to be rewound are the downstream tasks that were leaning on that step's result. In the report example, only the report-writing that depended on the analysis re-runs. The material-gathering, already finished outside that, is reused as is. The cost of one repair is bound to the affected scope rather than the whole — this is what "fixing only the leak instead of rebuilding the house" actually looks like.
Now, the numbers. The authors first fixed the measuring instrument. To properly measure a workflow where several AIs divide the labor, you need tasks built to match it. So they reworked public datasets to build a separate new benchmark (a standard problem set for measuring performance), Braid. Each task comes with several materials attached, and they filtered them with quality criteria so the materials don't overlap in content, the answer doesn't leak out in advance, and materials that actually fit the question are included.
The core comparison is a single one. With the base model and the number of attempts held equal, and only the composition and repair method changed, how does accuracy shift? The representative figures the paper puts forward are up to 11.97 percentage points over a single agent (solving with one AI) and up to 9.64 percentage points over the workflow baseline. Here "up to" is the highest value across several backbones (the underlying AI models) and branches, not the representative result of any one model. And note that this 9.64 percentage points is the maximum improvement produced by "how the whole workflow is put together," not the isolated effect of the single device of "in-flow repair" taken on its own — that share shows up separately in the table just below.
What tells you more is the table that measures as modules are stacked on one at a time. The base model is Qwen3.5-9B, averaged over 5 domains (fields).
| Composition | Accuracy (%) | vs. single agent (pp) |
|---|---|---|
| Single agent | 17.38 | — |
| greedy-search | 15.49 | -1.89 |
| Coalesce (cost-based splitting) | 22.21 | +4.83 |
| Coalesce + in-flow repair | 23.80 | +6.42 |
| InFlowOp (full) | 25.13 | +7.75 |
The reading order matters. Doing it alone (17.38) is the starting point. Coalesce, which splits based on scores, jumps +4.83 percentage points from there — the single biggest cell in the table. Why becomes clear from the row right above it. greedy-search (greedy splitting), which splits the same way but grabbing only toward what looks good right in front of it, actually came in 1.89 percentage points below doing it alone. So splitting in itself doesn't guarantee a gain. The gain comes from how you split.
Then comes this paper's real twist. Adding in-flow repair on top of a well-built design still moves the needle — about +1.6 percentage points (the table's 23.80 − 22.21) — and the device by which each AI accumulates performance experience and updates its own capability record on its own adds about +1.3 percentage points more. But each of these contributions, taken on its own, is smaller than the single good move of splitting well at the start (+4.83 percentage points). It means getting the up-front composition right is a bigger lever than repairing what went wrong — not that repair does nothing. This is the answer to the "more important question" tipped off earlier.
There's also a scene where scale gets skipped over. Fitting InFlowOp onto the small Qwen3.5-4B reaches a 5-domain average of 20.81. That beats simply running the larger Qwen3.5-9B (17.38), GPT-5-mini (16.33), or GPT-5.4-mini (17.49) alone, all of them. It says that even a small model, dressed in a good design, surpasses the clumsy use of a large one. The pattern holds on the strongest base model too. It rises from 41.99 run alone to 49.37.
Let me head off one misreading here. The numbers in this table are all "accuracy." They are not proof that money or time was reduced. Reading this score straight as "cost savings" falls into a three-layer trap. First, this score was measured only on Braid, which was built for relative comparison, so it doesn't tell you any specific service's actual spending as an absolute value. Second, repair raising accuracy by +1.6 percentage points doesn't mean the actual cost of that repair was that cheap. What the table measures is, start to finish, the accuracy gain. Last, putting latency into the score is no guarantee that the value is seconds measured by a wall clock (the details of the measurement method are in the paper's appendix). In short, this table answers "which design is smarter," not "how much did it save."
The limits are clear too. The gains are large in charts, math, and finance, and smallest in physics. Physics stays low no matter which model or which method you use. It's a signal that there are domains where the base model's reasoning power itself is the wall, one that even coordination design can't get past. The fact that the whole thing stands on an answer-key-free score is also double-edged. Write the contracts sloppily and it lets a wrong step pass or halts a perfectly fine one. And since the score calculation leans on the capabilities an AI declares about itself, if that declaration is exaggerated, the whole scale tilts toward optimism.
ONTLE attaches an AI PM (project manager) to each customer project and carries it from intake to completion. So that one line — "greedy came in below doing it alone" — isn't somebody else's story. If the PM treats cutting a request into fine pieces as a virtue in itself, it only grows the coordination cost. The criterion for splitting must always be "execution cost against fit."
If you overlay InFlowOp's framework onto ONTLE, what changes isn't a few repair procedures but the PM's job itself. Until now, when a price report's analysis table went wrong, the ONTLE PM had only two paths. Run it from scratch (discard the progress), or have a human step in and rework the whole thing. Both paths mean, in the end, that a human re-plans the workflow.
Once this framework comes in, the system takes on the judgment of "how to re-plan the workflow." Then the PM's center of gravity shifts. From a watchdog guarding the quality of each individual task, to a planner watching whether the project's overall goal is being properly achieved. What can be promised to the customer changes too — not "if it goes wrong, a human steps in to fix it for you," but "the system automatically rewinds and re-runs only the piece that went wrong." Even during the rewind, the customer's screen still shows only "in progress" and "done," and a step like the material-gathering that finished first stays alive as is. When the input was deficient and a step has to be re-split, it's a matter of one node (a single point on the map, that is, one step) on the work map branching out into several sub-nodes.
That said, this isn't a feature embedded in ONTLE right now, but the direction this paper points to. It's one line lighting up where ONTLE might go next.
The authors experimented with that approach too, and "calculating" against a checklist of required items came out better than having an AI "judge" the fit. Whether human or model, grading "how well will it fit" by eyeball wobbles. Nailing down the items that must be filled and counting whether they're filled turned out to be more stable.
No. It's a two-stage framework that needs no separate training and no extra answer-key data. There's only one premise — declaring the input and output conditions on each step as a contract.
They reworked 10 public datasets into 14, laid out across 8 domains with 19 evaluation branches. Each task is assembled with two complexities and two composition methods, and gated by four quality criteria — fail even one and it wasn't used as a task. The four quality criteria are devices to keep materials from overlapping in content, keep the answer from leaking out in advance, and keep the materials that fit the question properly included.