A lot of automation projects go wrong for one simple reason: they try to automate everything. It sounds efficient on paper. In reality it creates more complexity, more edge cases, and more things that can break — and the team ends up babysitting the automation instead of doing the work it replaced. After years of building AI automation into real businesses, the rule I trust most is boring and it works: automate the predictable 80%, and design the other 20% properly. This post is the full argument, with the math that makes it obvious.

What I’ll Cover in This Blog

✔️ Why “automate everything” is the most expensive sentence in AI
✔️ The edge-case tax: what each extra percent of automation actually costs
✔️ What belongs in the 80% — and the one-question test that decides
✔️ What the 20% really is, and why it is a design problem, not a failure
✔️ The symptoms of over-automation, so you can catch it early

Now, let’s dive in! 🔥

The Scenario

Corvane Logistics is a 90-person freight forwarder. Their quoting process is mostly routine: standard lanes, standard cargo, published rates. Last year they automated it end to end — including the weird cases. Oversized cargo, multi-leg routes, customs holds, the client who negotiates every line item: all of it got its own branch in the automation.

Six months later the flow had 41 branches, three people who understood it, and a new full-time job nobody had planned for: investigating what the automation did and why. Quotes for standard lanes went out fast. Quotes for anything unusual went out wrong — confidently, automatically wrong. Sound familiar? Let’s unpack why this keeps happening.

The Edge-Case Tax: Why “Everything” Is So Expensive

Here’s the pattern I see in nearly every over-automated process. The first 80% of the work is genuinely predictable — the same inputs, the same rules, the same outputs, thousands of times. Automating it is cheap, and the payoff is immediate.

Then someone says: “Let’s handle the exceptions too.”

🔹 Every exception is a branch. Each rare case gets its own condition, its own path, its own failure mode. The automation doesn’t get smarter — it gets longer.

🔹 Rare cases are rare. You’re writing and maintaining logic that runs twice a month, and the cost per execution climbs while the payoff shrinks.

🔹 Exceptions interact. Oversized cargo and a customs hold and a negotiated rate is not three branches — it’s a combination nobody coded for, and the automation picks the wrong one silently.

🔹 Complexity compounds. Forty-one branches don’t cost 41 units of maintenance. Every change now has to be tested against every branch, so the cost grows faster than the coverage.

Google’s SRE handbook calls the predictable, repetitive work “toil” — and it’s exactly the work automation is for. But the same handbook is careful about what automation is not for, and that line is the whole game.

What Belongs in the 80%: The One-Question Test

The line between the 80 and the 20 is not a percentage — it’s a property of the work. The test I use on every process step is one question:

Can you write the rule down completely?

If the answer is yes — “when a standard-lane quote request arrives with published rates, generate the quote, attach the terms, send it, log it” — that step is deterministic. It belongs in the automation, it needs no AI at all, and it should run identically every time.

If the answer is no — the rule has a “usually”, an “unless”, or an “it depends” in it — then forcing it into the automation means encoding a guess. And an encoded guess doesn’t look like a guess in production. It looks like a confident, wrong answer.

🔹 Predictable + repetitive + rule-based → the 80%. Intake, routing, record creation, status updates, notifications, standard documents, reconciliations.

🔹 Judgment, interpretation, negotiation, novelty → the 20%. Pricing the exception, approving the unusual, handling the case you’ve never seen.

This is the same classification I run in every implementation — deterministic work to automations, judgment work to agents, decisions to humans — and I covered where it sits in the wider process in The Current State Assessment. The 80/20 rule is that classification applied with discipline.

The 20% Is Not a Failure — It’s a Design Problem

Here’s the reframe that changes how teams build: the messy 20% is not the part you failed to automate. It’s the part you design differently.

At Corvane, the fix was not more branches. We deleted 28 of the 41, and every case that didn’t match a clean rule went to one place: an exception queue, with the full context attached — the request, the customer history, the rate data, and why the automation declined to handle it. A pricing specialist cleared the queue twice a day. Average time per exception dropped from a forty-minute investigation to a two-minute decision, because the system did the preparation and the human did the judgment.

That’s the division of labor that works:

🔹 The automation handles the volume — reliably, identically, silently.
🔹 The automation detects its own limits — “this doesn’t match a rule” is a first-class outcome, not an error.
🔹 The human handles the exception — with everything they need already assembled.

Because the goal was never to remove humans from the process. The goal is a system that works reliably without creating new problems. A human making a fast, informed call on the weird 20% is the system working — and I go deep on how to build that exception path in part two of this pair.

The Symptoms of Over-Automation

You rarely notice over-automation on the day it happens. You notice it weeks later, sideways. The signals I look for in every audit:

✔️ Nobody can explain a decision. “Why did this quote go out at that price?” takes an hour to answer. Explainability died somewhere around branch 30.
✔️ A babysitter role has appeared. Someone’s actual job is now watching the automation — which means the automation created work instead of removing it.
✔️ Exceptions get forced through. The weird case gets mangled to fit a branch, because there’s no path for “this is genuinely unusual.”
✔️ Every change is scary. Touching one rule requires testing forty, so improvements stop shipping.
✔️ Trust is quietly gone. The team double-checks the automation’s output — meaning you’re now paying for the work twice.
✔️ The AI is guessing. Judgment calls were handed to a model without grounding or an approval step — the failure mode I broke down in AI Won’t Fix Your Mess.

Two or more of these, and the answer is almost never “automate harder.” It’s re-drawing the 80/20 line.

Where AI Changes the Line (and Where It Doesn’t)

A fair question: doesn’t modern AI move the line? Can’t an agent handle the “it depends” cases now?

Partly — and precisely. AI extends what you can assist, not what you should fully automate. An agent can read the unusual request, classify it, draft a response, and assemble the decision packet — that’s interpretation, and models are genuinely good at it. What the agent should not do is commit on the 20%: send the negotiated quote, approve the exception, promise the refund. The judgment stays human; the preparation gets dramatically cheaper.

So the modern version of the rule looks like this:

🔹 Deterministic 80% → automation. No AI. Rules, run identically, forever.
🔹 Interpretive middle → AI-assisted. The agent reads, drafts, classifies, and prepares — reviewed where it matters.
🔹 Consequential 20% → human decision. One minute instead of forty, because the system did the homework.

Notice what this doesn’t require: a bigger model. It requires clearer boundaries — the same argument I made in You Don’t Need a Bigger Model.

Conclusion

The 80/20 rule of AI automation, in one breath:

✔️ “Automate everything” is how projects drown — every exception is a branch, and branches compound.
✔️ The one-question test: can you write the rule down completely? Yes → automate. No → design a human path.
✔️ The 20% is a design problem, not a failure — an exception queue with full context beats 28 brittle branches.
✔️ AI extends assistance, not commitment — agents prepare the judgment call; humans make it.
✔️ Watch for the symptoms — babysitter roles, unexplainable decisions, frozen changes, quiet double-checking.
✔️ The goal isn’t removing humans. It’s a system that works reliably without creating new problems.

Automate the predictable 80%. Design the other 20% properly. That’s the whole rule — and part two shows exactly how to build the 20%: Designing Exception Paths and Human-in-the-Loop.

Connect with me on LinkedIn →

Suspect one of your processes is past the healthy line? Send me the one automation your team quietly distrusts — that’s where the audit starts.

What’s one process in your business that’s being over-automated right now? Tell me on LinkedIn — I read every reply.

About the Author — Abubakar Asif