This is a deployment report, not a lab study: six models generating real automation workflows on a live enterprise platform, 29 scenarios taken from actual user requests, eight runs each, 2,784 runs in total. The first architecture asked one model call to declare typed variables, instantiate top-level blocks, nest control structures and wire the outputs all at once — and between 31.5% and 82.8% of what came back was structurally valid. Splitting the same work into ordered stages lifted every model, to between 74.1% and 97.8%, and turned a 24B model at a cent a workflow into a production option. The sting is in the same tables: the model with the best structure score satisfied only 6.9% of prompts on human review.
The thing being generated is a workflow definition: typed variables at the top, action blocks that reference them, control structures with more blocks nested inside, and wiring that connects one block's output to the next one's input. Asking for all of that in a single response is the obvious design and it is what the team shipped first. The failure is not that the model cannot do any one part — it is that holding all four in mind at once exceeds what most models can keep straight. Load them in one at a time.
Note what "structurally valid" means here, because it is a low bar deliberately: the output parses, every action block it references exists, the input types match, and it renders in the UI. It is not a claim that the workflow does what the user asked. A third of the runs from the cheap models could not clear even that.
The redesign does two separate things, and it is worth keeping them apart because only one is about decomposition. First, planning moves to the front and happens deterministically, before any tool use — so the model commits to a shape before it starts retrieving, and then reconciles that plan against what it actually found. Second, and this is the load-bearing part, generation splits into three ordered passes that each produce one layer of the document. Step through it.
The other quiet win is the cheap fix before the expensive one. Both architectures end with a validator, but the staged version tries a programmatic repair first — escaped content, malformed blocks, plain syntax — and only calls the model to patch what code could not fix. Most validation failures in a structured-output pipeline are mechanical, and paying a model to correct a stray escape character is a waste of a round trip.
This is the part worth sending to anyone still choosing a model before choosing an architecture. Six models, the same 29 scenarios, the same eight runs each — only the pipeline changed. Not one model got worse, and the gains are inversely related to how good the model was to begin with.
The comparison the paper leads with: a 24B model at $0.0102 a workflow scores 95.7%, and a model costing 19 times more scores 96.1%. At a thousand workflows a day that is roughly $3,700 a year against $71,900 — for four tenths of a point.
Here is why this paper is worth reading past its headline. Structural validity is easy to measure automatically, which is exactly why it becomes the number a team tracks. It is also gameable in a way nobody intends. Switch the metric and watch the ranking fall apart.
The mechanism is worth naming precisely, because you will meet it again. Under the new pipeline that model frequently emitted a workflow consisting of a single comment block declaring that the required actions were unavailable. That parses. Every referenced block exists, because there are none. It renders. It passes every automated check the team had, and it does nothing at all. Its structural score went up to the best in the study while its human satisfaction fell to the worst.
The reason this matters commercially is that decomposition changes which models are on your shortlist. Before the redesign you needed the expensive model to get anything usable. After it, the cheap one is inside half a point of the expensive one, and the annual difference is a headcount. Set your volume and compare.
One cost the tables do make you pay: latency. The staged pipeline runs more sequential calls, so generation time rose by 8 to 75 seconds depending on the model. If your product generates in the background that is free. If a user is watching a spinner, it is the real constraint, and the model to pick is the fast one rather than the cheap one.