They automated the workaround
Meta description: Standardize the workflow first; only expand AI use when the current level proves faster, better, and still under human control.
The automation project has a success story it tells at town halls: cycle time down double digits, manual touches eliminated, an SLA met for six consecutive months. I have learned to ask about the other number — the exception pile. In these stories, the exceptions grew as fast as the cycle time fell, and a team now quietly reworks what the automation confidently got wrong. The automation did exactly what it was built to do. It was built on the workaround — the lived process, with all its patches — and now the patches run at machine speed, with machine confidence.
In my experience, a company should not rush to automate everything that can be automated. The first step is to establish a workflow that is standardized enough to evaluate. Without that baseline, it is difficult to tell whether AI has improved the process or merely made it faster while weakening quality.
What was automated — the official process or the lived one?
In the postmortems I read, this distinction arrives late. The project documented a process: interviews, a flow diagram, sign-off. What was documented was the process as described in a workshop — the official one, cleaned for presentation. The lived process, the one operators actually run, contains the workarounds: the manual check that catches the known data quirk, the informal escalation, the step everyone skips and one person secretly redoes. The automation encoded the diagram. The diagram was a fiction the workshop agreed on. Nobody automated the work; they automated the story about the work.
Why does cycle time improve while the pile grows?
The tell I trust is the standardized baseline. A repeatable process lets the business compare what happened before and after AI became involved: timing, error rate, review effort, and the end result. A company that has never standardized a task may mistake an impressive AI demonstration for operational readiness.
An agency, for example, might receive a request to produce a large amount of content. An AI-supported draft can reduce preparation time substantially, but the work must still be inspected. If the organization has not defined what acceptable content is, or who is responsible for catching mistakes, the apparent productivity gain can disappear in corrections.
The mechanics are straightforward once seen. Cycle time measures the happy path — cases that flow through untouched. The happy path was always fast; humans were slow at it, the machine is fast, the metric improves. The unhappy path — the cases needing judgment, the edge conditions, the known quirks — now arrives at the exception desk pre-processed and confidently wrong, which takes longer to repair than it took to do by hand. Two queues, two speeds, and the reported metric watches the fast one. The automation did not eliminate the work. It sorted the work into “visible and fast” and “hidden and growing.”
Why does tuning start before anyone redraws the work?
Read more: Miklos Roth.
The false explanation is model quality: the exceptions mean the model needs tuning — more examples, better prompts, a finer model. I have watched tuning rounds consume quarters while the exception rate held, because the exceptions were not model failures. They were process failures the model faithfully inherited: ambiguous inputs that the official process pretended were unambiguous, judgment calls the diagram drew as decisions with rules. Tuning cannot fix these, because they are not in the model. But tuning is the fix the tooling makes purchasable, and redrawing the work requires a harder conversation.
What pattern marks a wrong-process automation?
The marker I look for is who notices first. In a right-process automation, the operators relax — the tedium is gone, the judgment remains. In a wrong-process automation, the operators become the shadow quality department: checking the machine’s work, catching its confident errors, developing an informal list of cases to pull before the automation touches them. When the automation’s most experienced users have built a private system to compensate for it, the automation has encoded the wrong thing. The operators know. The dashboard does not.
Only when the current level has shown a worthwhile result under appropriate review should the business expand. If quality falls, mistakes accumulate, or employees spend more time repairing AI work, the appropriate response is to revise the process. Automation is not the goal. The goal is a better business process that the organization can control and understand.
At our agency, AI has increased our content-production capacity across several areas. But early on we learned what an uninspected exception pile looks like: we sent a client a document of roughly sixty pages after reviewing the first thirty. The second half was poor enough that the client rejected it. Our quality-control process had stopped halfway through. We changed the workflow, reviewed the whole document, and adjusted the instructions and iteration process.
Miklos Roth
What question should have been asked before build?
Every failed version of this story I know has a moment — before the build, before the vendor selection — when the project could have been redirected by a single question about the process itself: not how to automate it, but whether it deserves to exist in its current shape. That question was never asked, because the project’s mandate was automation, and questioning the process would have expanded the scope. Scope discipline protected the timeline and doomed the outcome.
The question that determines whether the scaling is real: have we improved the process itself, or have we merely taught the machine to repeat its weaknesses more quickly?
PR excerpt (80–120 words, Miklos’s own words): A company should not rush to automate everything that can be automated. The first step is to establish a workflow standardized enough to evaluate — without that baseline, it is difficult to tell whether AI has improved the process or merely made it faster while weakening quality. Only when the current level has shown a worthwhile result under appropriate review should the business expand. Automation is not the goal; the goal is a better business process that the organization can control and understand.
