From potential to kinetic: why execution, not models, decides who gets value from agents

Every organisation I talk to has potential energy stored in AI. Licences paid for, pilots built, a demo that got applause in the boardroom. Very little of it is moving.

The numbers are blunt. By McKinsey’s count, four in ten large organisations say they are scaling agents. Thirty-seven in a hundred report any profit effect from AI at all. Six in a hundred report a material one. That six was six a year earlier too.¹

Nobody in that survey is short of models. What is short is the conversion: the part that turns stored potential into motion. I have spent the last two years running teams that build agentic systems for enterprises, in banks, insurers, telecoms and public bodies across Europe and the Middle East, and I have gone looking in the public record for the organisations that did convert. This is what they did differently.

Inertia

Start with where the effort goes. Almost everyone pointed AI at the part of the lifecycle that is easiest to demo: writing code. That is a quarter to a third of delivering a system. Automate it brilliantly and you save ten to fifteen percent of the whole. The organisations that got twenty-five to thirty changed the entire process: how they decide what to build, how they prove it works, and how they run it afterwards.²

Building is now the easy part. Deciding, proving and operating are the work.

The cases with a real number behind them, in a results statement or a journal rather than a keynote, look nothing like the demos. An Australian bank resolves 86% of its digital conversations end to end, about two million a month. A European telecom holds end-to-end resolution at or above 70% on roughly sixty million conversations a month, across two consecutive investor decks. A Singapore bank has around eighty agents assembling credit memos in hours, with every output reviewed by a person before it acts. A US retailer put a negotiation bot in front of twenty thousand tail suppliers nobody had ever negotiated with; it closed 68% of them at an average 3% saving.³

Different industries, four continents, the same models anyone can buy. What they share is not the technology. Look at the second half of every line: a rate with a denominator, a human in the decision, a segment where nobody was doing the work before.

Five decisions

Read enough of these cases and five traits recur. None is about which model. All are decisions a leader makes, or fails to make, before anyone writes code.

They picked work humans did not do, or did slowly and reviewably. They put the agent inside a workflow with a human decision in it. They equipped their own people before their customers. They built on data they already trusted for something else. And they named an owner in the business, then published a rate with a denominator.

Turned around, those are five questions to put to anyone offering to build you agents. Including us.

Is this an agent’s job? The Australian bank’s first attempt bolted a voice bot onto a call centre and announced redundancies. Call volumes went up; within four weeks it reversed and apologised. The second attempt, the one with the 86%, is a router. For every request it asks what kind of job this is: a simple query goes to conversational AI, a content question to retrieval, a regulated step to deterministic code, and a vulnerable customer to a person. The language model handles what it is good at. Ask your partner what their rule is for deciding when an agent is the wrong answer. If they do not have one, everything will become an agent, and most of it should not.

Is the data ready? Not “is it clean”; it never will be. The question is whether the people who know the data are inside the loop, during the build and after. The same bank built a fraud agent in about three months that now monitors eighty million signals a day and has authored most of its card-fraud rules, and every rule it proposes, the fraud team approves before it goes live. Contrast the voice agent that a fast-food chain put in more than a hundred drive-thrus: it passed in test, failed on real accents and background noise, and stayed wrong for three years, because the staff had no way to correct it and nobody measured it centrally. Data is never finished. Keep the people who know it inside the loop, so the agent is tuned by the business, not by the vendor.⁴

How will we know it works? The telecom chose to be judged on end-to-end resolution and customer satisfaction, country by country, each with a baseline recorded before go-live. First-time resolution in the first market went from 15% to 60%, and has held. Compare the fintech that measured its assistant on cost: the headline looked wonderful for about fifteen months, until the CEO said publicly that quality had slipped and people were being hired back. The assistant stayed; the metric changed. If the only number is cost, you find out late. Ask for the rate, the denominator, and the date of the baseline.⁵

Who owns it after go-live? Every strong case has a named owner in the function where the agent works: the fraud team approves the rules, the physician signs the note, the buyer sets the guardrails. Ownership is not a name on a form. It is a loop someone runs every month because their job depends on the outcome: observe the traces, overrides and cost per outcome; re-run the evaluations; tune the prompts, data and thresholds; decide whether the agent earns more autonomy or less. If, on the day your delivery partner leaves, the answer to “who owns this” is “IT, generally”, the agent is an orphan.

How fast is safe? This one is about us, the builders, and nobody puts it on a slide. Every system in your organisation is now being built with agents, whether or not it ships one. The controlled evidence is sharper than the headlines: 26% more tasks completed on well-specified work across nearly five thousand developers; and in the one randomised study on real issues, experienced engineers were 19% slower with AI in code they already knew. Telemetry across twenty-two thousand developers explains both: output went up, review time went up four times faster, and bugs per developer rose by half.⁶ So the question for your partner is “how fast is safe?”, and the answer should be rules, not reassurance. Ours: one small iteration at a time, review hours budgeted up front, a written scope before the agent builds, evaluation as the gate, and agent work logged and costed like a person’s.

Friction

People hear “human in the loop” and think “slower”. The record says the opposite. Twelve of fourteen durable back-office cases I could find are propose-and-decide: the system proposes, a person decides. The one large randomised field study of agent-assist in customer support found 14% more issues resolved per hour overall, and 34% for new staff.⁷

The human is not drag. The human is the brake that lets you drive a fast car. And the brake comes off a rung at a time, from suggesting, to acting with approval, to acting within guardrails, to running alone on defined low-risk work, when the numbers say so, not when everyone feels comfortable. Autonomy is earned by evidence, not granted by comfort.

What is still hard

Three things I will not pretend are solved. Agents produce code faster than people can review it, and review is the new bottleneck; we budget for it explicitly and it still bites. Testing something that does not give the same answer twice is a discipline most teams have not built; we start from twenty to fifty real failure cases and require two experts to agree on pass or fail. And data that sits outside reach stays outside reach; no model fixes that.

What I would do on Monday

Pick one process where people do nothing today, or do it slowly and reviewably, and write down why it is an agent’s job and not a workflow. Name the business owner now, before a line of code, and agree the one rate with a denominator they will report every month. Record the baseline this week, because you will not be able to reconstruct it in month four.

Footnotes

1. McKinsey, The State of AI in 2026, August 2026, n=1,719. ↩

2. Bain, Technology Report 2025: coding and testing are 25–35% of the lifecycle. ↩

3. Commonwealth Bank of Australia FY26 results; Vodafone investor decks, November 2025 and May 2026; DBS, Computer Weekly, July 2026; Walmart in Harvard Business Review, 2022. ↩

4. CBA, April 2026, on the fraud agent; the drive-thru timeline from the McDonald’s–IBM programme 2021–24 and the 2026 restart. ↩

5. Vodafone, as above; Klarna, Bloomberg May 2025 and the Q3 2025 earnings call. ↩

6. Cui et al. on 4,867 developers; METR, July 2025 and February 2026; Faros AI telemetry across 22,000 developers, April 2026. ↩

7. Brynjolfsson, Li and Raymond, Quarterly Journal of Economics, April 2025. The twelve-of-fourteen count is my own review of published cases, September 2026. ↩