Quick path
In this article
Quick read: what changed, why it matters, and what to do next.
A developer on r/AI_Agents posted last week about the job nobody puts in a pitch deck: a client paid him to rip the AI back out of a tool he'd built them. The thread filled with people admitting they had taken the same call.
It looks like failure: you sold the future, now you are billing to delete it. But read the work order as a document and it beats anything the project started with. Nobody pays to remove a feature until they know exactly what it was supposed to do, where it broke, and what they want instead. That is a requirements spec. It just showed up after the build, with an invoice stapled to it.
Which is the whole point. If you would pay to remove the AI, the boring path should have been scoped first, and you can write that removal invoice on purpose before the model goes in instead of paying someone to reverse-engineer it afterward.
What the operators are actually complaining about
The complaint is much narrower than "AI bad." Over on r/automation, the frustration is that people keep forcing AI into jobs ordinary automation already handles: reinventing a wheel that rolled fine, except now it has a few screws loose and a monthly token bill. A builder who made $75K selling AI automations to clients wrote up what he would do differently, and the recurring lesson was not "add more model." It was scope smaller, prove the job, and stop treating AI usage as the outcome.
The pattern underneath those complaints is a fit problem. Somebody put model judgment where a rule belonged. The rule would have been deterministic: same input, same output, every time, traceable when it broke. The model is probabilistic by design, which is exactly what you want when the job needs judgment and exactly what you do not want when the job is "move the field from column A to column B." Erratic output, maintenance drag, and a support queue full of "why did it do that" are the predictable tax on that mismatch.
AI earns its place where a human would have exercised judgment anyway. Where a human would have followed a rule, you wanted the rule.
The AI removal invoice
So borrow the consultant's worst day and run it as a planning exercise. The artifact is a single table you fill out per workflow - not a governance checklist, not an approval queue, just a teardown of what one AI feature was supposed to do versus what it actually needed to be.
| Column | What it captures |
|---|---|
| Original promise | What the AI was sold to do, in the words of the pitch |
| Actual job | What the workflow really needs done, stated plainly |
| Failure symptom | The thing that made someone want it gone - erratic output, cost, latency, "why did it do that" |
| Deterministic replacement | The rule, lookup, template, or integration that does the actual job |
| Residual AI role | What model judgment, if any, survives - usually a smaller, drafting-only slice |
| Owner | The person who maintains the replacement and answers for it |
| Proof | How you know it works - the test, the sample, the receipt |
| Removal cost | What it took to pull the AI out and rebuild - the number that should have been the warning |
The two columns that change how you think are actual job and removal cost. Put the actual job next to the original promise and most of the time the gap is embarrassing: the promise was "an AI assistant that intelligently routes support tickets," the actual job was "send billing questions to the billing inbox." One of those is a model. The other is a rule with three branches that you can read, test, and fix in an afternoon. And the removal cost is the number that retroactively prices the shortcut. If pulling the AI out and shipping the boring version costs a week, that week was always the real budget - you just paid it late, with interest, and with a customer-facing failure in between.

Three lanes, not two
Filling the invoice does not push everything toward deletion. It sorts each workflow into one of three lanes, and the middle one is where most of the value hides.
Keep AI. The actual job genuinely needs judgment: summarizing a messy thread, drafting a reply that has to read like a person wrote it, classifying open-ended input that no rule could enumerate. Here the failure symptom usually is not "wrong," it is "unsupervised." The fix is not removal; it is scope and a receipt. This is the lane where AI becomes plain plumbing rather than a headline feature.
Demote AI. The model does useful work but should not be the last word. Move it to draft-and-review: it proposes, a person approves, and the deterministic system carries out the action. The judgment stays; the autonomy goes. Most "rip it out" jobs are really demotion jobs in disguise, where the model was fine as a first-pass drafter and only failed because it was wired straight to the customer with no human in the loop.
Remove AI. The actual job was a rule all along. Replace it with deterministic automation: a lookup, a template, a webhook, a branch. This is the lane where determinism earns its keep. A step that touches access, money, or another system has to run the same way every time and stay explainable after it runs: same input, same output, a log you can read. That is a strange job to hand a probabilistic model, and it is the first thing you want back when the 2 a.m. page comes.
Why teams overbuilt in the first place
If the fit is so obvious in hindsight, why does anyone wire a model into a three-branch routing rule? Usually because of pressure pointing the wrong way. David Demaree's piece on AI and agency argues that successful adoption runs on clarity, psychological safety, outcomes over outputs, and bottom-up experimentation - and that top-down mandates and token leaderboards tend to backfire through Goodhart's Law. When "did you use AI" becomes the metric, the metric becomes the goal, and people reach for the model to satisfy the scoreboard rather than the job. You end up measuring AI usage instead of outcomes, and overbuilding is what that incentive produces.
The removal invoice is a small antidote because it forces the outcome question back to the front. The actual job column does not care whether you used AI. It cares what the workflow needed. Fill it in honestly and the overbuilt cases out themselves before they ship.
This is the same instinct behind scoping the boring path first - picking the first automation you should not hand to a model, running a shadow week before you automate anything, and doing a weekly workflow audit on your first safe pilot. The invoice is the version you reach for when you skipped those steps and the maintenance drag has already arrived. It works as a pre-mortem just as well as a postmortem - fill it out before the build and the removal cost stays hypothetical.
Run it on one workflow this week
Pick the AI feature that has generated the most "why did it do that" in the last month. Fill the eight rows. Be specific in actual job and honest in removal cost. By the time the table is full, the lane is obvious: keep it where judgment is required, demote it to draft-and-review, or replace it with a rule you can read.
That is what the invoice adds that a normal planning doc usually misses. It prices the cleanup before the cleanup exists. It turns "AI would be cool here" into a more useful question: what would we have to pay someone to undo if we guessed wrong?
If you want a second set of eyes, bring one workflow to a process automation review and we will tell you whether it needs AI, needs automation, or needs removing, plus what the boring path would have cost if you had scoped it first.
Implementation help
Bring one workflow. We will tell you if it needs AI, automation, or removal.
BaristaLabs audits a live workflow against the removal invoice and sorts it into three lanes - keep the model where judgment is required, demote it to draft-and-review, or replace it with deterministic automation you can debug at 2 a.m.
Useful when outputs are erratic, the bill keeps climbing, and nobody can say what the model is actually deciding.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.
Share this post
