The economics of automation

01What automation is, to an economist

Strip away the technology and automation is one thing: spending capital to replace labor. A machine, a script, a workflow and a model are all capital goods. You pay for them up front and keep paying to run them, and in return a task that used to take hours of someone's attention now takes electricity, license fees and a smaller amount of attention to keep it going. The decision to automate is therefore a capital investment decision, and it should meet the standard any other investment meets: over its life, does it produce more value than it costs, and more than the alternatives?

Put that way, several arguments settle before they start. The real comparison is never "automated versus manual" in the abstract. It is this particular system against this particular use of these particular people. Because labor is scarce and has other uses, automation is really a decision about reallocation, and the question that matters is what the freed hours will be spent on. If nothing changes in how people and money are deployed, then in economic terms the automation has produced nothing.

Faster is not the same as valuable

Three words are used as if they were interchangeable. Efficiency is output per unit of input: a task done in fewer hours, with fewer errors, for less money. Effectiveness asks whether the output was worth producing in the first place. Productivity, as economists use the word, is the value of output per unit of input across the whole business, and of the three it is the only one that reaches the accounts. Automation can make an ineffective task more efficient, which means the company now does the wrong thing faster. Michael Hammer launched the process-reengineering movement on this argument in 1990. Companies had spent heavily on information technology through the 1980s with disappointing results, he wrote, largely because they used it to speed up existing processes instead of questioning them.^[1]

Why ten hours saved is not ten hours of salary

This mistake sits underneath most automation business cases. A workflow saves a coordinator ten hours a week. The coordinator costs 60,000 a year, so the case books a quarter of that, 15,000 a year, as the benefit. The arithmetic is correct and the economics are not, because the coordinator still costs 60,000 a year. Payroll has not moved.

What the company has bought is ten hours of capacity, and capacity is worth whatever it is used for. If the coordinator spends it clearing a backlog that was delaying invoices, it is worth close to the claimed figure. If it disappears into more meetings, it is worth nothing. And if those ten hours were the worst part of the coordinator's week, there may be a retention benefit that no business case will capture.

It helps to separate six kinds of value an automation can produce. Each is measured differently, each arrives on its own timetable, and they are routinely counted twice.

Only the first row is cash in its own right. The others become cash only when management acts on them, which is why a business case that stops at hours saved describes a possibility rather than a forecast.

How automation changes the shape of costs

Automation also changes the cost structure of the work. A manual process has low fixed costs and high variable costs: each extra unit costs about as much as the last, because it takes about as much of someone's time. Automation reverses this. It carries a large fixed cost to build and maintain, and a very small cost for each additional unit.

That is the economic logic of scale, and two consequences of it run through the rest of this paper. First, automation becomes more attractive as more volume passes through it, so the question of when (Chapter 5) matters as much as the question of whether. Second, an automated process can absorb growth without its costs growing in step. For a growing business, that second effect can be worth more than everything else in the case put together, and a case built on today's volume will never show it.

02Why businesses automate

Every automation proposal we have reviewed justifies itself with some combination of the fourteen motivations below. Each is legitimate on its own. The trouble is that they do not add up. The most common failure in a business case is to list six of them for the same process and sum them, when four of the six are the same saved hour seen from different angles.

Three patterns in the table matter more than the rest.

Rows 1, 2, 3, 8 and 9 are usually the same hours. Suppose a process takes 400 hours a month and automation cuts it to 60, freeing 340. Those hours can be counted as a labor saving if they come off the payroll, as productivity if the same people now produce more, as avoided hiring if the company was about to add staff, as better allocation if people move to more valuable work, or as capacity if they are simply free. They can be counted once. Which of these it is depends on what management decides to do with them, and that decision belongs in the business case, not after it.

Error reduction is the most undervalued row, mainly because few companies know what an error costs them. A mispriced quote, a duplicate payment, a wrong shipment, a missed renewal: each has a direct cost someone could estimate and a tail of consequences nobody tracks. In our experience, errors and the rework they cause are the item most likely to turn a marginal case into a clear one, and the item most likely to be missing from the first draft.

Hammer's best-known example shows how large this can be. In the early 1980s Ford's North American accounts payable department employed more than 500 people, and Ford planned to cut that by 20 percent through automation. Then it looked at Mazda, which ran the same function with five. Instead of matching invoices to orders faster, Ford redesigned the process so that it no longer needed the invoice, and most of the matching disappeared with it. Headcount fell by 75 percent.^[1] The matching had existed mainly to catch discrepancies between documents, so the value lay in removing the discrepancies, not in reconciling them more quickly.

Rows 6, 10 and 13 hold the largest returns, and they are the hardest to forecast. Labor savings are capped by the size of the payroll; revenue is not. An automation that cuts quoting time from two days to twenty minutes may win business that was going to a faster competitor, and no study of the quoting team's hours will reveal that. These benefits belong in the business case on a line of their own, marked as uncertain, with the assumption written beside them. Leaving them out because they are hard to estimate is a mistake, and so is inflating them because they are large.

03The cost of doing nothing

Every investment is judged against an alternative. For automation, the alternative that receives the least scrutiny is the one most companies choose: carry on as before. Doing nothing is not free. It is simply a cost nobody has to sign for.

That cost has a recognizable shape. A manual process that was cheap when the company was small does not stay cheap, because it grows in four directions at once:

• With volume. Its cost is variable, so it rises as the business grows, and faster than the business once the process needs coordination: a second person, a handover, a checking step, a spreadsheet to track the spreadsheet.
• With wages. Labor costs rise on their own, and the people who have mastered an undocumented process become steadily harder and more expensive to replace.
• With errors. Mistakes multiply with volume, and each one costs more as the business grows, since a wrong shipment to a large customer is a bigger problem than one to a small customer.
• With delay. Queues form, cycle times stretch, and the people waiting on the output invent workarounds that carry costs of their own.

Eventually the process becomes a constraint on the whole business, and the company hires into it, slows down, or both.

The most useful way to see this is as opportunity cost: not what the manual process costs, but what the company gives up while its people and attention are tied up in it. A founder who spends Friday afternoons on invoicing costs the company far more than a few hours of salary; the real cost is the sales call, the hire or the product decision that did not happen. A sales team that spends a third of its week on data entry has lost a third of its selling capacity. None of this appears in any system, which is why it is so often discovered only after an automation ships, when the freed time turns out to be worth far more than the case assumed.

Growth moves the numbers quietly

Take a company that processes 300 customer orders a month by hand, at ten minutes each. That is 50 hours a month, a fraction of one person's time, and hard to justify spending anything on. At 3,000 orders it is 500 hours: three people, and a process nobody designed that lives in their heads and falls over whenever one of them is on holiday. The arithmetic never changed. The volume did, and nothing in the monthly reporting was set up to notice when it crossed the line. Most companies learn that a manual process has become expensive when it breaks, which is the most expensive way to learn it.

Competition adds a slower cost. If a competitor automates and you do not, the gap never shows up as a line item. It shows up as the competitor quoting faster, onboarding faster and pricing lower, and as margins that move in ways nobody can quite explain. The historical record is consistent on this point. The firms that got large productivity gains from information technology were not the ones that spent the most on it but the ones that reorganized around it, and the gap between them and everyone else widened over years rather than quarters.^[2]

Not every manual process is a problem waiting to happen

