The Execution Tax: Why How You Automate Decides What It Costs Forever

It usually starts with a single, sensible ambition: take one workflow that a person does today, and automate it.

Then you look closely at the work, and something uncomfortable surfaces. The inputs arrive as PDFs and screenshots, laid out for a human to scan. The rules that govern the work live in someone's head. Every case is phrased a little differently. And the moment you try to hand this to AI, you realise the machine has to re-read and re-interpret all of it — every single time it runs.

That re-interpretation isn't free. Every execution burns tokens, leans on the most capable (and expensive) model, and stays fragile to the smallest change in format. You haven't automated a workflow so much as agreed to pay a fee on it, forever.

This is the most fundamental — and most overlooked — decision in applied automation. The way work is shaped for human eyes is a liability for machines. And how you handle that, at the moment you automate, determines what the workflow costs for the rest of its life.

The cost you can't see at build time

Traditional automation thinking treats cost as a one-time event: you pay to build it, then it runs. That mental model is wrong for AI-era automation, where the dominant cost is per-execution, not per-build.

A human can absorb a messy, visual, implicit input through judgment at no marginal cost. A machine cannot. It must reconstruct meaning from the human-shaped artifact on every run — and that recurring cost is set by a decision you make once, at design time.

We call this the Execution Tax: the recurring, compounding cost you inherit when you automate around human-shaped work instead of reshaping it first. A build-time choice sets the slope of the run-time cost curve.

The shape of this picture is the whole argument. "Automate as-is" is cheaper to build and looks like the pragmatic choice. But its run cost is steep, and because it's paid on every execution, it overtakes the "reshape first" path and never stops climbing. By the time you've run the workflow at real volume, the decision you made to save a few thousand at build time has cost you many times that in run.

This is why so many automation programmes quietly stall. The pilot looked cheap. Then it went to volume, and the economics inverted.

Why the industry keeps getting this wrong

There's no shortage of advice telling organisations not to automate broken processes. Bain puts it bluntly: automating a broken process is "the single most costly mistake in AI deployment… AI doesn't fix workflow debt; it locks it in, speeds it up, and makes it vastly more expensive to unwind" (Bain & Company). The idea is older still — Michael Hammer's 1990 warning to "don't automate, obliterate" is the same instinct, three decades early.

But that conversation operates at the altitude of org charts and approval chains — workflow debt, handoffs, decision rights. It's strategically correct and operationally vague. It rarely reaches the level where the actual recurring cost is decided: the information architecture of a single workflow.

Meanwhile, a second, entirely separate conversation happens among engineers: use structured outputs, route to cheaper models, cache your prompts. All true, all tactical, and all disconnected from any business framing of why it matters.

The gap between these two conversations is where the Execution Tax lives. The shape of a workflow's inputs is simultaneously an engineering fact (it sets token cost and reliability) and a strategic one (it sets whether incremental automation produces predictable ROI). Bridging them is the difference between automation that compounds and automation that bleeds.

There's a hard reason this matters more with AI than it ever did with traditional software. As Bain observes, "Humans can work around fuzzy rules; agents can't. They need clear rules, stable handoffs, and aligned decision rights" (Bain & Company). A person silently compensates for badly-shaped work. A machine bills you for it — or breaks.

Why human work resists machines

If we're going to reshape work before automating it, we need to be precise about what makes work machine-hostile in the first place. In our delivery experience, it reduces to four recurring forms.

None of these are exotic. They're the default state of almost all knowledge work, because that work evolved to be performed by humans — who are extraordinary at reading visual layouts, carrying context in their heads, absorbing variability, and blending judgment into routine without noticing. Every one of those human strengths is a machine's recurring cost.

The point of naming the four forms is diagnostic. When you can see which form of hostility a workflow contains, you know which reshaping move to reach for — and you can estimate the tax before you commit to paying it.

The decision that sets the curve

Underneath all of this is one repeating choice, made step by step through a workflow: do you transform the information once into a form machines can use cheaply, or do you interpret the human-shaped version on every run?

Almost every expensive automation we've seen is stuck in the right-hand column — interpreting raw, human-shaped inputs on every execution, usually with a large model and a long prompt, to extract information whose structure never actually changes. It feels like progress because it works in the demo. It's a tax because it works every time, at full price.

