How would you know it worked?
By Anthony Odole · September 3, 2026 · 10 min read
MIT's research puts the share of generative AI pilots producing measurable profit-and-loss impact at about five percent. The root cause named most consistently across the wider literature is not model quality or integration difficulty. It's this:
The absence of a measurable business objective tied to the initiative from day one — without a production success metric, there is no forcing function to complete the journey from experiment to deployment.
I'd put it more bluntly. Most AI initiatives cannot fail, because nobody defined what failure would look like. An initiative that cannot fail also cannot succeed, and what it does instead is continue — consuming budget, generating activity, and producing a quarterly update that describes effort rather than outcome.
This is old ground for anyone who has done benefits realisation. What's new is that agents fail in a specific way that makes the usual instrumentation actively misleading.
The agent that succeeded at the wrong thing
An example from my own system, and it's the one I'd want a CTO to take away.
We have AI employees that handle inbound questions. One of them received a question from a business owner about their advertising — something that was squarely within another agent's remit. The agent recognised it wasn't its own job. It responded helpfully. It told the owner where they could go and look at the data themselves.
Every metric said this was a success. The message was received. A reply was generated. It was on-topic, accurate, polite, and delivered within the response window. No error was logged anywhere. On every dashboard we had, that interaction is indistinguishable from an excellent one.
It was a failure. The correct behaviour was to hand the owner to the colleague whose actual job this was — by name, with a warm introduction. Instead the agent politely returned the work to the customer and closed the loop on itself. We had built a team of specialists who would decline gracefully and never once say "let me get Maxwell, this is his area."
You cannot find that with response-rate metrics, latency metrics, error rates, or satisfaction scores. Every one of them was green. The failure lives in the gap between the agent completed its task and the business got what it needed, and that gap is invisible to any measurement taken from inside the agent's own frame.
Why agent metrics lie in a particular direction
Traditional software fails loudly. It throws an exception, returns a 500, breaks a test. The instrumentation we've built over thirty years is oriented toward catching things that went wrong, and it's good at it.
Agents fail differently, in three ways that all defeat that instrumentation.
They fail by doing nothing, silently. There is no exception for work not attempted. We once lost every background job in the platform for three days — the process had crashed while the container kept reporting healthy. Nothing alerted, because nothing errored. Absence of work produces no signal unless you build one deliberately, and almost nobody does, because every instinct from ordinary monitoring points the other way.
They fail by succeeding at a subtly wrong objective. The story above. The agent optimised the thing it could see.
They fail by grading themselves. If the agent that takes an action also holds the measurement of whether it worked, the metric is not independent evidence — it's the same reading taken twice by the same reader. I've written about why that separation matters and what it takes to enforce it. For measurement specifically the consequence is simple: any metric produced by the system being evaluated is not a metric, it's a self-report.
Put those together and you get the characteristic condition of a stalled AI programme: dashboards that are green, executives who are uneasy, and no way to reconcile the two. The dashboards aren't lying about what they measure. They're measuring activity, and the question is about outcomes.
Four questions to answer before you deploy
Not after. The order matters more than the content, because most of these are unrecoverable retrospectively — you cannot compute a baseline for a period you didn't measure.
1. What number moves, and who owns it?
Not "efficiency." Not "productivity." A specific figure that already exists on someone's report, with a name attached to it — because the owner of the number is the forcing function. Absent an owner, the metric becomes the AI programme's own self-assessment, and self-assessments trend positive.
The useful test: if this works, whose existing report changes, and would they notice without being told?
2. What is it now?
The baseline. Measured before deployment, over a period long enough to contain the normal variation.
This is the step most consistently skipped, and skipping it is terminal. Six months later somebody asks whether the agent helped, and the honest answer is that nobody knows, because there is nothing to compare against. What follows is a negotiation over anecdotes, which the party with the larger budget wins.
Measuring the baseline also has a useful side effect: it occasionally reveals that the problem was smaller than assumed, which is a cheap way to cancel a project that shouldn't run.
3. What would tell you it's working this week?
The business number will move slowly. Between deployment and that movement is a long silence where the programme is unfalsifiable, and unfalsifiable programmes drift.
So you need a leading indicator — something observable now that ought to precede the outcome. If the goal is faster response, measure time-to-first-substantive-reply. If it's conversion, measure how many conversations reach the point where conversion becomes possible.
The requirement: it must be measured outside the agent. Not "the agent reported it handled the enquiry." Something a different system saw.
4. What does the wrong kind of success look like?
This is the one nobody writes down, and it's the one that catches the failure I opened with.
For each intended outcome, name the way the agent could hit the metric while missing the point. Faster responses achieved by giving up sooner. More conversations handled by resolving fewer. Higher engagement produced by contacting people more often than they want. More budget efficiency produced by measuring against a broken conversion signal.
Then instrument the counter-metric. Every optimisation target needs a guardrail measuring the thing you'd sacrifice if you optimised too hard, and the guardrail must come from a different source than the target. This is the measurement expression of separation of duties, and it's cheap when you build it in and near-impossible to add convincingly after someone has started reporting the headline number upward.
The four questions, run against a real agent
Abstract criteria are easy to agree with and hard to apply, so here is the exercise done properly on a case I know well: an AI employee that handles inbound enquiries from business owners.
What number moves, and who owns it?
The answer that fails: "support efficiency." Nobody owns it, nothing reports it, and it will be computed for the first time by the person defending the programme.
The answer that works: the proportion of enquiries that reach a booked conversation — a figure the sales owner already tracks weekly and would notice moving without being told. That last property is the test. If the metric only exists because the AI project needed one, it isn't a business metric, it's a project artefact.
What is it now?
Measured over a period long enough to contain the normal swing — a quarter, not a fortnight, because a fortnight will be dominated by whatever happened that fortnight.
This is where the exercise most often kills its own project, usefully. Twice I've seen a baseline reveal the problem was a third the size everyone assumed. Both times the honest conclusion was that the initiative wasn't worth the engineering, and both times that conclusion arrived for the price of two weeks of measurement rather than two quarters of build.
What would tell you it's working this week?
The booked-conversation number will take a quarter to move. In the meantime, something observable should precede it: how many enquiries reach the point where a booking becomes possible at all.
The critical constraint is that this must be measured outside the agent. Not the agent reporting that it handled the enquiry well — a different system observing that the conversation reached a particular state. The instant the leading indicator is the agent's own assessment, you have built a machine that reports its own success and you will believe it for about six months.
What does the wrong kind of success look like?
Faster responses achieved by answering less completely. More enquiries "handled" by resolving fewer. A higher booking rate achieved by pressing people who weren't ready, which converts a future customer into a present annoyance.
So the guardrails: response completeness sampled by a human, and the rate at which booked conversations actually happen rather than being booked and abandoned. Both from sources the agent doesn't control.
Run those four questions honestly against your own case and you'll produce something that fits on one page and takes an afternoon. That page is worth more than the dashboard you'd otherwise build in month five, because it was written before anyone had a position to defend.
The measurement nobody wants to own
There's a governance problem underneath all this that I've watched go wrong more than once, and it has nothing to do with technology.
Whoever reports whether the AI is working usually also owns the AI programme. That is the same structural flaw I've written about in separating the agent that spends from the agent that judges, reproduced at the organisational level — and it's less excusable, because organisations have known how to fix this for a century.
The person presenting the number should not be the person whose budget depends on the number. In practice that means the business owner of the metric reports it, in their existing forum, in their existing format, with the AI programme appearing as one of several possible explanations for a movement rather than as the narrator.
This sounds bureaucratic. It is the difference between an initiative that can be honestly evaluated and one that produces increasingly confident reporting until someone senior loses patience — which is how most of these end, and why the ending is usually abrupt rather than considered.
What to instrument, concretely
Below the metrics sit the records that let you answer questions you haven't thought of yet. Three that I'd consider non-negotiable, all cheap on the day and unrecoverable later.
Authority at time of action. Every action an agent takes should record the level of autonomy it held at that moment — not just what it did. We stamp this on every gated action and every tool execution, which means an audit can ask "what did this agent do while operating with reduced supervision?" without reconstructing history from timestamps and deployment logs. One field. Add it before you need it.
Outcome, not just completion. Distinguish the agent finished the task from the thing the task existed for happened. These are different events, they often diverge, and if you only record the first you will never discover the second. This is the single change that would have caught my opening example.
Absence. A signal that fires when expected work doesn't happen. Scheduled scans that look for work which should have moved and hasn't — a conversation that went quiet mid-thread, a queue not draining, an agent that has been assigned something and produced nothing. Every other kind of monitoring waits for a bad event; this one waits for the absence of a good one, and it is the only thing that catches the most common agent failure.
The conversation this is really for
Most CTOs I speak to are being asked a version of "is the AI working?" by someone who has approved significant spend, and are answering with activity: interactions handled, hours saved, pilots running.
That answer holds for about two quarters. Then it stops holding, and the position becomes difficult — not because the AI failed, but because there's no way to demonstrate it succeeded, and in the absence of evidence people default to their priors. This is the same dynamic I've written about in counting infrastructure debt: the CTO knows what's true and lacks the methodology to state it in the language the executive team operates in.
The defence is built at the start, cheaply, by writing down four things before anyone deploys anything. It takes an afternoon. It is worth more than a quarter of engineering effort spent later trying to reconstruct evidence from systems that weren't recording it.
And there's a harder benefit, which is the real reason to do it. If you answer those four questions honestly and discover you can't name a number, or nobody owns it, or the baseline would be too expensive to establish — you have learned, for the cost of an afternoon, that this initiative was never going to be able to prove its value.
That's not a failure. That's the cheapest possible version of a discovery most organisations are currently making eighteen months and several million pounds later.
Architecture first. Technology second.
If you can't name the number, or nobody owns it, or the baseline no longer exists — you've found the thing that will end this programme in two quarters.
Book an Enterprise AI Strategy Briefing →
— Anthony Odole · ex-IBM Senior Managing Consultant · 18 years in enterprise architecture · now building and running a multi-agent platform