This argument needs care, because the opposite mistake is just as costly. Plenty of processes are manual because manual is the right answer. They are low in volume or high in judgment, they change every quarter, or doing them by hand is cheap and will stay cheap. A process one competent person handles in two hours a week is not a crisis, and it does not become one because an automation vendor has noticed it.

Estimate the cost of doing nothing the way you would estimate any other cost, from volume, growth, error rates and the real alternative use of the time. If the numbers are small, leave the process alone and look again in a year. Inaction is not always expensive. It does always have a cost, though, and that cost should be estimated rather than assumed to be zero, on the same page as the cost of acting.

04What to automate

The folk rule says to automate the repetitive tasks. It is wrong often enough to be dangerous. Repetition is one of about a dozen properties that decide whether a task is a good candidate, and on its own it says very little. A task done a thousand times a month, with stable rules and cheap mistakes, is an excellent candidate. A task done ten times a month whose mistakes cost tens of thousands may be a better one. A task done a thousand times a month that needs a judgment call every time, where the judgment is the whole point, may be the worst candidate on the list, however repetitive it looks from a distance.

The properties that matter fall into three groups: how much a task is worth automating, how feasible it is to automate well, and how much it would cost to try.

The most careful published work on these conditions is still Lacity and Willcocks's case studies of early robotic process automation (RPA). They found the technology worked best where volume, standardization, clear rules and process maturity were all high, and that the disappointments came where those conditions had been assumed rather than checked. Their Telefónica O2 case shows the upside when the conditions do hold. By 2015 the company had automated fifteen back-office processes handling 400,000 to 500,000 transactions a month, and reported a three-year return of 650 to 800 percent. That figure is self-reported and comes from vendor-sponsored research, so it should be read with caution, but it explains why the category exists.^[3]

Two properties in the table are skipped more often than the others, and either one can sink a case on its own.

The exception rate decides the economics more often than any other single number. An automation handles the cases that fit its rules and sends the rest to a person. If one case in a hundred is an exception, the automation covers 99 percent of the work, and the exceptions can be dealt with slowly, by hand. If one case in five is an exception, the automation still covers 80 percent of the volume, but the exception path now needs its own design, staff and tools. And the people working it no longer have the context they used to build up by handling the easy cases.

Judgment is the second. Many tasks that look repetitive are a thin layer of execution over a thick layer of decision. A credit controller who sends fifty reminder emails a week is not doing one task fifty times. The controller is deciding, fifty times, whether this customer needs a reminder, a phone call, a hold on the account or a word with the sales rep who owns the relationship. Automating the email is easy. Automating the decision is a different project with a different risk profile. A business case that confuses the two will automate the sending, keep the person for the deciding, and save almost nothing.

A scoring model, with its limits stated

When there are many candidates, a simple score helps with triage. Rate each one from 1 to 5 on four questions. How much is at stake, in hours and error cost combined? How standard and predictable is the work? How free is it of exceptions and judgment? How simple would it be to implement? Multiply the first score by the sum of the other three. The result ranks candidates well enough to decide which five deserve a proper analysis this quarter and which twenty do not.

Then put the score aside. It is a triage tool, not a financial analysis. It cannot tell you whether a candidate is worth 20,000 or 200,000, what the automation will cost to maintain, or whether the freed hours will ever become cash. The candidates at the top of the list get the full analysis described in Chapter 6. The score only decides who joins the queue.

05When to automate

The same automation can be a mistake at one scale and the best investment the company makes at another. This follows from the cost structure described in Chapter 1. Automation trades variable cost for fixed cost, and a fixed cost is only worth paying when enough volume passes over it to spread it thin. Somewhere there is a volume at which the automated process becomes as cheap per unit as the manual one. That is its break-even volume, and Chapter 6 shows how to calculate it. The timing question is where the process sits relative to that point today, and which way it is moving.

Too early

Automating too early has three costs. The first is obvious: the fixed cost is paid before the volume exists, so the company has bought capacity it does not use.

The second is less obvious. A process automated early is a process frozen early. Young companies change their processes constantly, because they are still learning what the process should be, and every change to an automated process costs engineering time that a change to a manual one does not. A five-person company that automates its onboarding has not saved anyone time. It has built a system that needs changing whenever the company learns something new about onboarding, which at that stage happens every month.

The third cost is the value of waiting, which an early investment gives up. Dixit and Pindyck's work on investment under uncertainty formalized what good managers already knew: when an investment is irreversible and the future uncertain, the option to wait has a value of its own, and investing now spends it.^[4] A year's delay buys a year's knowledge about volume, about what the process really needs to do, and about what the tools cost. When tooling prices are falling, that knowledge can be worth more than a year of savings.

Too late

Automating too late is the more common error and the more expensive one, because its costs stay invisible until they suddenly are not. By then the manual process has been scaled by hiring. There is a team whose jobs are the process, so the automation has become an organizational problem as well as a technical one. The process has accumulated undocumented exceptions, workarounds and tribal knowledge, each of which has to be found and then either automated or removed. Errors have been happening at volume for years. And on every unit since volume passed break-even, the company has paid more for the manual process than the automated one would have cost, a gap that widens as volume grows.

The longer an organization is built around the old way of working, the more there is to take apart before the new way pays. Paul David's history of factory electrification is the classic account. Electric dynamos were on the market in the 1880s, yet electricity did not lift measured productivity in American manufacturing until the 1920s. Factories laid out around a steam engine and its drive shafts could not simply bolt on electric motors and collect the gain. The gain came when factories were redesigned around the new power source, and that took a generation.^[5]

Why size is the wrong variable

Headcount is a poor guide to readiness, because what matters is the volume through a specific process, not the size of the company around it. A five-person online store shipping two thousand orders a day has more reason to automate fulfillment than a hundred-person consultancy sending twenty invoices a month. It is the process, not the company, that has to reach scale. The signs that it has are concrete:

• The process has a stable definition. It has been done the same way long enough that its exceptions are known and listed, not still being discovered.
• Volume is measured and rising, and a plausible forecast puts it well above today's level within the life of the automation.
• The next step would otherwise be a hire, and that person would be doing the process, not improving it.
• Errors are being caught, and someone has estimated what they cost.
• Someone owns the process and would own the automation. Not a department: a named person.
• The tools have been around long enough for other companies to have paid for the learning curve. Wright observed in 1936 that the unit cost of building an airplane fell by a roughly constant percentage each time cumulative output doubled.^[6] A 2013 study of 62 technologies found that his rule forecast their costs better than any of the five alternatives it tested.^[7] A company that waits for a tool to mature buys further down that curve, and inherits the integrations, documentation and lessons that earlier adopters paid for.

When most of these are true, the cost of waiting has overtaken the value of waiting, and the question moves from whether to how.

06Building the business case

An automation is a capital investment and should be analyzed as one. Nearly everyone agrees with that sentence, and few act on it. The people who propose automations are usually operational or technical, the tools for judging capital investments live in finance, and the two groups mostly meet at budget time. This chapter sets out the minimum analysis, in the order a CFO would expect to see it, and then runs two cases through it.

Total cost of ownership

The first number is what the automation will cost over its whole life, and the first draft of that number is always too low, because it counts only the items with a price tag. Licenses, development and implementation are visible. Most of the money goes on the rest of the list.