The discipline is to push the work as far left as you can. If you have any influence over how the information is captured, structure it at the source — the cheapest token is the one you never have to spend re-reading a layout. If you can't change the source, transform once: pay a single normalisation cost to turn the human-shaped input into a stable schema, then run cheap, deterministic steps against that schema forever after.

This single reframe — transform once, don't interpret every time — is the highest-leverage idea in the whole playbook. It's also the one that maps directly to the API pricing reality: published vendor pricing shows output tokens cost several times more than input tokens (Anthropic, OpenAI), and constraining a model to emit compact, structured output instead of verbose prose is one of the most reliable ways to cut both cost and failure rate. You only get to make that move once the input has been reshaped to allow it.

The Machine-Readiness Playbook

Knowing the principle isn't the same as having a repeatable way to apply it. Because real automation journeys start incrementally — one workflow at a time — what you need is not a grand transformation programme but a disciplined sequence you can run on each candidate before you commit to automating it.

A few notes on using it in practice.

Move 1 (Trace) is observation, not documentation. You are watching a real instance flow through, looking specifically for the four forms of hostility. Most teams skip this and go straight to "where do we plug in the AI?" — which is exactly how the tax gets baked in unnoticed.

Move 2 (Price the Tax) is the move that changes minds. When you put a credible per-execution number next to a realistic volume, the "automate as-is" option stops looking cheap. This is also where you decide whether a workflow is even worth automating yet, or whether reshaping has to come first.

Move 3 (Reshape) and Move 4 (Right-tool) are where the savings are actually realised. Reshaping makes the inputs legible; right-tooling makes sure you're not using a probabilistic model for deterministic work. As we've argued in our AI Value Realisation Pathway, predictable work belongs in code, not in prompts — the model should handle only what genuinely requires judgment.

Move 5 (Prove, then Compound) is what makes this strategic rather than tactical. You instrument cost-per-execution and quality, scale only when results are predictable, and then bank the reusable parts — the schemas, transforms, prompts, and routing rules. The second workflow borrows from the first. The tenth starts from a library. This is the mechanism by which a series of small, predictable wins becomes the foundation for transformation upstream.

Incremental wins are the strategy, not a compromise

It's tempting to read "one workflow at a time" as the timid option — the thing you do because you can't afford the big bang. It isn't. Incrementalism is the correct strategy here, for a specific reason: each workflow you reshape and automate well produces a predictable result and a reusable asset. The predictability earns trust and budget for the next one. The reusable assets make the next one cheaper.

That's a compounding loop, and it's the opposite of the all-or-nothing reengineering programmes that the strategy literature both recommends and admits are risky. You don't need to bet the organisation. You need to get genuinely good at the unit of work — automating a single workflow without inheriting a tax — and then do it again, deliberately, building the library as you go.

The organisations that struggle aren't the ones moving slowly. They're the ones moving carelessly — automating workflow after workflow as-is, each one quietly adding to a run-rate that no one modelled, until the AI budget is growing and the returns aren't.

Is this workflow ready?

Before you automate your next candidate, it's worth a two-minute honest read on how machine-ready it actually is — and therefore how much Execution Tax automating it as-is would lock in.

A low score isn't a reason not to automate. It's a reason to spend a little time on Trace and Reshape first, because that's the work that changes the slope of the cost curve for the entire life of the automation. A high score means the hard part is largely done — move to right-tooling, run a measured pilot, and bank what you learn.

The takeaway

The most important automation decision isn't whether to automate or even what to automate. It's how — specifically, whether you reshape the work for machines before you hand it over, or pay to interpret human-shaped work on every single run.

That choice is made quietly, at build time, by people focused on getting something working. And it sets a recurring cost that compounds for the life of the system. Naming it — the Execution Tax — is the first step to refusing to pay it.

Start with one workflow. Book a conversation and we'll trace it together, price the tax honestly, and show you exactly where reshaping changes the economics.

Sources

1. Bain & Company. Your AI Budget Is Growing. Your Returns Aren't. Here's Why. 2025. bain.com

2. Bain & Company. Want More Out of Your AI Investments? Think People First. 2025. bain.com

3. Hammer, Michael. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review, July–August 1990. hbr.org

4. McKinsey & Company. The State of AI. McKinsey QuantumBlack. mckinsey.com

5. Anthropic. API Pricing. anthropic.com/pricing

6. OpenAI. API Pricing. openai.com/api/pricing