There is a serious argument against re-engineering your workflows, and it deserves a better hearing than it usually gets.
It goes like this. Compute keeps getting cheaper. Models keep getting better at reading the mess we already have. So why spend a year and a budget re-plumbing a process, when you could point an agent at the existing documents and let it figure things out? Every hour of engineering you spend making a workflow machine-legible is an hour bet against the technology improving — and that has been a losing bet for three years running.
We have watched this logic play out before. For decades, repairing a household appliance or a phone made economic sense. Then manufacturing costs fell, skilled repair labour did not, and replacement quietly won. It won so completely that the European Union eventually legislated to reduce the premature disposal of goods that were perfectly viable, and to stop manufacturers using hardware or software techniques that impede repair [3]. Repair did not die because people stopped caring. It died because the maths stopped working.
So: is process re-engineering the new repair?
Three industries already ran this experiment
Before theorising, it's worth looking at sectors that faced exactly this choice with real capital at risk. None of them answered the way you'd expect.
Three Industries, One Question
Adapt the Machine, or Reshape the World?
Each already ran the experiment — and none of them answered the way you'd expect
What happened
Operators owned the environment completely and rebuilt it for machines. In practice automated terminals came out measurably less productive than conventional ones, and the capital only justified itself under demanding conditions.
What it proves
Owning the environment is not sufficient. Reshaping pays where flows are large, captive and regular — and struggles precisely where volume fluctuates, which is where flexible human labour still wins.
For your operation
The most sobering case for anyone who assumes re-engineering always wins. Variability is the enemy of a reshaped flow; check it before you commit capital.
The container terminal case is the uncomfortable one, and it deserves stating plainly. Port operators own their environment completely — they can lay the concrete, place the markers and dictate the layout. They reshaped it for machines. And the International Transport Forum found that in practice automated ports came out less productive than conventional ones, by something like 7 to 15 per cent; justifying the capital would have required operating expenses 25 per cent lower, or a 30 per cent productivity gain [1]. Automation paid off in specific conditions — large terminals with highly captive and regular flows — while under fluctuating workload the finding was blunt: automated terminals are not well suited to that, and port labour is [1].
That is a direct challenge to anyone who assumes re-engineering always wins. Owning the environment is necessary but nowhere near sufficient. Variability is what kills a reshaped flow, because a deterministic design is a bet on the world staying the shape you designed for.
The autonomous driving case cuts the other way, and corrects a story most of us tell wrongly. The popular version is that we left the world messy and improved the technology until it could cope. The operating reality is narrower: an automated driving system is defined by an operational design domain — the environmental, geographical and time-of-day conditions it is built for — and a serious system knows whether it is operating within its geolocational limits, with fail-safe behaviour when it is confronted with conditions outside that domain [2]. The regulator even contemplates a manufacturer declaring that operating outside the ODD would be unsafe, and that the vehicle has therefore been designed so that it cannot do so [2].
Read that again, because it is the opposite of "the machine learned to handle anything". We did not conquer unbounded mess. We drew a boundary around the mess we could handle, made the boundary explicit, and engineered what happens at the edge.
What a cheaper token cannot touch
Now the tokenomics question directly. If inference trends toward free, does the argument collapse?
Look at what is actually happening to the bills. Adoption has climbed to 88% of organisations while agent deployment remains in the single digits, and compute and infrastructure spending is hitting record levels rather than falling [4]. Unit prices dropping and total spend rising are not a contradiction; that is what happens when something gets cheap enough to use everywhere. Cheaper units do not produce cheaper systems.
More importantly, compute is only part of what a flow costs to run.
At $10.00 per million tokens, compute is 29 percent of the monthly cost of this flow. Cutting the token price by 0 percent reduces total cost by only 0 percent, because human assurance does not get cheaper.
Compute
USD 1,600
falls with token price
Human assurance
USD 4,000
does not
Monthly total
USD 5,600
compute is 29% of it
Compute is 29% of what this flow costs to run. Drag the token price down and watch how little of the total a cheaper model can actually reach.
Verification
Someone still has to know the parse was right. Checking is human time, and it is not deflating.
Accountability
Judgment, ethics and regulatory answerability stay with a person regardless of model price.
Being wrong
A misread at scale is remediation, credit notes and lost trust — the bill compute pricing never sees.
Illustrative model. 20,000 runs/month, ~8k tokens per parse, $4 of human time per touch.
That floor is the whole argument. Verification does not get cheaper: somebody still has to know the parse was right. Accountability does not get cheaper: judgment, ethics and regulatory answerability stay with a person no matter what the model costs [6], and the work where trust and accountability dominate stays human-led by design [5]. And being wrong does not get cheaper — a misread at scale becomes remediation and lost trust, a bill that never appears on a compute invoice.
There's a corroborating signal in the productivity data. The largest measured gains show up in structured, measurable work where outputs are easy to monitor, and are smaller where deeper reasoning is required [4]. Structure is not merely a nice-to-have for machines. It is where the returns concentrate — which is another way of saying the value of a machine-legible handoff is not primarily the tokens it saves.
So when should you not re-engineer?
Often, honestly. Here is the test.
The Disposability Test
Reshape It, or Let It Stay Messy?
Set these for one real flow — the answer is often not “re-engineer it”
Volume
How often does this flow run?
Fixed costs amortise over runs. Low volume never repays engineering.
Durability
Will this flow still exist in two years?
Reshaping a flow that is about to change is engineering you throw away.
Ownership
Do you control the interface?
You cannot reshape a customer’s PDF or a regulator’s portal. This is the hard constraint.
Stakes
What happens if it gets this wrong?
High stakes buy determinism or constraint — never an unchecked parse.
The call
Reshape it
The one-off work repays itself
Why
You control the interface, the flow is durable, and the volume is high enough that a fixed engineering cost amortises into a permanent saving.
Do this
Emit structured data at the source and delete the parse. You get the cost back and the failure mode with it.
Precedent: Container terminals: automation pays where flows are large, captive and regular — and only there.
Two of these deserve emphasis because they are where teams go wrong in opposite directions.
Ownership is a hard constraint, not a difficulty. You cannot reshape a customer's PDF, a supplier's spreadsheet, or a regulator's portal. Teams burn entire quarters trying to standardise inputs that belong to someone else. That is not an engineering problem you can out-execute; it is a boundary you don't get to move. Where you don't own the interface, the honest options are to absorb the parse or to bound the domain — never to keep pushing a schema uphill.
Low volume and short life should stop you cold. A fixed engineering cost only amortises over runs and years. Re-engineering a flow that runs 200 times a month, or that will be replaced when the platform migration lands, is engineering you throw away. That is the genuinely disposable case, and treating it as disposable is the correct call rather than a failure of ambition. The discipline BCG frames as asking both could AI do this and should AI do this exists precisely to avoid over-automation as well as under-utilisation [5].
Make it a calculation, not a doctrine
The reason this stays hard is that every input moves. Prices fall, volumes grow, flows stabilise or get retired.
The Decision Loop
How to Make the Call — and Keep Making It
The right answer changes as prices fall and volumes grow
Put a number on the recurring parse and a number on the one-off reshape, then divide. If the reshape does not repay inside a planning cycle, it is not a priority — whatever the architecture diagram says.
Why it matters
Most reshape-versus-absorb debates are conducted on taste. The maths is not hard and it settles the argument.
In practice
Even a large redesign can carry a defensible payback when volume is high — but you have to compute it rather than assume it.
The good news is that this is arithmetic, not ideology, and serious redesigns do clear the bar when the conditions are right — the bank in BCG's case study expects full payback within two years and around 150% ROI over five [5]. The number exists. Most organisations simply never compute it, and argue from taste instead.
The honest position
So yes — there is a world where compute gets cheap enough that re-engineering a given flow is not worth it. That world already exists for low-volume, short-lived work behind interfaces you don't control. Anyone insisting every workflow deserves redesign is selling something.
But that world does not arrive by the token price alone, because the token price is not what makes the hard cases hard. As compute approaches free, the binding constraint doesn't disappear — it shifts from cost to trust. What remains expensive is knowing the machine got it right, and owning the consequences when it didn't. Those costs are paid in human attention, and human attention is the one input in this system that isn't deflating.
The mature position is neither "reshape everything" nor "let the agent figure it out". It is three options held at once: reshape what you own and run often, absorb what is cheap and temporary, and bound the domain where you can't reshape but can't afford to be silently wrong. The organisations that do well won't be the ones with the strongest conviction. They'll be the ones that recompute the answer as the inputs move.
Sources
- International Transport Forum / OECD. Container Port Automation: Impacts and Implications (Policy Paper No. 96). 2021.Reports that in practice automated ports are generally less productive than conventional ones — a McKinsey survey indicated productivity 7-15% lower — and that justifying the capital investment would require operating expenses 25% lower, or a 30% productivity rise where opex falls only 10%. Automation is cost-effective in specific circumstances such as large terminals with highly captive and regular container flows; under fluctuating workload, 'automated terminals are not particularly well suited to deal with these requirements. Port labour is.'View source
- NHTSA / Federal Register (US Department of Transportation). Framework for Automated Driving System Safety (ANPRM, Docket No. NHTSA-2020-0106). 3 December 2020.Defines the operational design domain (ODD) as the operating conditions under which a driving automation system is specifically designed to function, including environmental, geographical and time-of-day restrictions. Perception involves the system determining its location in relation to the driving environment and its ODD, 'including whether it is operating within any geolocational limitations in the ODD', with assessment covering 'fail-safe capabilities if/when it is confronted with conditions outside its ODD'. Contemplates a manufacturer stating 'that it would be unsafe for the vehicle to operate in automated mode outside its ODD and that the vehicle has therefore been designed so that it cannot do so'.View source
- European Union (EUR-Lex). Directive (EU) 2024/1799 on common rules promoting the repair of goods. June 2024.Adopted to reduce premature disposal of viable goods and encourage consumers to use goods for longer, noting that a large number of defective but otherwise viable goods are prematurely discarded. Manufacturers are prohibited from using contractual clauses, hardware or software techniques that impede the repair of listed goods unless justified by legitimate and objective factors.View source
- Stanford HAI. The 2026 AI Index Report — Economy. 2026.Compute costs and infrastructure spending are reaching record levels (Google reporting >$150B annual capex in 2025); organisational AI adoption rose to 88%, yet AI agent deployment remains in the single digits across nearly all business functions; productivity gains are largest in structured, measurable work where outputs are easy to monitor, and smaller in tasks requiring deeper reasoning.View source
- Boston Consulting Group. Design Your Company for AI, Not AI for Your Company. 2026.Only ~5% of organisations capture meaningful value at scale; becoming AI-first is 30% technology and 70% people and organisation. Leaders should ask both 'Could AI do this as well or better than humans?' and 'Should AI do this?', making the human-agent collaboration model explicit to avoid over-automation and under-utilisation; activities where trust, empathy or accountability dominate remain human-led. A global bank's redesign expects full payback within two years and a projected 150% ROI over five years.View source
- EY-Parthenon. How agentic AI can help unlock enterprise value at scale. June 2026.Humans remain embedded where judgment, accountability, ethics, or regulatory oversight are required, with people acting as supervisors, conductors and exception managers rather than process coordinators.View source