The evidence on how far first estimates miss is uncomfortable. Flyvbjerg and Budzier studied 1,471 IT projects and found an average cost overrun of 27 percent. That sounds manageable until you look at the tail: one project in six was a black swan, overrunning its budget by an average of 200 percent and its schedule by almost 70 percent.^[8] A McKinsey and Oxford study of large IT projects found them running, on average, 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.^[9]

Those are large projects, and a workflow automation is not an ERP rollout. The tail is real at every scale, though. When Revlon switched on a new ERP system at its plant in Oxford, North Carolina, in February 2018, it could not make or ship enough product to fill retailers' orders, and the company later disclosed a material weakness in its financial controls. Its annual report estimated the lost net sales for the year at about 64 million dollars, and recorded a further 53.6 million dollars of charges, mainly for restoring customer service.^[10] Estimates miss in the same direction whatever the size of the project, and Flyvbjerg's remedy works at any size too: do not rely on the inside view of the people who want to build the thing. Ask what similar projects actually cost.

The five calculations

Return on investment is net benefit divided by total cost over the same period, expressed as a percentage. It is the number everyone asks for and the least informative of the five, because it ignores time. An automation that returns 150 percent over three years and one that returns 150 percent over eight are very different investments. Always state the period, and always say whether the benefits are cash or capacity.

Payback period is the time it takes for cumulative benefits to catch up with cumulative costs. Operational leaders find it the most intuitive of the five, and it has a real virtue: it measures risk. Everything before payback is exposure, and everything after it is upside. Be suspicious of any automation with a payback beyond two years. It may still be a good investment, but two years is roughly how long the assumptions behind it take to go stale.

Net present value reflects the fact that money received in three years is worth less than money received today. It discounts each year's net cash flow at the company's cost of capital and adds them up. It is the right measure when the automation has a long life, when the benefits arrive late, or when two options differ in timing. The CFO already has the discount rate; use it.

Internal rate of return is the discount rate at which NPV is zero, in effect the return the investment earns on its own terms. It is useful when a company has a hurdle rate and many projects competing for the same funds. It adds nothing to the case for a 40,000 workflow automation that pays back in nine months, and if a case needs an IRR to be persuasive, that is worth noticing.

Break-even asks a different question: not whether the automation pays at the forecast volume, but at what volume it starts to pay. For a growing company it is often the most useful number of all, because it turns the decision into something you can watch. If an automation breaks even at 1,800 invoices a month, and the company processes 1,200 today and expects 2,500 in eighteen months, the question is no longer about the automation. It is whether you believe the forecast.

Sensitivity analysis is less a sixth calculation than a discipline applied to the other five. Move each assumption by a plausible amount and see which ones change the answer. In our experience, the assumptions that move automation cases most are, in order: whether freed hours become cash, the exception rate, the ongoing maintenance effort, and adoption. Volume and license cost get most of the attention and usually matter less.

Case A: an invoice automation that pays

A distributor receives 3,000 supplier invoices a month. Three accounts payable clerks key them in, match them to purchase orders and chase discrepancies. Measured rather than estimated, each invoice takes ten minutes on average: 500 hours a month at a fully loaded cost of 38 an hour, or 228,000 a year, which works out at a little over 6 per invoice. The ERP already has an intake module, and the proposal is to add a document capture service, configure three-way matching and send exceptions to a queue.

Now comes the question that decides the case: what happens to the 410 hours? Here the answer is specific. Two of the three clerks retire within the year and will not be replaced. That turns 320 of the freed hours into a cash saving of 120,000 a year, which counts their pay and payroll costs but not the overheads in the loaded rate, since those stay with the company. The third clerk takes over exceptions, supplier queries and an early-payment discount program nobody previously had time to run. Finance estimates, conservatively, that capturing discounts on the 60 percent of eligible invoices the company currently misses is worth 35,000 a year. The remaining capacity is valued at zero. At steady state the cash benefit is 155,000 a year, reached after a six-month ramp, so year one delivers 70 percent of it.

Three-year ROI is 226,500 divided by 192,000, or 118 percent. Payback comes just inside twelve months, and NPV at a 10 percent discount rate is about 170,000. The case survives a worse straight-through rate, too: even at 50 percent, the freed hours still cover the two retirements. And the assumptions sit comfortably within published benchmarks. Ardent Partners' 2025 accounts payable study puts the average all-in cost of processing an invoice at 9.40, with the best-performing fifth of organizations at 2.78 and the rest at 12.88, and reports an average exception rate of 14 percent.^[11] The distributor's starting cost of about 6 per invoice is unremarkable, and the 20 percent exception rate assumed here is worse than average, which is the safer direction to err in.

One assumption, though, would break the case: the retirements. Suppose the company kept all three clerks and simply let them work at a gentler pace. The cash benefit would fall to the 35,000 from discounts, against 44,000 a year of running costs, and the automation would lose money in every year it ran. Same technology, same hours saved, opposite result. The difference is a management decision, and it has to be made before the project is approved, not after.

Case B: a lead-routing automation that only looks good

A software company has six sales development representatives (SDRs). Part of their week goes on admin for each inbound lead: looking up the company, checking the CRM for existing contacts, assigning an owner and logging the result. A survey of the team says this takes each of them 15 hours a week. At a loaded cost of 45 an hour, that is 210,000 a year of SDR time spent on administration. A custom automation connecting the web form, an enrichment API, the CRM and the email system is quoted at 45,000. The case writes itself: 210,000 a year saved, and the build paid back in under three months.

The first draft left a good deal out.

Rework the numbers with what the scrutiny found. Measured over two weeks, the task took 8 hours a week per SDR, not 15. At four minutes a lead, that is about 120 leads a week each. The automation handles 82 percent of them cleanly. The other 18 percent, about 22 a week, now take eight minutes each, because the SDR picks them up cold. Net, each SDR gets back about 5 hours a week, roughly 1,400 hours a year across the team, which at 45 an hour is 63,000 of capacity.

But no SDR leaves and no hire is avoided. The company has six SDRs after the automation, as it did before. The cash saving is zero, and the running cost is 45,000 a year. Against that sits a real but unmeasured benefit from contacting leads faster. It may be worth a great deal or nothing at all, and nobody can tell without a controlled test, which the company has not designed.

On a cash basis the project loses 180,000 over three years. On a capacity basis it frees 189,000 worth of SDR time, which is worth something only if those hours become pipeline and the pipeline becomes revenue. A truthful business case says so in as many words. This automation is a bet that five more selling hours per SDR per week will produce enough extra gross margin to cover the build and the running costs, about 60,000 a year over three years, and here is how we will measure whether it does. That may be a bet worth taking. It is not a three-month payback.

It is worth noticing what would have changed the answer. At three times the lead volume, the team would have had to hire just to keep up with the admin, so the automation would avoid a hire, and that is cash. An off-the-shelf CRM feature instead of a custom build would shrink the maintenance line to almost nothing. A decision to reduce the team by one SDR and redraw the territories would turn the capacity into cash. Each of these is a different project, and the analysis is what shows which one the company is actually choosing.

07Simplify before you automate

The most reliable way to lose money on automation is to automate a process that should have been fixed first. A badly designed process, once automated, is a badly designed process that runs faster, fails in bulk and costs engineering time to change. Hammer's 1990 article put the argument in its title: don't automate, obliterate. His reasoning was economic. The technology of the day was being used to make existing work faster, when its real value lay in making some of that work unnecessary.^[1] Thirty-five years and far better technology later, the mistake has not changed.

