There is a mantra repeated at every tech conference and in every boardroom: «we need to apply AI». Companies of all sizes buy thousands of code-assistant licenses, commit tens of millions of euros to token consumption, and run internal training sessions over video calls. And yet productivity barely moves. Why? Because the vast majority of organizations are doing exactly what they did with computing three decades ago: applying technology on top of processes that were already broken — and the result is simply making garbage faster.
It is backed by data in a thread circulating these days on X, signed by Vas (@vasuman), CEO of the US-based AI adoption firm Varick Agents. After speaking with more than 300 CEOs, CIOs and CFOs of the world’s largest companies, his conclusion is damning: the world has spent a fortune on AI and, for most companies, almost nothing has changed. Maybe the problem isn’t the technology but the fact that nobody in the chain owns the process. In this article we break it down: why adoption fails, what history has to say, and how to avoid it with a methodology we practice every day at BAOSS.
The lesson from 1990 that nobody wanted to learn
In 1990, Michael Hammer —an MIT computer science professor— published an article in the Harvard Business Review that is almost a prophecy. After spending years inside companies that had spent enormous sums on computers with little return, he wrote:
«Heavy investments in information technology have delivered disappointing results, largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up».
If you replace «information technology» with «AI», you could publish that quote tomorrow on the front page of any business newspaper. Hammer also coined a vivid phrase: «stop paving over the cow paths» — that is, stop automating and consolidating an inefficient process instead of redesigning it to work the way it should. Thirty-six years later, we are still paving cow paths.
The figure that explains it all: 1 trillion versus 37 billion
The scale of the mismatch is staggering. In 2025, more than a trillion dollars was spent on capex building AI infrastructure —Microsoft, Alphabet, Amazon and Meta alone surpassed $410 billion— yet companies spent only $37 billion actually using it. The tip of the iceberg is the UK Department for Business and Trade’s trial with Microsoft 365 Copilot.
The result, published with total honesty, was disappointing: they deployed 1,000 licenses for 3 months and the average was just 1.14 Copilot actions per user per day. PowerPoint presentations took 7 minutes less (from 18 to 11), but with half the quality; Excel analysis was completed more slowly; and the time saved on email was, literally, «extremely small». Their literal conclusion: «We found no strong evidence that time savings are translating into productivity improvements». Even so, 72% of users said they were satisfied or very satisfied.
Ethan Mollick, a Wharton professor and well-known AI researcher, sums it up in one sentence: «Using AI that improves individual performance does not naturally translate into improving organizational performance». People enjoy the tool, but they produce exactly what they produced before.
The number that changes everything: 22 process days, 17 minutes of work
Hammer’s best figure comes from an insurer he studied. An insurance claim took 22 days to make its way through the company. Of those 22 days, the total time someone actually worked on it was 17 minutes. Now calculate what happens if your «AI expert» deploys the world’s best model over that process and makes each individual step twice as fast: they’ve saved eight and a half minutes. They’ll sell it as a «50% saving», get their bonus and move on. But it’s eight minutes.
The savings weren’t in working on the claim, but in the queues and handoffs: the wait for other teams, the dead time before the second review, the gaps between departments. Speeding up those 17 minutes is worse than doing nothing: you’ve spent the budget and proven to the board that «AI doesn’t work».
You might think this is a relic of the 1990s. It isn’t. Vas recounts working with a company whose own systems records demonstrated the same phenomenon: opening a new customer case required 25 minutes of real work, but the elapsed time from when a case came in to when it was activated ranged from 2 days to 2 weeks. The work can be minutes while the process stays weeks.
The fatal temptation: «let’s unify the systems first»
When the data is a mess and the systems don’t talk to each other, the instinct is to fix that before touching anything else: «we need a single ERP, a single CRM, a single data platform, and then AI on top». It sounds good in theory, but any IT specialist knows it is never that simple. The examples of spectacular failures with system migrations are legion.
TSB spent £318 million on a core banking migration, swallowed another ~£200 million or so in incident costs, was fined £48.65 million by the FCA and the PRA in December 2022, and left 5.2 million customers without banking services. Zimmer Biomet, a manufacturer worth $8 billion, filed a $172 million claim against Deloitte in September 2025 after a failed «migration and consolidation» prevented it from carrying out basic functions: shipping its product, billing its customers, or generating sales reports. And those are just the cases that made the news.
The key is to understand that you don’t need a single system; you need a single process. Deterministic integrations broke the moment two systems disagreed about what a vendor record looked like. AI agents, by contrast, tolerate that inconsistency. An orchestration layer that sits on top of the systems you already have is the solution to disparate systems: your systems don’t just need to talk to each other, they need to be «happily married», tolerating each other’s flaws.
The method: map, sort into three buckets, and measure baselines
To redesign your business, you first have to understand it. And that understanding is not achieved by picking a single workflow and spending eight weeks perfecting it — it will most likely be blocked by a sibling process upstream and you’ll end up with net zero ROI. But you also can’t consume the whole business at once. The answer is to start at the department level.
Choose a department (finance, procurement, operations) and identify the «bundles» of flows that feed that department —for example, in Finance: accounts payable, accounts receivable, FP&A, billing, banking, reconciliations. For each flow, map seven details:
- The happy path: what this flow is responsible for and what happens in the ideal scenario.
- The exceptions: what percentage of the volume leaves the happy path, where it goes, who it involves, what the cycle time to resolve it is, and how much an error costs here.
- What’s upstream and downstream: how the flow interacts with the others when things get delayed or fail.
- The systems of record: which ones are involved and which one wins when two of them contradict each other.
- How it varies by region, entity, subsidiary, or the acquisition it came from.
- Touch time versus elapsed time, and how that gap varies at each step.
- Each person’s AI capability in the function and how much ownership they should have over the future system.
Extracting that information requires two complementary procedures: on one hand, process mining against the systems of record to obtain actions, timestamps, performance, edits, and the reality that doesn’t match the documentation; on the other, interviews with the operators, because the reality of your organization lives in the heads of 10–20 people who have been doing that exact work for your exact company for years. And for your AI to work, it has to be adopted by those people. Doing only one of the two leaves an incomplete picture.
Agents that work: they’re not just calls to an LLM
Process redesign is a classification exercise. Each step of a process falls into one of three buckets:
- Deterministic. If X then Y, no judgment. If the invoice is below an amount threshold and matches the purchase order and the delivery note, it gets paid. These actions are best as pure software: cheap, auditable, deterministic (it never hallucinates) and fast. You don’t need a sophisticated model call to do what ordinary code can do.
- Agency. If you have thousands of past examples of humans making a judgment call with the outcome recorded, and the risk is low (deal desk approvals, GL accounting coding), then by all means use an LLM for the judgment. Especially if the output is a yes/no, a «hand this off to that team», a flag/no-flag, or a match/no-match. Here you’re judging the difficulty of the action, not the thinking.
- Human in the loop. For steps that are too risky or lack enough historical context, keep the person in the loop: the cost of an agent getting the action wrong is simply too high. But put all the relevant evidence in front of the human at the moment of deciding. For example, the agent detects a discrepancy between an invoice and a purchase order and presents the person with 3 options: approve, reject, or give feedback and hand off. The agent has saved the person 40 minutes of digging through emails and records, so they can decide in 30 seconds.
Once each step is classified, you can turn a 25-step process into a cluster of 3 agents, with deterministic steps before and after and 2 human-in-the-loop checkpoints to unblock. That re-engineering work, together with the agents themselves, is where all the ROI lives.
Then, set KPI baselines before building anything. Your goal is to calculate the numbers behind the process you’re solving, where and how they’re measured today. If you can’t do that, the project is doomed to fail: in 12 months you need to be able to say «we were at X and now we’re at 3X, or 10X», thanks to the agents. Only then can you call it a success.
The real-world case: a 12-step bank reconciliation turned into 3
Let’s see, again, what it looks like in practice. Vas and his team re-engineered a global company that reconciled more than 300 bank accounts every month. Two-thirds were managed by an offshore team and the rest was split between two other regions in three different formats, but everything in Excel. There were more than 12,000 open reconciliation items, and 4 days at the start of each month were spent just fetching statements. Their reconciliation process took up almost the entire month, every month.
The previous flow was a pile of waiting: tracking down and collecting statements from each bank in its own format; normalizing them into the regional ledger; extracting the accounting statement; matching line by line; flagging what doesn’t match; writing to a local controller to ask for context; waiting for their reply; chasing them if they didn’t answer; posting the adjustment; consolidating the region; and repeating the whole process for the other two regions, each in its own format. If you speed up each step, the matching speeds up. The problem is that matching was never the problem: the 4 days of waiting for statements, the email to a controller in another time zone, and the reply that took 3 days — that was the problem.
The new process had three steps:
- Statements arrive through a feed, conveyor-belt style, instead of being chased down. This has nothing to do with AI.
- Everything that can be matched by rules is matched automatically; if not, an agent assembles the case end to end: with the item itself, the historical categorizations, the evidence gathered from multiple systems of record, and a proposed next step.
- Finally, a human works their exceptions queue with the evidence prepared for review, instead of manually digging through data scattered across ERPs and spreadsheets.
The searching, the emailing, the waiting, the re-keying, and the regional consolidations disappeared entirely. That is the difference between an agent system that saves minutes and hours, and an agent system that saves weeks.
The results when it’s done right
When the work is approached this way, the impact touches the four levers that matter in an AI transformation: cost (ideally lower), revenue (ideally higher), time (ideally faster) and risk (ideally lower). Across Varick’s deployments, about half of them in public companies, here’s what moved, lever by lever:
- Time. Month-end close went from 18–22 days to 7–9 days. Supply-chain disruptions are now classified in under 6 hours, versus several days.
- Revenue. Deals used to sit stalled for an average of 23 days; now it’s 6 days. Salespeople’s administrative time dropped from 38% of the week to 14%, and that time went back into selling.
- Cost. Accounts-payable exception handling went from 600–800 invoices a month to fewer than 50. In one marketing organization, 8% to 12% of the media budget was recovered from pacing errors that previously only surfaced at month-end, saving millions per quarter.
- Risk. Payroll corrections fell by 90%, because reconciliation between systems ran before payroll, not after. 80% of employee-support queries were answered using the company’s own policy documents, while edge cases kept escalating to an HR person.
In total, the value delivered across that set of deployments exceeded $100 million, and it was co-created and measured together with the clients.
Why it isn’t more common: interference, risk, and operators’ fear
If the method works, why do so few people apply it? For three reasons that are less technological and more human.
First, nobody in the chain owns the process. Whoever signs an AI contract today can control the tools and the vendor selection, but they certainly don’t control the process. Nobody in that role can walk into finance and say that their 14-step process should have 5. So nobody does it: you «apply AI» to what you already have and end up with faster garbage. Redesigning a process that spans four departments requires someone able to tell all four of them that the process changes. Very few people in a company can do that; it has to come from the top.
Second, AI is perceived as risky. The status quo feels «safe» to most people: nobody gets promoted because the AI works, but you can be fired if it doesn’t — even if clinging to the status quo means slowly letting the company die.
Third, the people doing the work today have to want the new system. The accounts-payable manager and the finance analysts have to adopt it and push it forward tomorrow. And they have to disclose information they believe could replace them, even though in most cases it won’t. Back in the 1990s, when Hammer tried to eliminate a handoff, that meant firing the person whose job it was and asking everyone else to change how they worked, while the «software» of the time couldn’t support that change. That’s why, when the consultants left, the structure and the process reverted to their original state: riddled with inefficiencies and errors.
Today, two things are fundamentally different. First, native AI tools offer an incredibly fluid software state that adapts to change. An agent installed in your system of record can execute handoffs that previously depended on people, handle the discrepancies of deterministic software at the same time, and is immune to the normal variance in humans. Second, the work eliminated first is almost entirely coordination: chasing, waiting, escalating, classifying. After those improvements and a real AI transformation, what remains is high-judgment, high-leverage work — which is what your best people should be spending all their time on anyway.
The single-vendor trap
Traditional consultancies are decent at process work, it has to be said: if you want an elaborate illustration of a 15-step process spanning 10 countries and 3 entities, they’ll produce the prettiest PowerPoint you’ve ever seen for $300,000. What they don’t know how to do is the other half, the most important one: knowing what a model can be trusted with, how much an agent that runs 40,000 times a month costs, which model to use for which type of task, how to design an optimal evaluation set, and which of the three buckets each step falls into. So your redesign is created by consultants who are guessing.
The AI labs, by contrast, have the opposite problem: they can build an agent, but they’ve never sat down with finance and operations to tear apart a flow where both departments argue about who owns what and who is upstream of whom. So they glue AI onto a broken process and call it «automated», instead of gutting it and redesigning it. And the biggest «applied AI» labs will force you to marry their models forever. Betting your company’s entire intelligence embedding on a single vendor is suicide: tomorrow, when they rate-limit, raise prices, or retire the model you run on, you’re left with the mess and the bill. Switching the endpoint from Claude to Gemini or DeepSeek isn’t as simple as it looks: re-running the evaluations and re-determining which reasoning level to use per call is laborious, and the labs won’t help you.
What you need is the best of both worlds combined: people who have actually run a finance, operations, sales, or HR function; engineers capable of taking production software into your ERPs and CRMs; and AI engineers capable of building vendor-neutral frameworks with governance and integrated evaluation sets. What you still need is for the team to have the process owner, the software engineers, and the AI engineers in the same room on the project — and almost nobody has all three.
Conclusion
The lesson of this thread is as old as it is current: technology never replaced a bad process; it accelerated it. The lost time wasn’t in the work itself, but in the queues and handoffs. Before buying thousands of AI-assistant licenses, ask yourself which process you’re going to redesign and who has the authority to change it. Start with one department, do process mining and interview the operators, classify each step as deterministic, agentic, or human-in-the-loop, measure the baselines, and only then build.
At BAOSS we’ve spent years applying this same discipline: helping companies redesign processes before automating them, with solid AI agents, governance, and ROI measurement from day one. We don’t sell «applying AI»; we sell transformation that gets measured. If you’re at that point, let’s talk about how to get started.
Article inspired by the thread from Vas (@vasuman, CEO of Varick Agents), «AI Adoption Without Process Change» (September 2026). The figures cited come from public sources (Harvard Business Review 1990, the UK Government’s Copilot trial, the TSB and Zimmer Biomet cases, published metrics from the Varick deployment).