Automating the slack

Write down the three problems that, if they moved, would change what your organisation is worth. Then write down everything anyone in the building has pointed AI at over the past twelve months. If your organisation is anything like typical, the two lists will not share a single item. And almost nobody finds that strange.

The standard explanation is capability, and it sounds responsible when spoken aloud. The models are not ready for the hard problems yet. You start with low-risk use cases, prove value, and climb the ladder as the technology matures. Every vendor deck contains a version of this, and most internal AI policies encode it. Start safe, scale later.

But look at what actually made the second list. Meeting summaries. Status updates. First drafts of documents that were only ever going to be skimmed. Boilerplate, formatting, the internal report whose main function is to exist. What these tasks have in common is that they were already delegable. Every one of them would have gone to a junior, a temp or an offshore team years ago if one had been standing around free. The capability story has the causality backwards. The hard problems did not stay human because AI cannot help with them. They stayed human because of what happens to the person holding them when they go wrong.

Delegation has never been sorted by value. It is sorted by survivable error. You hand off the work you can afford to have done badly, and you keep the work where a mistake carries your name. High-value work is high-value partly because errors in it are expensive, and expensive errors need a visible owner. So when AI arrived offering to take tasks off people's hands, everyone quietly ran the same filter they have always run on interns and contractors, and handed over whatever was safe to get wrong. No steering committee decided this. No approval form asks whether a proposed use case sits anywhere near the thing actually constraining the business. The portfolio assembled itself, one individually sensible delegation at a time, and the finished portfolio is a map. Not of what the technology can do. Of what everyone felt they could survive.

What that portfolio does to an organisation has been understood since 1984, when Eliyahu Goldratt published The Goal and built the Theory of Constraints around one observation: a system's throughput is set by its constraint and nowhere else. An hour saved at a non-constraint is a mirage. Nothing the customer experiences gets shorter. And Goldratt pushed past "no benefit". Run your non-constraints at full speed and you actively damage the system, because everything they produce piles up in front of the constraint as inventory. In a factory the pile is visible. It sits on the floor, ties up cash, gets in the way of the forklifts. In an office the pile is documents, drafts, updates, decks and reports: output produced faster than the people who have to act on it can absorb it.

AI then does something stranger than speeding up the non-constraints. It collapses the marginal cost of their output to almost nothing, and cheap production has a well-documented consequence. William Stanley Jevons noticed in 1865 that more efficient steam engines increased Britain's coal consumption rather than reducing it, because making a thing cheaper to use means it gets used more. The Jevons paradox has an exact office equivalent: the document that took a morning now takes a prompt, so there are more documents. Each one lands somewhere. Somebody has to read it, or triage it, or at least decide it can safely be ignored, and that filtering is new work. It appears on nobody's automation list. It resists delegation for exactly the career-risk reasons above, since deciding what can be ignored is judgment, and judgment is owned. And it falls disproportionately on senior people, who are the most likely to be standing at the actual constraint. The bottleneck, meanwhile, is absorbing the exhaust from everything that did get faster.

In Goldratt's language, non-constraints have slack by definition: spare capacity that contributes nothing to throughput. That slack is precisely where the safe tasks live, so the career-risk filter routes AI straight into it, and automating the slack is what most AI programmes have actually consisted of. From the inside, the organisation experiences the sequence as: we adopted AI everywhere, output went up, and everything somehow got slower. A year in, the ambient explanation becomes that AI generates busywork. Which is true, and is also the most efficient possible misreading of what happened. The tool went exactly where it was pointed, and it was pointed, with some precision, away from everything that mattered.

The usual defence is the freed hour. If AI drafts the status update, its author gets an hour back for harder things. But an hour freed at a non-constraint does not become throughput, which is the entire Theory of Constraints in one sentence. Watch what the freed hour is actually spent on, and it is mostly more of the output that just became cheap, because producing is comfortable and the hard problem is still risky. Push on that and the defence moves to patience. Today's models cannot be trusted with the hard problems, so wait for ones that can. But the sorting was never technical. A smarter model does not change whose name is on the failure. Waiting for capability to fix a delegation problem is like waiting for smarter interns to fix your unwillingness to trust interns. The filter lives in the humans, and it does not update on benchmark scores.

Which suggests a different test of AI maturity than the one in circulation. The count of automated tasks and the adoption percentage are tool-shaped numbers, and I have written about what happens when those numbers become goals. The honest test runs the other way: has anyone decomposed the hardest bottleneck into pieces AI can assist with? Decomposition is real work, and it is senior work. It means taking a problem whose whole character is risky judgment, breaking it apart, noticing which parts are actually legwork wearing judgment's clothes (gathering, cross-checking, drafting options, finding the contradiction in two hundred pages), and keeping the sign-off human while pointing AI at the legwork. The risk stays owned. The volume moves. That is the configuration where the technology finally touches throughput, and it is rare because it asks a senior person to spend their scarcest resource, attention at the constraint, on redesign instead of on filtering the flood.

Most organisations are running the opposite programme and calling the length of the second list progress. The maturity test is not how long that list is. It is whether anything from the first list has been broken into pieces small enough to appear on it.