So this is the order we work in. First, eliminate the work that does not need to exist. Then simplify what remains. Then standardize it, so it is done one way. Only then ask whether to automate it. Each step shrinks the scope, cost and risk of the next, and the project can rightly end at any of them. We once watched a six-figure automation proposal evaporate in a one-hour workshop, when it emerged that nobody read the report it was meant to generate. That hour was the best-returning automation work the company did all year.

The ladder of solutions

Any business problem that reaches an automation discussion has a ladder of possible responses, and cost and risk both rise with each rung.

The rule is to stop at the lowest rung that solves the problem to the standard the business actually needs. This is not caution for its own sake. Every rung above the lowest sufficient one adds cost without adding value, and much of that cost takes a form that is easy to underestimate: complexity. A workflow that connects five systems has five ways to break whenever one of them changes, and the people who understand all five are few and expensive.

Sculley and colleagues at Google described this for machine learning systems in 2015, and their point applies well beyond them. The model, or the rule, is a small box in the middle of the diagram. The plumbing around it (data, configuration, monitoring, glue code) is where the cost and the fragility live.^[12] The RPA wave produced its own version. A 2020 survey of 271 enterprises running software bots found that 45 percent dealt with broken bots weekly or more often, mostly because the applications the bots worked through had changed. The survey was paid for by a vendor with a product to sell, which is a reason to discount the number but not the mechanism.^[13] Technical debt is a liability with a real interest rate, and automation projects are among the fastest ways a business can take it on.

Standardization comes first

An automation encodes one way of doing a task. If three people currently do the task three different ways, the automation will encode one of them. The other two people will adopt it, work around it, or quietly carry on their own way and treat its output as one more input. We have seen all three. Only the first delivers the forecast value, and it depends on agreeing the one way before anything is built, which is a management job rather than an engineering one.

The early practitioners said so plainly. "Don't automate a process that's not ready to be automated. Stabilise it first," Paul Donaldson of Xchanging, one of the first large RPA adopters, told the LSE researchers.^[14] When a process cannot be standardized because the variation is genuine, because each case really does need a different approach, that is a finding in its own right: the process is not ready for automation yet.

When manual is cheaper

Finally, some processes are simply better done by hand, and a company that cannot say so has lost the ability to make the decision at all. Four situations come up again and again:

• Low volume, high variety. Twenty bespoke contracts a year do not justify a contract-generation system.
• Constant change. A process that changes every quarter will keep its automation in permanent repair.
• Learning on the job. When the person doing the work is learning something the business needs, as founders do when they handle early customer support, the manual work is the point.
• Errors that people catch. Where a mistake is expensive and the people doing the work catch mistakes an automated process would let through, the manual step is doing a job that is easy to overlook.

Toyota's production system has a name for the idea underneath this: jidoka, which Toyota translates as automation with a human touch. A machine stops itself when something is abnormal so that a person can look, instead of carrying on and producing defects at speed.^[15] The principle is older than computing, and it is the right instinct for a great deal of office automation. The aim is to put people's attention where it is needed, which is a different goal from removing them.

08How AI automation differs

Traditional automation follows instructions. Someone writes down the rules, the conditions and the steps, and the system carries them out exactly, every time, for as long as the inputs look the way the rules expect. If an invoice arrives from this supplier, save the attachment to that folder. If a form is submitted, create a record. If an invoice is seven days overdue, send the reminder. The system has no idea what an invoice is. It matches the patterns it was told to match and does what it was told to do, and its great virtue is that it does so with perfect consistency at almost no cost per run.

AI automation, in the sense that matters here, is automation in which a model performs a step that used to need a person to read, interpret, classify or write. Read this customer email and work out what the customer wants. Pull the invoice number, amount and due date out of a document, whatever layout the supplier used. Sort these support conversations by what they are about rather than by which words they contain. Draft a reply based on the conversation so far. Look across three systems and suggest what to do next. Rules cannot do these tasks, or cannot do them well. The model copes with ambiguity that whoever wrote the rules could not foresee, and that is the reason to use it.

The two have different economic signatures.

The last row matters most. A rule fails in ways you can predict; a model fails in ways you have to measure, and silent failure is not a rare edge case. One widely used leaderboard scores models on whether their summaries stay faithful to the source document. In late 2026 its measured rates of unsupported content ran from under 2 percent to over 20 percent depending on the model, with most frontier models between 7 and 14 percent, as judged by the leaderboard's own scoring model.^[16] Summarization is only one task, but no business would accept error rates like these from any other system without checking them. The flexibility is why AI opens up work that could never be automated before. The unpredictability is why it needs a different kind of economic analysis, which is the subject of Chapter 10.

One point is worth carrying through the rest of this part. AI does not make every automation better. It makes some automations possible that were previously impossible or impractical, and for everything else it is a more expensive, less predictable way of doing what a rule already does.

09What AI makes newly possible

For sixty years, the frontier of office automation was the structure of the input. If information arrived as fields in a database, a machine could process it. If it arrived as language, as a document in an unpredictable layout, as a judgment that depended on context, or as facts scattered across systems with no common key, it needed a person. The economist David Autor described this boundary in 2015 through Polanyi's paradox, the observation that we know more than we can tell. The tasks that resisted automation were the ones whose rules nobody could write down.^[17] Large language models have moved that boundary without removing it. Machines are now tolerably good at a large class of tasks whose rules nobody could spell out.

The result is a new tier of candidate processes, and most of them share a profile: high volume, unstructured input, low to moderate stakes per item, and a person currently doing the reading. By function, they look like this:

Nothing in this table is speculative. All of it is running in production somewhere, mostly in companies that would not describe themselves as advanced. The useful question for a leadership team is not whether these things are possible but which of them, in this company, pass the tests in Chapters 4 to 6.

Four degrees of involvement, four different investments

"AI automation" covers four quite different arrangements, and their economics differ enough that they should never share a business case.

AI assisting an employee. The person does the task. The model drafts, suggests, summarizes or searches, and the person decides what to use. The investment is a license and some training, and the risk is low, because a human reviews everything. The return is a real productivity gain that is hard to see on a P&L. The best evidence on this mode comes from a study of 5,179 customer support agents at a software company. A staggered rollout of a generative AI assistant raised the number of issues resolved per hour by about 14 percent on average, and by about 34 percent for the least experienced agents, with little or no gain for the most experienced. Customer sentiment improved and staff turnover fell.^[18] Several other studies have found the same pattern of large gains for novices and small ones for experts, and it should shape where assistance goes first.

AI augmenting a process. The process stays as it is, but one step inside it is handed to a model: extraction, classification, a draft. A person still owns the outcome and checks the model's work, usually only by exception. The investment is integration and evaluation, the running cost is metered, and the return can be measured, because the step had one cost before and has another after.

AI automating a workflow. In the normal case, the model's output is acted on with no person in the loop, and people see only exceptions and samples. This is where the labor economics of Part I apply in full. It is also where the error rate stops being a quality concern and becomes a cost line, because every wrong output now does something.

AI agents operating across systems. The model decides what to do next, calls tools, takes actions in several systems and keeps going for many steps. The potential leverage is the highest of the four, and so is every other number: the integration cost, the evaluation burden, the damage a single error can do, and the difficulty of knowing what the system did and why. We have written a separate note on how much autonomy to give such a system, action by action.^[19] In short, the economics of agents are the economics of automation with a large and uncertain error term, and the business case has to be built around that term rather than around the model's capability.

