The latest generation of models doesn't just answer — it works the problem first: breaking a request into steps, checking its own intermediate work, and deciding when to use a tool instead of guessing. Vendors brand this differently, but the capability is converging across every major model family. This briefing covers what actually changed, where it lands in real operations, and what it costs.
Key takeaways
- Reasoning-class models plan multi-step work before answering, which moves exception-heavy workflows into automation range for the first time.
- The gains land first in exception handling, document assembly, and data reconciliation — not in chat.
- Reasoning compute costs more per call. The winning designs route hard steps to it and keep deterministic steps on rules.
- Model-agnostic scoping still wins: benchmark candidates against your documents, then hold the winner to written acceptance criteria.
What actually changed
Earlier models produced answers in one pass. Ask for something complicated and quality depended on how well the question was phrased. Reasoning-class models spend compute deciding how to answer before answering — and the practical effect is that multi-step work that used to require chains of brittle prompts now survives contact with messy, real-world inputs.
The mechanism matters more than the branding. These models are trained to produce and check intermediate steps — a plan, a draft, a verification pass — before committing to an answer. That's why they hold up on tasks where the first idea is usually wrong: reconciling two conflicting records, assembling a document from six sources with rules about precedence, deciding which of four playbooks an odd request actually belongs to.
Where it shows up first
- Exception handling. The step in every automation where the input doesn't match the template — previously the reason a person stayed in the loop for everything — can now be triaged, with only genuine judgment calls escalated.
- Document assembly. Work that pulls from many sources with rules about what goes where (proposals, compliance packets, quotes) benefits from a model that plans the assembly instead of improvising it.
- Data reconciliation. Deciding whether two records describe the same entity is a reasoning task, not a lookup — and it is the unglamorous core of most unified-data projects.
Where it doesn't help (yet)
Reasoning is not a universal upgrade. Steps with one right answer and a rule that finds it — validation, lookups, threshold checks — get slower and more expensive under a reasoning model without getting more correct. The same goes for latency-sensitive paths: a model that thinks for twenty seconds has no place in a screen someone is waiting on. A workflow is a mix of both kinds of step, and treating it as all one or all the other is how automation projects go sideways.
The question is no longer “can a model do this?” It's “which steps of this workflow deserve a model, and which deserve a rule?”
The cost calculus
Planning before answering consumes extra tokens, and those tokens are billed. In practice that pushes well-built systems toward tiered routing: a small, fast model or a plain rule handles the routine ninety percent, and the reasoning model is reserved for the exceptions where its judgment earns its cost. Designed that way, the expensive calls are the ones that used to be a person's afternoon.
One thing the new models do not change: who signs. In every system we ship, the model drafts and a person decides — consequential outputs like a quote, a filing, or a customer commitment go through a named reviewer before they leave the building. Reasoning models make the drafts better. They don't make the review optional.
What we recommend operators do
Our guidance is unchanged by the technology — because it never depended on any one model. We are model-agnostic by design: during scoping we benchmark candidate models against your actual documents and your actual edge cases, then recommend the one that clears your accuracy bar at the lowest operating cost. When a better model ships — and one always ships — a tailored system swaps it in behind the same acceptance criteria, without rebuilding the workflow around it.
- 01List the workflows where exceptions, not volume, are the bottleneck — those are the newly automatable ones.
- 02For each, separate the steps a rule can decide from the steps that need judgment. Only the second list needs a reasoning model.
- 03Write the acceptance criteria before touching a model. If you can't state what “correct” means, no model will meet it.
If you're wondering which of your workflows this generation of models unlocks, that's exactly what a two-week scoping phase answers. This briefing pairs with our notes on agent interoperability standards and on-device models — better reasoning, portable plumbing, and local inference are one story about where automation is heading. Explore the stack or book a consult.