The Line Item Missing from the Business Case
Every second business case for AI automation contains a sentence in this form: “60 percent of requests will be handled automatically going forward.” Below it a saving, next to it a payback period. The math is usually correct.
It is incomplete all the same, at a point that has no line in the calculation: automation creates a liability that never gets booked anywhere - the loss of the fallback option.
This is not an argument against automation. It is an argument for accounting for a position that is currently missing across the board.
Substitution isn’t symmetric
The core of the problem is unspectacular: the path into automation and the path back out are of different lengths.
Cutting staff takes months. Building staff takes considerably longer - hiring, onboarding, and it is especially noticeable in support, because the actual capital there rarely sits in documentation. It sits in experience: which phrasing in a ticket points to which real problem. Which customer has which history. When to escalate and when not to.
Letting the experienced people go therefore costs you not just capacity, but the ability to train new people. That is the point where a reversible decision turns into one that is hard to reverse. Not immediately - but after twelve to eighteen months, returning to the previous state is no longer expensive, it is no longer possible within the relevant time frame.
That is not a cost risk. It is a continuity risk, and it belongs in a different category with different instruments.
Price is only one of several triggers
Those who consider the point at all usually consider the cost side: what if token prices go up? The concern is legitimate - for some providers it is plausible that current prices sit below full cost, and agentic workflows are disproportionately sensitive to price changes, because they iterate, call tools, and carry context along.
But price is only one path. The same state is also reached through:
- Provider failure or the discontinuation of a model without an equivalent successor.
- Quality regression after an update - the model gets better on average and worse in your specific use case, without a breaking change being noted anywhere.
- Regulatory requirements that prohibit operating in the current form.
- An incident after which nobody internally is willing to take responsibility for unsupervised operation any more.
All five paths end the same way: a substantial share of processing capacity is no longer available, and there is nobody there to absorb it. Anyone hedging only against price increases has covered one path out of five.
It also explains why the usual classification doesn’t hold. When the point does land in the risk register, it typically lands as supplier risk with the standard measure “keep an alternative supplier on hand.” Except that switching to a competitor doesn’t help when an entire industry corrects its prices - and it doesn’t help against the other four paths either.
The more uncomfortable case: training people
Support is a vivid example, but the mechanism is more general. It applies wherever a capability disappears from an organization because it was automated.
It shows most clearly in software development. The tasks that go to agents first today are precisely the ones people used to learn on: small bug fixes, writing tests, reading and understanding existing code, routine changes in unfamiliar modules. That work was never particularly valuable - it was the path along which, over a few years, a junior became someone who can judge architectural decisions.
When that path falls away, no acute problem appears. The seniors are still there, productivity goes up, everything works. The question only comes up later: in five to eight years, where do the people come from who can judge an agent’s output on the merits?
That matters especially because verification is the actual bottleneck in AI-assisted work. Implementation has become cheap; judging whether the result is correct has not. And that judgment capability is not a tool you purchase, it is a headcount that builds up over years - and erodes over years once you shut off the inflow.
The awkward punchline: the bottleneck gets tighter while you optimize it.
Why nobody notices
This decision is rarely made. It emerges.
No board resolves to dismantle its ability to train people or to give up its fallback option. What gets resolved are individual, well-justified optimizations: a position left unfilled, a scaled-back trainee program, a pilot that gets extended because it works. Each step is reasonable on its own and economically defensible.
The effect is strategic all the same, and it never gets assessed as such anywhere - because there is no point at which anyone decides on the sum.
That is a familiar pattern: a decision of strategic reach emerges as a side effect of many operational decisions, each of which was individually right. Those who know the pattern can address it. Those who don’t name it won’t notice it.
What you can actually do
Four measures, none of them costly.
A deliberate floor. A minimum human capacity that does not get optimized away for efficiency reasons. Large enough to preserve experiential knowledge and the ability to train people; small enough not to neutralize the savings. What matters is that it is set explicitly and justified - otherwise it disappears in the next round of cuts, because nobody is defending it.
A rehearsed degraded mode. What happens if the automation is unavailable tomorrow? Longer handling times plus prioritization is a workable answer. Having no answer is the more common one. The difference doesn’t show in the concept, it shows in whether it was ever played through once.
Documentation as a by-product. Cases an agent resolves have to be recorded in a way a human can follow. Otherwise the knowledge migrates into conversation logs nobody reads, and the accumulation of experience that used to happen automatically stops happening.
A break-even factor in the business case. One line: at what multiple of token costs does the use case stop carrying itself? At a factor of 3, the question is settled. At a factor of 1.5 it isn’t a risk position, it is thin economics - and that belongs before the decision, not in a register that gets leafed through quarterly.
For context: the consumption difference between a frugally built and a naively built agentic application is realistically a factor of 3 to 5 - more than most price scenarios can produce. Anyone measuring cost per transaction instead of just looking at the monthly bill already holds the bigger lever.
Where this lands
None of this argues against automation. The efficiency gains are real, and the alternative - waiting until everything is settled - has its own, usually higher, costs.
The point is narrower: a business case that only weighs savings against running costs fails to represent a real position. That position can be quantified, and once it is quantified, the decision doesn’t get harder - it gets more robust. In many cases it comes out exactly as it did before, just with a floor and a degraded mode alongside it.
That is the difference between a risk you take and one you didn’t notice.