10The hidden costs of AI

AI is not free automation. It is automation with a different cost structure, and first-draft business cases tend to go wrong precisely where the structure differs. Three differences stand out.

• It is metered. Every model call uses tokens, and tokens are billed. Scale a workflow to ten times the volume and its model bill scales with it.
• The prototype is cheap; production is not. The prototype needed no evaluation, monitoring, retries, fallbacks, access control or audit logs, and no plan for the day the vendor changes the model. Production needs all of them.
• It is sometimes wrong in ways that are hard to spot, so the cost of the system has to include the cost of catching and fixing its mistakes.

These are the lines most often missing from the budget, grouped by when they arrive:

Cost per successful task, not cost per call

The most important single correction to an AI business case is to replace cost per call with cost per successful task. A model call costing a fraction of a cent is not the unit of analysis. The unit is a task completed to the standard the business needs, and its cost includes the calls that produced wrong answers, the work of noticing they were wrong, and the person who fixed them.

A simple example shows why. A system processes 1,000 documents a month, and the model costs 0.05 per document, so the model bill is 50. But 15 percent of the outputs need a person to correct them. Each correction takes six minutes at 40 an hour, or 4 per document, so the 150 corrections cost 600. The system really costs 650 a month, of which the model is 8 percent, and each successfully processed document costs 0.65: thirteen times the figure on the vendor's pricing page.

Now suppose a stricter evaluation finds that another 5 percent of outputs were wrong and nobody noticed. Those errors have a downstream cost, and it is larger than the cost of correction, because someone acted on them. None of this means AI is expensive. It means the model price is rarely the number that matters, and the error rate almost always is.

It is also why a workflow that shone in the demo can fail economically in production. The demo ran on twenty examples chosen by someone who wanted it to work; production runs on everything, including the cases nobody chose. Dell'Acqua and colleagues gave this a name in a 2023 field experiment with 758 consultants at Boston Consulting Group: the jagged frontier. On tasks inside the model's capability, consultants using it completed 12.2 percent more tasks, 25.1 percent faster, and the original working paper rated the quality of their work about 40 percent higher. On a task chosen to sit just outside that capability, consultants using the model were 19 percentage points less likely to reach the right answer than those working without it.^[20] The frontier is invisible from the outside. The only way to find where it runs for your task is to measure, and measurement is the evaluation cost the demo skipped.

Two more properties belong in the cost model. The first is that reliability compounds. A ten-step workflow in which each step is 95 percent reliable completes correctly only about 60 percent of the time, and recent research on long tasks finds that a model's per-step accuracy itself falls as the task grows longer, partly because the model builds on its own earlier mistakes.^[21] The second is that reliability drifts. The same prompt sent to the same vendor's model months apart can behave differently, as a 2023 study of ChatGPT's behavior over time showed in some well-publicized and contested examples.^[22] Whatever you make of the specific numbers, the operational lesson holds: an AI automation needs a standing evaluation, re-run every time the model changes, and that is a recurring cost rather than a one-off.

A worked comparison: rules against a model

A support team receives 20,000 emails a month, and each one has to be routed to one of twelve queues. There are two options.

Option A is a rule-based router that uses keyword rules plus the category the customer chose on the web form. It routes 72 percent of emails and sends the other 28 percent to a general queue, where a coordinator triages them by hand at 30 seconds each. Because the rules are conservative, few of the emails they route go to the wrong place, though each misroute costs an agent about three minutes to redirect. We assume misroutes come to 3 percent of all email.

Option B is a language model classifier that reads the email and the form. On the evaluation set it routes 93 percent correctly, and the other 7 percent are misrouted rather than queued, because the model always gives an answer. At current list prices for a small model, each email costs about a hundredth of a cent, which at this volume is a rounding error; a frontier model would cost about twenty times as much and still come in under 40 a month.^[23] Option B also needs an evaluation set, a monthly re-check and part of an engineer's attention.

The last row divides each total by the emails that reach the right queue at the first attempt. On these assumptions the model costs about a quarter more per month than the rules. Its great advantage, a near-zero price per email, is more than eaten up by the cost of its confident mistakes.

One number missing from the table could still decide the case: what a misroute costs the customer. If a misrouted email is answered a day late and that hurts retention, the model's extra misroutes are expensive and Option A's lead widens. If a misroute costs nothing beyond the agent's three minutes, the table is the whole story, and A wins by about 900 a month while also being the simpler system to run.

Now let the model abstain when it is unsure, sending its least certain 10 percent to the coordinator instead of guessing. Option B's misroutes fall to perhaps 2 percent, the correction line drops to 800, triaging the abstentions adds about 670, and the total falls to roughly 3,170, or 0.16 per correctly routed email. Now B wins clearly, on cost and on misroutes. That last design is the one we would build, and the reason for it only shows up in the arithmetic. The model earns its place by handling the 28 percent the rules could not, while admitting what it does not know. Replacing the rules was never where its value lay.

The table holds one more lesson: change the input. If the web form had a well-designed category field that customers actually used, Option A would route 90 percent of emails instead of 72, its triage cost would fall by about two thirds, and no model would be needed. The cheapest AI project is often a better form.

11When AI is worth it

The ladder from Chapter 7 can now be filled in at the top. A problem that reaches the AI discussion has seven possible responses, and the right one is the lowest that meets the standard.

AI earns its place on the ladder when several of these are true at once:

• The inputs are unstructured: documents, emails, conversations, free text.
• The task needs context, because the same words mean different things in different cases.
• The rules are hard or impossible to write in advance, or there would be so many that maintaining them would become a job of its own.
• The person doing the work is expensive, or the work is a poor use of an expensive person.
• Volume is high enough that the model's metered cost is small next to the labor it replaces.
• A faster decision is worth something: a quote in minutes rather than days, a claim triaged on arrival rather than the next morning.

It does not earn its place when:

• The inputs are already structured and the rules are clear.
• Software you already own has the feature, or a simple conditional workflow would do.
• Volume is too low to cover the cost of evaluation and monitoring.
• An error would be costly enough that the review needed to catch it costs more than doing the task by hand.

That last case is the one most often argued away, and it should not be. Mistakes in customer-facing or financially consequential output carry a cost no token price reflects. Air Canada found this out when a tribunal ordered it to compensate a passenger who had relied on its chatbot's incorrect account of the airline's bereavement-fare policy.^[24]

The principle for this part, then: do not use AI when a simpler, cheaper, more reliable solution delivers the same business outcome. The important word in that sentence is reliable. A rule that is right every time on the cases it handles, and stops on the rest, is a different kind of asset from a model that is right 93 percent of the time on everything, and the difference is worth money.

Overbuying capability

One failure mode deserves its own name: paying for capability the business has no economic use for. It is the AI equivalent of a factory buying a machine three times the size it needs, and the symptoms are easy to recognize:

• A top-tier model chosen where a small one would do, at ten or twenty times the usage cost. When Princeton researchers re-ran published agent designs on the same coding benchmark, they found costs differing by almost two orders of magnitude for broadly similar accuracy, because nobody had been optimizing for cost.^[25]
• An agent built for a workflow that a two-step rule could handle.
• A platform licensed across the whole company for a use case in one team.

