There is a conversation we keep having with leadership teams, and it always has the same shape. Real money has gone into AI: licences, tokens, a pilot or three, sometimes a whole "AI-first" programme with its own slide template. Everyone can point at activity. Then you ask what has changed in the day-to-day running of the business — how long the close takes, how fast quotes go out, how much of the team's week is still manual — and the answer, delivered with some embarrassment, is nothing.
The data says this is the norm, not the exception. MIT's NANDA group reviewed three hundred enterprise deployments and found 95% of generative AI pilots delivered no measurable return to the P&L. BCG puts the share of companies generating AI value at scale in the low single digits. RAND found AI projects failing at more than double the rate of ordinary IT projects. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027.
Here is the detail worth staring at: those failure rates have stayed flat across every model generation. The models improved enormously; the enterprise results did not. Which tells you something most AI vendors would rather you didn't notice — the model was never the bottleneck.
The exception that explains everything
One group has extracted enormous value from exactly the same models: software engineers. Coding assistants and agents have delivered the biggest productivity jump engineering has seen in decades, with measured gains of 50% and up on real tasks.
Why there and nowhere else? Because engineering work has four properties almost no other business function has. It is bounded (a task lives in a file, with explicit dependencies), checkable (tests and compilers give feedback in seconds), structured (versioned, deterministic, replayable), and verifiable (a reviewer can approve a diff in minutes).
Now hold your month-end close, your quoting process, or your maintenance scheduling up against that list. The work spans five systems that do not share state, the documented process differs from the real one, and the output takes a senior person days to verify. Pointing a raw model at work like that produces negative return: the operator still does the job, and now also corrects the AI.
The gap between those two worlds is not closed by a smarter model. It is closed by engineering and process work, and the businesses that fail skip it in one of four predictable ways.
Failure mode one: building for the process on paper
The strongest predictor that an AI project will fail is that the team started building before anyone watched the work being done.
Every business has two versions of every process: the one in the SOP, and the one that actually happens at 4:45pm on the last working day of the month. The real one contains the spreadsheet someone always checks first, the colleague who gets emailed directly because the system notification is broken, the fifteen exception types nobody wrote down, and the unwritten rule about which orders the boss wants to see personally. In our audits, the divergence between the documented process and the real one is routinely 30% of the volume, and in exception-heavy work it can be most of it.
Automate the paper process and you handle the clean majority while breaking on the exceptions — and the exceptions were always where the time went. The team ends up with more work than before, and the pilot dies with a shrug. The fix is unglamorous: sit with the people doing the work, watch it end to end, and map what actually happens before a model is involved. It feels like consulting rather than AI, which is exactly why it gets skipped.
Failure mode two: asking the model to do everything
Once a team has an LLM, every problem starts to look like a prompt. Extract a value? Ask the model. Compare two numbers? Ask the model. Route a result? Ask the model. The result is a system that is slow, expensive, and wrong just often enough to be unshippable — a hallucination is a quirk in a chatbot and a liability in accounts payable.
The production agents that survive look boring by comparison. They are mostly ordinary, deterministic code — queries, comparisons, branching — with a model called only at the points where judgment genuinely lives: reading an unstructured document, classifying an exception, drafting something for a human to approve. Deterministic steps are fast, cheap, and auditable by construction. Boring is not a compromise; boring is the goal.
Failure mode three: shadow agents
This one is silent until roughly month six. Given accessible AI tools, every capable employee becomes their own automation department. One person builds an invoice classifier, another wires up a report generator, a third has a personal agent summarising the CRM before every review meeting. Multiply across a company and you get dozens of workflows, each built differently, each solving overlapping problems, none owned by anyone.
Then a model gets deprecated, an API changes, or the builder leaves — and half of them break at once. Nobody is on call, nobody knows which ones matter, and the engineering team inherits a janitorial job it never agreed to. It is shadow IT all over again, except the shadow systems now take actions.
The fix has to be architectural from day one: one platform that carries the shared infrastructure — integrations, approvals, logging, model routing, knowledge — with every new agent landing as configuration on top of it rather than as a new island. That structure is also where the economics turn: the first agent on a platform is the slowest to ship, and each one after it lands faster because the scaffolding already exists.
Failure mode four: declaring it done
Traditional software stays built. AI does not. Models get retired — the major labs have deprecated a dozen between them in eighteen months — prices move quarterly, and your own workflow drifts underneath the agent as the business changes. A deployment that was accurate in March and untouched since will be quietly wrong by autumn, and a system that is "done" is a system that is decaying.
The deployments that pay off for years are the ones somebody operates: watching accuracy, absorbing model changes behind a routing layer, retiring agents that stopped earning their keep, and feeding every human correction back into the system. AI is infrastructure with a maintenance bill, and pretending otherwise just moves the bill to a worse address.
What the successful few do
Strip the survivor stories down and the same five habits appear every time:
- They watch the work before they build. The real process, not the documented one, defines what gets automated.
- They decompose until most of the system is deterministic. The model goes only where judgment lives.
- They build on one platform. Every agent shares infrastructure; sprawl is dead on arrival.
- They stay model-agnostic. Each step routes to the best model available, so a lab's release schedule never becomes their outage.
- They operate it continuously. Someone owns the system after go-live, permanently.
None of this is a secret, and none of it requires a breakthrough. It is disciplined engineering applied to operations — which is presumably why so few AI initiatives, staffed for demos and announcements, ever get around to it.
It is also, not coincidentally, the shape of what we sell: a fixed-price audit that maps the real workflow first, agents built mostly from deterministic steps on a shared platform, and a subscription under which we operate what we build, permanently. If your AI programme has produced more decks than change, the models were never your problem — and the fix is more available than you think.