From executor to orchestrator, by design.

The lever was not a better model

For two years the implicit theory of AI value was that the next model would unlock the next tranche of return. Buy access to a stronger model, point it at the same work, and the gain would follow. It mostly did not. The model got materially better every few months and the return on most programmes stayed flat — which is the gap that turned productivity from an HR line into a board metric.

Where the gain did show up, the cause was rarely the model. It was that someone redrew the work. The task that used to be one person doing one thing end to end became a person supervising several agents that each do a slice, in parallel, with the human deciding what to trust, what to escalate and where to set the line. That is a different job, not a faster version of the old one. And when the job changes but the organisation around it does not — same title, same reporting line, same metric — the change has nowhere to land, and the gain leaks back out within a quarter or two.

The model is now a commodity input. The scarce, defensible move of 2026 is redesigning the work around it — and that is an operating-model decision, not a procurement one.

This piece is about that redesign at the level where it actually bites: the unit of work and the person doing it. The org-level build — the artefacts, the governance, the 90-day plan — we cover in the operating-model piece. Here the question is narrower and more concrete: what does the job become, and what has to change around it for the gain to stay.

What the job actually became

The clearest way to see the shift is to put the old shape of the work next to the new one. The executor owned a task and was measured on throughput. The orchestrator owns an outcome and is measured on how much of it clears without a human touching it. Almost every part of the day changes underneath that.

Read down the right-hand column and a thing becomes obvious: the orchestrator's job is mostly about the boundary between "the agent handles this" and "a human handles this", and about keeping that boundary honest as volume and document mix change. That is a real skill, it is not the skill the executor was hired for, and pretending the transition is automatic is the first way the redesign fails.

Why the headline numbers only show up after the redesign

The figures that get quoted in the case studies are real, and they are also conditional. Deploy cycles cut by roughly 70%. Insurance underwriting compressed from 10 weeks to 10 days. Back-office queues that used to carry a multi-day backlog clearing same-day. We have seen versions of all of these. What the headline tends to drop is the precondition: every one of them sits on top of a job that was redrawn, not just a tool that was added.

The mechanism is not subtle. If you drop agents into the old operating model — same role definitions, same hand-offs, same metric — three things happen. The agent does part of the work, so the person finishes faster, so the person is measured as "more productive" on the old KPI. But the freed capacity has nowhere to go, because no one redefined the role to absorb it; the hand-offs are still built for the old sequence, so the agent's output waits in the same queues it always did; and the exceptions the agent escalates land on someone whose job description does not mention exception handling, so they get treated as interruptions rather than the core of the new work. The result is a genuine local speed-up that does not show up in the unit's output, and a board that asks, a few months later, where the gain went.

The redesign is what converts a local speed-up into a unit result. It does three things the tool alone cannot: it redefines the role so the freed capacity is pointed at higher value work on purpose; it re-cuts the hand-offs so the agent's output does not re-enter a queue built for the old flow; and it makes exception handling the named job of a named person, measured as such. None of that is a model capability. All of it is an operating-model decision, which is exactly why the gain correlates with the redesign and not with the model version.

The new unit of work: orchestrated outcomes, not tasks completed

You cannot run the new model on the old metric. "Tasks completed" measures the executor, and once the executor is gone it measures the wrong thing — it counts the human's manual touches, which the redesign is trying to reduce, so a falling number can mean either "we are getting better" or "we are falling behind", and the metric cannot tell you which. The metric that fits the orchestrator is the share of outcomes that clear without a human in the loop, at or above the quality bar.

Concretely, the orchestrator's scorecard is four numbers, and they are the same four whether the outcome is an invoice, a claim or an underwriting file:

• Auto-resolution rate — the share of outcomes that clear straight through, inside the stated quality bar, with no human touch. This is the headline number and the one the redesign is built to move.
• Exception rate and reason — what share escalates to the human, and why, broken down by cause. A flat rate with shifting reasons is a different problem from a rising rate, and the orchestrator needs both.
• Time-to-outcome — wall-clock from arrival to resolved, which is the number the business actually feels and the one that turned 10 weeks into 10 days.
• Quality on the auto-resolved set — sampled accuracy on the outcomes that cleared alone, because an auto-resolution rate without a quality check is just a measure of how much you stopped looking.

The last one matters more than it looks. It is tempting to celebrate a rising auto-resolution rate on its own, but a rate that climbs while quality on the auto-set quietly falls is the redesign failing in the most expensive way — invisibly, until an exception that should have escalated ships and someone downstream finds it. The orchestrator's real job is holding those two numbers in tension: push auto-resolution up, hold quality flat, and let the gap between them be the thing the review actually discusses.

Job redesign, persona by persona