In each case the capability is real and the purchase can be defended, and in each case the company has bought a fixed cost with no volume to spread it over. Capability becomes value only when it is applied to a problem whose solution is worth more than the capability costs, and the arithmetic for that is the same as in Chapter 6.

12The hype trap

For all its caution, this paper is in favor of AI. We build AI systems for a living, and we think the technology is the most significant change to the economics of knowledge work in a generation. That is why this chapter is here. The surest way to waste the opportunity is to chase it for the wrong reasons, and at the moment the wrong reasons are everywhere.

Technology looking for a problem. The procedure in Chapter 13 starts with a business problem and ends, sometimes, with AI. The hype version starts with AI and goes looking for somewhere to put it. That order produces pilots nobody asked for, in processes nobody owns, measured by nobody.

The evidence that this is common is not subtle. A 2025 MIT report, drawing on surveys and interviews covering several hundred AI initiatives, concluded that the large majority of enterprise generative AI pilots had produced no measurable effect on profit and loss. Its methods were criticized, and its headline number is better read as a signal than a measurement, but the pattern it described, pilots that never reach the real workflow, matched what practitioners were seeing everywhere.^[26] Gartner, using a different method, predicted in mid-2024 that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, rising costs and unclear business value. In 2025 it predicted that more than 40 percent of agentic AI projects would be canceled by the end of 2027.^[27][28]

McKinsey's surveys tell the same story from inside companies. In early 2025, 78 percent of respondents said their organizations used AI somewhere, and more than 80 percent said it had no tangible effect on enterprise earnings. By late 2025 use had reached 88 percent, and 39 percent reported any effect on earnings at all, most of them under 5 percent.^[29] None of this is a verdict on the technology. It is a verdict on the order of operations.

Demos that leave out the costs. A sixty-second video of an agent booking a meeting, researching a prospect and drafting the outreach demonstrates a capability, not an economic result. It does not show the evaluation set, the failure rate, the permissions, the cost of the wrong email sent to the wrong prospect, or the engineer who will maintain it when the CRM's API changes. Social media rewards the sixty seconds and never shows the rest.

Productivity claims that do not transfer. Controlled studies of AI assistance find real gains for individuals on specific tasks: writing tasks done about 40 percent faster in one experiment, a programming task done 56 percent faster in another.^[30][31] Those gains are real, but they sit at the top of the range, and they were measured on well-defined tasks chosen because they could be measured cleanly.

Other studies point the other way. In a 2025 randomized study, sixteen experienced open-source developers working in their own large codebases took 19 percent longer with AI tools, while believing they had been faster. The same group's larger follow-up, using late-2025 tools, found no reliable effect in either direction and warned that its own results were already out of date, which is a fair summary of the evidence as a whole.^[32] A study of 25,000 Danish workers in exposed occupations, using survey and administrative data, found that adoption had been rapid, that time savings were modest at about 3 percent of hours, and that there was no detectable effect yet on earnings or hours worked.^[33] The distance between one person finishing a task faster and an organization becoming more profitable is the whole subject of Part I, and no headline figure covers it on its own.

Vendor projections. A vendor's ROI model is a sales document. Its assumptions about adoption, error rates and what happens to freed hours were made by someone paid on the outcome of the meeting. Treat it the way Flyvbjerg would treat a project team's cost estimate: as the inside view, to be checked against what comparable deployments actually delivered. The same skepticism applies to the industry's favorite cautionary statistic. The claim that 70 percent of change programs fail has been repeated for thirty years, yet when a researcher traced it to its sources in 2011, the trail led to no valid empirical evidence at all.^[34] Numbers that travel without their methods are marketing, whichever side of the argument they serve.

Prototype versus production. The jagged frontier applies to whole projects as well as to tasks. The prototype was built inside the frontier, and production will spend much of its time outside it. The pattern predates language models. McKinsey's 2018 survey of more than 700 industrial companies coined the phrase pilot purgatory for plenty of activity with no bottom-line benefit. It found that fewer than a third had moved their critical use cases into large-scale rollout, and 61 percent named the lack of a demonstrated return as a major obstacle.^[35]

Klarna's experience shows the whole arc in public. In February 2024 the company announced that its AI assistant had handled two thirds of customer service chats in its first month, doing the work of 700 full-time agents, with a projected 40 million dollar improvement in profit.^[36] By 2025 its chief executive was saying publicly that cost had weighed too heavily in the decision, that quality had suffered, and that the company was hiring people for customer service again, with the model handling the simpler cases and humans the rest.^[37] The story is less about AI failing than about a business case that counted the cost saving without pricing the quality, and about a company willing to correct it in public.

Automation that creates work. An AI system without a process owner produces outputs someone must check, questions someone must answer and incidents someone must handle. If those people were not in the plan, the system has added work rather than removed it. The symptom is a team that is busier after the automation than before. The cause is almost always that three things were missing at the start: a named owner, a defined path for exceptions, and a KPI that would show whether the thing was working.

Be most skeptical of the biggest claims: that a whole function can be replaced, that everything can be automated, that one tool will transform the business. They are not impossible, but the evidence for them does not yet exist. In our experience, the companies getting real returns from AI are making unglamorous, specific, measured changes to particular processes, one at a time, in the order the economics dictate.

13A practical procedure

This is the procedure we use, written so that a leadership team could run it without us. It has fifteen steps, and the order matters: each step is cheaper than the next, and the project can rightly stop at any of them. Most candidates should stop before step nine. When they do, the procedure is working.

1. Start from a business problem. Not a technology, a task or a demo, but a cost that is too high, a cycle that is too slow, an error that keeps happening or a limit on growth. Write it down in one sentence with a number in it.
2. Understand the process as it is actually done, not as the procedure manual describes it. Watch it. Ask the people who do it what they do when the normal path does not apply, because that is where the exceptions live.
3. Establish the baseline. Volume per month, hours per unit, who does the work, error rate and cycle time, measured over at least two weeks. Do not rely on people's estimates of their own time. In a work-sampling study at Duke, junior doctors overstated the time they spent examining patients by 70 percent and understated their time with supervising physicians by more than half.^[38] Our own baselines show errors of a similar size, in both directions.
4. Price the baseline. Hours at fully loaded cost, errors at their all-in cost, delay at its cost to whoever is waiting. Add the opportunity cost of people's time if there is a specific better use for it. This is the cost of doing nothing, and it goes at the top of the business case.
5. Eliminate what does not need to exist. For every step, output and approval, ask who uses it and what would happen if it stopped. Remove what nobody would miss.
6. Simplify and standardize what remains. One way of doing it, agreed by the people who do it, and written down. If the process cannot be standardized, stop here and record why; it is not a candidate yet.
7. Re-price the simplified process. Steps 5 and 6 often deliver most of the available savings at no cost. Decide whether to go on.
8. List the possible solutions across the whole ladder. Manual with a better form, a feature of software you already own, a rule-based workflow, a product, a custom build, an AI-augmented step, an agent. Rule out in writing the rungs that clearly do not fit.
9. Estimate total cost of ownership with the outside view. For the two or three rungs that remain, ask what comparable automations actually cost to run, here or elsewhere. If nobody knows, add a contingency that reflects the uncertainty, and say so.
10. Build the business case for each. Three years of total cost of ownership. Benefits split into cash, capacity and the rest, with the management decision that turns capacity into cash stated explicitly. ROI, payback and NPV. Sensitivity to the exception rate, maintenance, adoption and cash conversion.
11. Evaluate the risks and dependencies. Which systems does this touch, and how often do they change? Which vendor does it depend on, and what is the exit? What happens on the day it fails, and who runs the manual fallback? For AI: what is the error rate on your data, what does an error cost, and how will errors be caught?
12. Run a small pilot with a defined end. One team, one slice of the volume, a fixed period, a success threshold agreed in advance, and the baseline from step 3 as the comparison. A pilot without a kill criterion is not a pilot but a soft launch.
13. Measure the actual results. Same metrics as the baseline, same method, same length of period. Include the hours that the people who were supposed to be freed now spend on the automation.
14. Compare with the business case, line by line. Where did the forecast miss, and why? This is the most valuable information the company will get about its next automation, and it is usually skipped because by now everyone wants to move on.
15. Scale, improve or stop. Scale if the pilot met the threshold and the cost model holds at volume. Improve if it missed on something fixable. Stop if it missed on something structural, and treat the cost of the pilot as the price of what you learned. A company that has never stopped an automation has never evaluated one honestly.

