Cheap Mistakes Go to AI. Expensive Ones Wait.
Routine AI work becomes dangerous when an error passes every control and sits unnoticed. Sort tasks by the thinking they need and the consequence of escape, then measure the checking layer with sampled escape rate and time to detection.
The AI work that burns a service firm is often the routine task that looked safe. A major account complained about service, the message was tagged as billing, and nobody responsible saw it for 11 days. The client then called the consultant directly and canceled.
The delay was not necessarily the only reason, but the missed complaint was a serious control failure. In another system, ten consecutive runs recorded zero failed attempts and 10/10 first-pass technical completion. A review found that one run had skipped a required project and draft. Automation had removed the person who used to notice those gaps.
That is the risk to price: what a wrong output can cost, whether it escapes the controls, and how long it survives. Sort work by the thinking it needs and the worst realistic consequence. Then measure the controls with two numbers: escape rate and time to detection. Cheap mistakes can run. Expensive ones need proof before they leave the system.
Automation removes an accidental control
Before automation, the person doing a routine task also noticed nearby problems. A consultant writing a follow-up might realize that nobody created the promised project. An account manager reading a complaint might see that the client was ready to leave. Those checks rarely appeared in the process. They happened because a person was already looking.
The missed complaint shows what disappears. The client had complained about service, but the message landed in a billing queue. Nobody responsible for the account saw it. Eleven days later, the client called the consultant directly. By the time the thread was opened, the client had asked to cancel and subsequently left.
I cannot say the delay was the only reason the client left. I can say the complaint sat unseen for 11 days and cancellation followed. That was enough to treat the classification as a serious control failure.
Within 24 hours, the rule changed. Cancellation language, threats to leave, and strategic accounts now bypass normal classification. Ordinary billing questions still flow through the same automation. The dangerous exception takes another path.
A green system can still be wrong
The recurring email-to-task workflow from the opening recorded every run as a technical success. An automated reviewer examined three of the ten runs. One had processed an email outside its own time window, skipped a required project, and left no evidence of a requested draft. The other seven runs were never reviewed by anything.
The failed run stayed green because the system measured whether it finished, not whether it produced every promised artifact. Reconciliation now runs after every meeting. It checks that the expected project, tasks, and drafts exist and correspond to commitments from the meeting. A draft does not pass merely because a draft exists. It has to be the promised draft.
A client status update exposed a harder version of the same problem. The creator read a closed task as completed work. The validator checked the update against the task system and approved it. Both matched the source. Then the client replied: “This hasn’t been delivered.”
Task closure is no longer proof of delivery. The workflow now looks for the actual output: a delivered file, sent message, published item, or whatever completion means for that work. Without that artifact, the status stays unresolved.
A 2026 study helps explain why quiet failures survive. Across 720 automated-inspection scenarios, people reported a failure 57.4% of the time. When they did report it, detection took about 43 trials on average. That was factory inspection, not service delivery, so it supports the mechanism rather than giving service firms a benchmark.
Price the failure that escapes
Most operators start with a useful question: can I undo the mistake? Amazon’s one-way and two-way doors make the same distinction in its 2016 shareholder letter. Reversible decisions deserve a lighter process and faster correction.
The test breaks when nobody knows there is anything to undo. The complaint was reversible on each of those 11 days. The firm never got the chance because the message stayed out of sight.
Across the pull-backs I have seen in a franchise network’s delivery data, the price was wrong for one of three reasons:
- The failure was silent. Automation removed the person who had been catching mistakes while doing something else.
- The normal case hid the worst case. A payment reminder usually carries little risk. Send it to a strategic account that already paid, and the relationship matters more than the amount.
- Judgement was hiding inside routine work. “Pull the data and write the status update” still requires someone to decide whether the work was delivered.
These are observed reasons, not a complete list.
The price can also change after automation starts. Meeting summaries began as something to skim after a call. Then people opened the summary instead of the recording. Proposals quoted it, scopes cited it, and the summary became evidence. The task became more dangerous without anyone changing the workflow.
Score the worst realistic consequence, not the average mistake. Score the task again when other work starts relying on its output.
Sort work by thinking and consequence
The first question is what kind of thinking the task needs. Sequoia’s Julien Bek separates intelligence from judgement. Intelligence-heavy work follows rules toward a knowable answer: translating a specification into code, testing, tagging, summarizing, or matching quotes to sources. Judgement-heavy work depends on experience and taste: what to build, what quality can ship, when to say no.
The second question is what the worst realistic error would cost after it escapes the normal controls.
| Lower consequence if a wrong output escapes | Higher consequence if a wrong output escapes | |
|---|---|---|
| Intelligence-heavy | Let it run, then sample it. Internal summaries, tagging, first-pass research, internal drafts. | Require proof before release. Invoices, quotes, client emails, status updates. |
| Judgement-heavy | AI drafts, you choose. Options, shortlists, first passes at a plan. | You decide, AI briefs. Pricing, ending a client relationship, deciding what quality ships. |
The consequence stays with the task. A better validator does not make a false invoice cheap. Better controls lower how often the wrong invoice escapes and how long it survives before somebody catches it. That can justify more autonomy without pretending the underlying risk disappeared.
An earlier piece here uses checkability and undo cost to choose an autonomy level inside one task. Jina Yoon’s autonomy levels at PostHog use the same two tests. This sort happens one step earlier, across the firm’s task list: what thinking does the work need, and what happens if a wrong output gets through?
Better checks earn more autonomy
In the delivery data I watch, tasks moved from human review to agent review as the checking layer improved. Meeting summaries became fully agent-checked. Research review began matching quotes to references automatically. Data analysis moved away from heavy human checking, and competitor analysis and content creation followed the same path.
The strongest implementation is a closed loop with three roles: an orchestrator, a creator agent, and a validator agent. The validator points out mistakes, the creator fixes them, and the cycle repeats until the validator passes the work or an attempt limit stops it.
That loop catches disagreement. It does not catch two agents agreeing with a bad source. The false status update passed because creator and validator both treated task closure as delivery. The repair had to reach outside the loop and demand evidence of the real output.
Attempt limits still tell you something. If a gated task reaches its limit often, either the inputs are broken or the work contains a judgement call nobody wrote down. Fix the input and the task can stay where it is. Find hidden judgement and the AI should prepare the brief rather than make the decision. The rate is a signal, not a standard another firm should copy.
None of this is free. Rework during tuning was estimated from artifacts marked as reworked at as much as 200 man-hours of senior people’s time over six months. That cost was small next to the manual labor removed, but it was real.
Putting a senior person in front of every output is not the answer. At scale, “every deliverable received senior review” either becomes false or turns senior people into proofreaders. High-consequence work needs explicit human signoff or proof. Routine work needs a cheaper way to reveal what escaped.
Audit what the system says is finished
Reported failures cannot tell you the escape rate. They only tell you what somebody noticed.
A random sample of completed outputs is audited every week. Each output is compared with its source material and the real-world outcome. An escape is an incorrect output that passed every normal control before the audit found it. The denominator is the number of outputs checked, not every output the system produced.
Track two numbers:
- Sampled escape rate: escaped incorrect outputs divided by audited outputs.
- Time to detection: how long each escaped error lived before somebody found it.
The first tells you how much wrong work passes the controls in the sample. The second tells you how long that work can keep affecting clients, invoices, projects, or later decisions.
Start with one weekly sample. Compare the output with the original source, then check the thing that happened in the real world. A status update needs evidence of delivery. A meeting follow-up needs the promised project, tasks, and draft. A quote needs the current cost table.
When the audit finds an escape, add the smallest control that would have caught that class of error. Then keep sampling. Normal controls find known failures. Audits look for the ones you have not named yet.
Move one exception at a time
A failed exception does not send the whole task back to a person. It changes the path for that kind of case.
The complaint classifier still handles routine messages, but cancellation language and strategic accounts bypass it. Payment reminders can keep running while top accounts and threshold-crossing amounts receive another check. Status updates can stay automated while delivery requires artifact evidence.
This is how a coarse rule becomes useful production control. The task remains automated. The exception that proved expensive gets a tripwire.
Sort ten tasks this week
Write down ten tasks AI already touches in your firm. For each one, answer five questions:
- Does the task mostly follow rules, or does it require experience and taste?
- What is the worst realistic consequence if a wrong output escapes?
- What artifact or outcome proves the work is complete?
- How long would an error survive before somebody noticed?
- Which completed outputs will you sample each week?
If the honest answer to the fourth question is “until a client tells us,” the task needs a stronger control before it receives more autonomy.
You probably do not have clean numbers yet. Make the first estimate with the person who used to catch the errors, then start the sample. Sorting the ten tasks takes an afternoon. Building the checks takes as long as the work actually requires.
The firm changes as those checks improve. Consultants spend less time copying, formatting, chasing information, and producing routine first drafts. Senior people spend more time resolving ambiguous cases and signing off on decisions with real consequences. Routine AI-assisted execution and work sold with senior judgement or human signoff should not carry the same promise.
Where this stops
This approach assumes the work leaves an artifact that can be checked and a named person owns each gate. A firm running on verbal handoffs and a shared inbox has nothing reliable to compare with the output. The sort may place every task correctly and still change nothing.
A sampled escape rate describes the outputs audited, not every output produced. It reveals risk without pretending to measure what the sample never saw.
While the owner still reads most of what goes out, the firm already has a checking layer, though a slow and expensive one. These measures start mattering when the owner stops reading everything.