"Redesign the operating model" is the kind of sentence that survives a strategy offsite and dies on contact with an actual org chart. The version that works is granular: you take each agent-augmented persona, name what its day used to be, and name what it becomes — and then you fund the trip between the two.

Two things have to be true for this table to be more than decoration. First, the upskilling has to run in parallel with the automation, not after it — the processor who is about to be measured on exception judgement needs that skill before the agent takes the routine work, not in a training module scheduled for next quarter. Second, the freed capacity needs a named destination. "We saved five hours a week" is not a result until someone decides, on purpose, what those five hours now do. Left unmanaged, freed capacity reliably goes one of two places: it evaporates into recovered slack, or it gets booked as a near-term headcount cut that buys a quarter of margin and a year of attrition and lost institutional knowledge. Neither is the gain the programme was sold on.

Three anti-patterns that keep the gain on a slide

The redesign fails in three recognisable ways. Each one produces a convincing local result and a disappointing unit result, which is exactly why they survive long enough to do damage.

Measuring productivity without changing the operating model. The most common, and the one this whole piece is about. The organisation rolls out agents, measures the per-person speed-up on the old KPI, books it as a win, and changes nothing structural. Six months later the unit's output has not moved, the board asks why, and there is no honest answer — because the gain was real at the desk and never had a path to the P&L. The tell is a deck full of "hours saved" with no line for "capacity reinvested".

Automating first, upskilling later. The agent takes the routine work on Monday; the training to handle what is left — exceptions, threshold calibration, judgement on ambiguous cases — is scheduled for "later". In the gap, the person whose routine work just vanished is now responsible for the hard residue with none of the new skills, the exception queue backs up, quality on the auto-set drifts because no one is calibrating the line, and the early read is "the agent made things worse". The agent did not; the sequencing did.

Orchestration without a kill switch or a budget. A person now supervises several agents running continuously, which is a real shift in what can go wrong: an agent stuck in a loop, a threshold set too loose, a cost line that climbs while no one is watching. The disciplines that make always-on agents safe — a per-agent budget, a kill switch, a defined ground truth for when to stop — are not optional once a human is orchestrating rather than triggering. The orchestrator who cannot stop an agent is not in control of the outcome they are accountable for; they are watching it.

What this means for the document layer

For most enterprises the first place this redesign meets reality is the document desk — the people who process invoices, claims, KYB files, contracts and statements. It is the highest volume, most rules-bound work in the building, which makes it both the best place to start and the place where a botched transition shows up fastest.

The processor becomes an exception handler and a threshold owner. The work that used to be "read the document, key the fields, match it" becomes "review what the agents extracted, decide the cases they flagged, and own where the confidence line sits for this document class". That is the executor-to-orchestrator shift in its most concrete form, and it only works if the platform surfaces a per-field confidence and a clean escalation path rather than a single all-or-nothing answer.

The metric becomes the decision rate, not the page count. "Documents processed" is the executor's number; it counts manual touches and falls when the redesign works, which makes it useless as a target. The orchestrator's number is the share of documents that clear straight through, per class, inside the stated accuracy — held against a sampled quality check on the auto-resolved set. A document platform that can only report volume leaves the orchestrator measuring the wrong thing.

The threshold is only honest if the trail is. Calibrating where the auto / escalate line sits is guesswork unless every extraction and decision carries an audit trail — which input, which model and version, which confidence, which human reviewed it and why. That trail is what lets the orchestrator move the threshold on evidence rather than instinct, and it is the same artefact a regulator will ask for. The redesign and the governance are the same work seen from two angles.

Underneath all three is the same point the multi-agent back-office piece makes from the engineering side: the document layer does not need to be clever for the orchestrator to do their job. It needs to be legible — per-field confidence, a clean exception path, a decision rate per class, and a trail that survives an audit. Give the orchestrator those and the redesign holds; withhold them and the human is back to doing the agent's checking by hand, which is the executor's job with extra steps.

Closing thought

The interesting fact about 2026 is not that agents got capable enough to do real work. It is that the value showed up only where someone was willing to change the work around them — to retire the executor's job, fund the orchestrator's, and swap the metric that measured the first for the one that measures the second. Companies that did the easy half — added the agent, measured the speed-up — booked six months of improvement and a long-term cost in capacity that never landed and people who left. Companies that did the hard half kept the gain, because they built somewhere for it to go.

At Cogneris we build the document layer for the orchestrator, not the executor: per-field confidence and a clean escalation path so a person can own the exceptions instead of redoing the work, a decision rate per class instead of a page count, a unit cost that follows the market down, and a signed audit trail on every extraction so the threshold can move on evidence. If you are redrawing a document workflow around agents and want the gain to survive the next quarterly review, read the operating-model piece for the org-level build, or talk to our team. The agent is the easy part now. The job redesign is the lever.