Who does what

Automation fails as an IT decision, as a finance decision and as an operations decision whenever only one of those functions makes it. The reason is economic. The value depends on a decision about how to use people and money, which belongs to finance and operations. The cost depends on technical choices and their maintenance burden, which belong to technology. And the whole thing works only if the people doing the process adopt it. Each of these groups can effectively veto the result, so each needs a seat at the table.

Of the six, the one most often missing is the last. The people who do the work know where the exceptions are, what the documentation gets wrong, and which steps exist only because of a problem solved three years ago. Their adoption also decides whether the forecast value ever arrives. An automation designed without them is designed around a description of the process rather than the process itself, and it will meet the real one on launch day.

14Measuring success

After launch, an automation has to answer the question it was meant to answer when it was approved: is the organization economically better off? Everything else is instrumentation in service of that question. The instrumentation matters, because without it the question cannot be answered, but be clear about which measures track outcomes and which track activity. The two are confused constantly, and the confusion is expensive.

Compare that list with the measures that fill most automation dashboards: workflows automated, bots or agents deployed, model calls made, hours theoretically saved. Each is a count of activity, and none says whether the company made or lost money. A company with four hundred automated workflows and no measured change in cost per task or throughput has a large maintenance burden and no evidence of value. The count is not meaningless, but it is an input, and inputs are what a company spends, not what it earns.

Hours saved needs particular care, because it is the metric most likely to be reported and the one most likely to mislead. It is a forecast of capacity, and capacity has no value until it is used. The follow-up question is always the same: saved for what? If the answer is a smaller team, a hire not made, a backlog cleared or a product shipped sooner, the hours have a value you can state. If nobody knows the answer, the hours have not been saved in any sense a CFO would recognize.

Two cautions about measurement itself. First, any measure that becomes a target will be gamed. The principle is usually called Goodhart's law, and the phrasing most people quote is Marilyn Strathern's: when a measure becomes a target, it ceases to be a good measure.^[39] So measure the outcome, and keep the activity metrics as diagnostics. Second, measure against the baseline taken before launch, using the same method. A process that was never measured cannot be shown to have improved, and a surprising number of automation programs discover this at the very moment they try to prove their value.

15Common mistakes

We have seen every item below more than once, in companies that are otherwise well run, and we are not alone. EY's practitioners wrote in 2016 that they had seen as many as 30 to 50 percent of initial RPA projects fail, and were careful to add that the cause was not the technology but a short list of avoidable mistakes. That is an impression from a firm that sells implementations, not a measurement, but their list largely matches ours.^[40] Each mistake has an economic consequence, and each has a remedy that costs less than the mistake.

The last row ties the others together. An automation is not a project that ends. It is a capital asset that depreciates, needs maintenance, lives in a changing environment and should be reviewed on a schedule like any other asset. Treat it as a project and attention stops at launch, which is when the operating costs begin.

16Building an automation strategy

Everything so far has been about a single decision. A company that makes many such decisions needs a way to make them consistently, and that is what an automation strategy is for. It is not a list of technologies. It is a method for putting a limited budget and limited engineering attention into the opportunities with the highest expected return, and for checking afterwards whether the returns arrived.

Treat automation as a portfolio. At any moment a company has some automations under consideration, some in flight and some in production. Each has an expected return, a cost, a risk and a claim on scarce people. The portfolio view asks the question no single project can: given this year's budget and engineers, which combination produces the most value? The answer is rarely the projects with the highest individual ROI, because those tend to be the smallest. Nor is it usually the largest projects, which absorb capacity that several medium-sized ones would have used better.

Prioritize on economic value, and balance the time horizon. Quick wins, like the rule-based workflow that pays back in four months, build capability and credibility and fund the next round. Strategic investments, like a data foundation that makes six later automations possible, pay back slowly, and only if those later automations happen. A portfolio of nothing but quick wins stays small. A portfolio of nothing but strategic bets runs out of credibility before it runs out of money.

Davenport and Ronanki made the same point in their study of 152 early AI projects, under the heading don't start with moon shots. Their cautionary tale was MD Anderson Cancer Center's attempt to build an oncology adviser with IBM, which was put on hold after costs passed 62 million dollars without reaching patients, while the same institution's modest projects for hotel bookings and billing were quietly delivering.^[41] The usual discipline applies: put most of the capacity into things that pay within a year, and a deliberate minority into things that compound.

Choose the governance model deliberately. A central automation team brings consistency, reuse and standards, but it becomes a bottleneck and loses touch with the processes. Decentralized teams automate what they understand, quickly, and leave behind fifty incompatible workflows with no owner once the builder moves on. Most companies that do this well settle on a hybrid: a small central group owns the platform, the standards, the evaluation practice and the business-case template, while business units own the processes and the priorities. Where exactly the line falls matters less than that it is drawn and everyone knows where it is.

Give every automation an owner, a cost line and a review date. An owner who is a person, not a team. A running cost, not a project budget. And an annual review of whether it still earns its keep, not just a launch date. In our experience, the number of automations in a mid-sized company that are still running, still costing money and no longer doing anything useful comes as a surprise to the CFO.

Document processes before automating them, and keep the documentation with the automation. The automation is the executable form of the documentation. When the two drift apart, one of them is wrong, and nobody will know which until it matters.

Invest in shared infrastructure where the volume justifies it. Integration with the CRM, the ERP and the identity system; a document pipeline; an evaluation harness for AI components; monitoring. The first automation that needs each of these pays for it, and the fifth gets it almost free. The strategic question is whether to build them for the first automation or wait for the second, and the answer depends on how sure the company is that the second is coming.

Manage risk at the portfolio level. Dependence on one vendor, one platform or one engineer is a portfolio risk rather than a project risk, and it is visible only from above. So is the combined damage that automations acting in customer-facing or financial systems could do if they failed together.

Do not automate everything at once. The constraint is usually not money but attention: that of the people who understand the processes, and of the engineers who can build and maintain the automations. Both are finite. A company that launches ten automations in a quarter ends up with ten half-adopted systems and overstretched owners.

