You automated half a job

Most of the AI automation headcount decisions we've been asked to review are, on their own terms, correct. The roles genuinely were automatable. A task that took a person twenty minutes now takes a system twenty seconds, at a fraction of the cost, without fatigue, without backlog, without the quiet degradation of the fortieth repetition before lunch. The savings are not fictional, and the organizations that moved early are not deluded. We help clients do exactly this work, and we would rarely tell one to leave that money on the table.

The trouble is not the arithmetic. It's that the arithmetic is complete on one side of a ledger whose other side has no account. Those roles were doing two jobs — the documented one, and an undocumented, continuous correction of everything upstream that arrived slightly wrong. Only the first was automated. The second wasn't transferred to the system, or reassigned, or retired on purpose. It stopped. And on the day it stopped, nothing happened at all.

Two jobs, one description

Ask what someone in one of these roles actually did on an ordinary Tuesday and the job description covers about half of it. The rest is the part nobody wrote down. They noticed the address was malformed and fixed it before it reached dispatch. They noticed the product code didn't match the description on the same line and rang the branch instead of passing it through. They noticed that this customer had called three times about the same thing, which meant it was no longer a customer problem — something was actually broken — and they told someone. None of it was in the specification, none of it was measured, and all of it was absorbed silently by people who mostly didn't think of it as work. It was just what you did before you could do the task you were given.

Automate the documented task and you capture the documented saving, exactly as modeled. The correction work has no such clean fate. It doesn't move across, because nobody ever specified it, and a system that was never told the address might be wrong has no reason to look.

The error rate was always there

The common misreading of what follows is that the automation introduced errors. It didn't. The rate you are now looking at is the rate your upstream systems have always produced. It was being metabolized — continuously, invisibly, at the last desk before the consequences — by people who fixed it and never reported it, because reporting wasn't the job and fixing took less time than raising it. Automation doesn't raise the error rate. It reveals it. And it reveals it on a lag, at volume, and well downstream of wherever it originated.

This is the general form of an argument we've made narrowly elsewhere: the person at that desk was also quietly bending a bad metric back toward the thing it was meant to approximate, and automation inherits the metric, not the goal. Same removal, different symptom. The system pursues the specification exactly as written, having no idea what it was written to stand in for.

The AI automation headcount ledger

What keeps this from being caught isn't a failure of diligence. It's timing. The saving books immediately. It lands in the quarter the decision was made, in a line with a name attached, defensible in exactly the terms it was promised. The degradation arrives two or three quarters later, and it arrives in a different currency — a slow rise in complaints, a rework queue that keeps growing, disputes taking longer to close, a churn cohort that looks slightly worse than the last one for reasons nobody can pin down.

By then the two entries have no way of meeting. The saving sits in one function's ledger and one quarter's report; the cost is spread across three other functions and shows up as an unexplained trend. Nobody is hiding anything. The cost is simply arriving somewhere the saving cannot be seen from, wearing a different name — a soft market, a demanding season, a support team that needs more people. The most likely explanation is never offered, because the thing that would have to be traced was never recorded. It is a clean example of the evaluation discipline gap: the decision was measured on the way in and never once on the way out.

Loud humans, silent systems

We've made a version of this argument about technology — brittle was a feature, because a system that fails loudly tells you the truth about itself. The same thing holds for organizations, and it is harder to see there because the alarm was never mechanical. It was a few hundred people, distributed across every point where work changed hands, each catching a handful of things a day, each occasionally escalating one — redundantly, inconsistently, and with the considerable advantage that a person who sees the same wrong thing four times gets annoyed and tells someone.

What replaces that is uniform. A system does not get annoyed, and it does not process the fifth malformed record differently from the first. That uniformity is most of the value, and it is also why the failure, when it comes, arrives as a clean trend rather than as a scatter of people complaining. Loud, distributed error-catching becomes silent, consistent processing. The catching was never on the balance sheet. Its absence isn't either.

Measure what arrives wrong

To be fair to the other side: some of that correction work was pure waste. A field that should have been validated at entry years ago, a handoff between two systems that has never once worked cleanly. That work should not have existed, and a person quietly absorbing it every day is how it survived a decade without anyone funding a fix. Automation forcing that fix is a genuine benefit. The problem was never that the correction stopped. It's that nobody knew it was happening, so nobody decided what should happen instead.

Which makes the discipline straightforward, if unglamorous. Before you remove a role, measure two things: what arrives at that desk wrong, and what leaves it right. The delta is the correction work, and it — not the task in the description — is what you are actually removing. Sit with someone for a week and count. It is not a sophisticated exercise, and it is almost never done, because the saving is legible without it and the case is easier to write when nobody has looked.

Then decide, deliberately. Fix it upstream, so what arrives is clean and the correction is genuinely unnecessary. Instrument for it downstream, so that when a malformed record reaches the end of the line something catches it and says so. Or accept it, having priced it, on the view that the errors are rare enough and cheap enough to let through. All three are defensible, and we have recommended each. The fourth option is the one usually taken, and it is the only one that isn't: not knowing, and finding out obliquely, five quarters later, from a number that has already learned to explain itself some other way.

Take the saving. It is real, and the case for it is sound. Just be exact about what you bought. You didn't automate a job — you automated half of one, and the half you kept is the half that was written down.