History points the same way, from electrification to enterprise software: the returns go to companies that reorganize carefully around a technology, not to those that deploy the most of it. Brynjolfsson and Hitt's review of the evidence on information technology and productivity concluded that the complementary investments in process redesign, training and new ways of working were many times larger than the investment in the technology itself, and were where the returns were decided.^[2] The sharpest demonstration is a 2012 study of establishments in Europe. Doubling the IT capital stock was associated with 1.2 percent higher productivity at domestic firms and non-American multinationals, but 4.9 percent at establishments owned by American multinationals, and most of the difference came down to management practices rather than technology.^[42] There is no reason to expect the current wave to be different, and some early evidence that it is not.

17What comes next

This chapter separates what is known from what is forecast, because the two are routinely blended, and the blend is where bad capital allocation comes from.

What the evidence supports

The cost of some cognitive tasks is falling fast. The Stanford AI Index reported that the inference cost of reaching a given level of performance on a standard benchmark fell more than 280-fold between late 2022 and late 2024.^[43] A 2025 study built on the largest dataset of benchmark prices to date put the decline at roughly 5 to 10 times a year for a fixed level of frontier performance, while the price of running the newest frontier models rose by 3 to 18 times a year, because they are larger and do more reasoning.^[44] For a business, this means the model-usage line in an AI business case is likely to be overstated for any task that does not need the newest model, and a workflow that is marginal at today's prices may be clearly worthwhile in two years. It does not mean the other lines fall with it. Integration, evaluation, review, governance and change management are priced in human time, and human time is not getting cheaper.

The division of labor between people and machines is shifting task by task, not job by job. The most careful attempts to measure exposure find that most occupations contain tasks a model can now do and tasks it cannot, and that the share of occupations where a model could do nearly everything is small. One widely cited analysis estimated that about 80 percent of the US workforce could have at least a tenth of their tasks affected by language models, and roughly a fifth could see half or more of their tasks affected.^[45] The International Labour Organization, applying a similar task-level method across countries, concluded that the potential to augment existing jobs is considerably larger than the potential to automate them entirely.^[46] Anthropic's own analysis of how its models are used found usage split between augmentation and automation. Augmentation was the larger share in its first report, in early 2025; automation had overtaken it by that autumn, and enterprise traffic through Anthropic's API leaned far more toward automation than consumer use did.^[47]

The history of this measurement is instructive. A 2013 Oxford study that scored whole occupations put 47 percent of American employment at high risk of computerization. Three years later, an OECD analysis that scored the tasks inside occupations instead put the comparable figure at around 9 percent.^[48][49] The job is not the unit of analysis. The task is.

Early effects on the labor market are visible, and uneven. Research using payroll data for millions of US workers found, in its first version in August 2025, that employment of early-career workers in the occupations most exposed to AI had fallen by about 13 percent relative to less exposed occupations, while more experienced workers in the same occupations were not affected in the same way. With data through mid-2026, the authors put the gap at about 19 percent below trend, driven mainly by reduced hiring.^[50] This fits the field studies showing that AI assistance substitutes most for the skills of the least experienced. It is descriptive rather than causal, from one country, over a short period, and it says nothing about what happens next. But it is evidence, and it should shape how companies think about where their future senior people will come from.

Adoption by firms is narrower than the conversation suggests. The Census Bureau's survey of more than 850,000 American firms for 2017 found AI adoption of 6.6 percent across the economy, rising from 5.3 percent among the smallest firms to 62.5 percent among those with more than 10,000 employees. The same pattern, with large and established firms first, shows up in the Bureau's current biweekly survey, which in May 2026 put AI use at about a fifth of all firms and 37 percent of those with 250 or more employees.^[51][52] Most of the economy has not yet made the decisions this paper is about.

What is forecast, and should be treated as such

Macroeconomic estimates differ by an order of magnitude. Acemoglu's 2024 analysis, which assumes AI affects only the tasks where current capability has been demonstrated, puts the gain in total factor productivity at no more than about two thirds of one percent over a decade.^[53] Other estimates, assuming broader capability and faster adoption, are many times larger. The spread is informative in itself: the aggregate return depends on assumptions that are not yet settled. A company should plan on its own measured results, not on anyone's macro forecast, the optimistic ones included.

The economics of autonomous agents are, as of this writing, mostly unproven in ordinary business settings. Published benchmarks show capable models completing a good share of realistic multi-step tasks on a single attempt, and far fewer when they must succeed on every one of repeated attempts, which is the standard a business process needs.^[54] A 2025 benchmark built by Salesforce on realistic sales and service tasks in its own CRM found leading agents succeeding on about 58 percent of single-turn tasks, and about 35 percent once a conversation with a user was involved.^[55]

If that gap closes, as it appears to be doing, the economic effect will be large. An agent that can be trusted with multi-step work across systems removes much of the integration and orchestration cost that dominates the total cost of AI automation today. Until then, the right posture is the one in Chapter 11: measure reliability on your own task, price the errors, make actions reversible, and extend autonomy as the evidence comes in. Companies that build the evaluation and reversibility infrastructure now are likely to be the ones able to move quickly when the capability arrives.

Organizations will change shape, and nobody knows how. They may become flatter in some functions, where models take over the coordination that middle layers used to do. They may become smaller for a given revenue, if the fixed-cost logic of Chapter 1 plays out across knowledge work as it did across manufacturing. They may become more senior-heavy, if the entry-level tasks that trained juniors are the ones that get automated, which raises a question no company has yet answered: where will the senior people of 2040 come from? Lisanne Bainbridge identified the underlying irony in 1983, writing about industrial control rooms. The designer who tries to eliminate the operator still leaves the operator the tasks the designer could not work out how to automate, and an operator who has only ever monitored an automated process is no longer an experienced one when it fails.^[56] All of these futures are plausible. None of them is evidence yet.

What does not change

Even if model costs fell to zero, four things would stay expensive, and they are the things that decide whether an automation makes money.

Implementation. Someone has to connect the model to the systems, the data and the process, and that is human work in an organization that was not designed for it. Brynjolfsson, Rock and Syverson call the resulting pattern a productivity J-curve. A general-purpose technology first depresses measured productivity, because firms are investing in intangible complements (process redesign, training, new ways of organizing) that do not show up as output. Productivity rises only later, once those complements are in place.^[57] Firm-level studies of enterprise software found the same shape one company at a time: ERP adopters saw productivity dip during implementation and rise afterwards, along with their market value.^[58] Many companies are probably in the dip now, and the rise is available only to those that make the investments the dip consists of.

Accountability. A model cannot be responsible for an outcome. A person has to be, and that person's attention, judgment and name are what the organization pays for when something goes wrong. The cost of oversight does not shrink with the cost of the model, and for high-risk uses in the European Union it is now written into law: the EU's AI Act requires high-risk systems to be designed so that the people overseeing them can understand their limits, stay alert to their own tendency to over-rely on the output, and override or stop the system.^[59]

Judgment, creativity and relationships. Brynjolfsson's Turing trap argument is an economic one. A technology built to imitate people competes with them and drives down the value of what they do; a technology built to augment them raises that value and creates more for the firm and the economy.^[60] The tasks that stay with people, such as deciding what to do with freed capacity, owning the customer relationship and choosing which problem to solve, determine where the value of all the automation ends up. Their relative worth rises as everything around them gets cheaper, which puts them at the center of the economics rather than at its edges.

The decision itself. Whether to automate, what, when and how will remain a management decision, made under uncertainty with imperfect information about costs and benefits. The quality of that decision will keep separating the companies that get value from automation from those that get a pilot. The technology will keep changing. The question this paper opened with will not.