Three things most organisations are missing before they start with AI agents

There's a pattern that keeps showing up. An organisation gets excited about AI agents. They've seen the demos, read the announcements, maybe even attended a Microsoft event. Someone senior says "we should be doing this." And they're right - they should. The technology genuinely is as capable as the hype suggests.

But then nothing happens. Or worse, something happens - a proof of concept gets built, it works well enough in a demo, and then it quietly dies. Six months later they're still talking about it in steering meetings. The vendor has moved on. The opportunity cost is real but invisible.

This isn't a technology problem. The platforms are mature. The models are good. The tooling is accessible. What's missing is structural - three things that sit underneath the technology and determine whether an organisation actually ships anything or just talks about it.

1. A decision group that exists to go faster

Not a governance committee. Not an approval board. A small group of people - business and IT together - who meet regularly and have the authority to say yes to things.

That distinction matters. Most organisations already have governance structures. The problem is that those structures were designed to manage risk in a world where technology changes were expensive and hard to reverse. They're built to slow things down, and they're very good at it.

AI decisions are different. Most of them are what Jeff Bezos calls Type 2 decisions - reversible, low-consequence choices that should be made quickly by a small group. The alternative, he argues, is predictable:

"As organisations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."

• Jeff Bezos, 2016 Letter to Shareholders

McKinsey's research backs this up. Their 2025 State of AI report found that the model that works is "centralised governance with federated execution" - a single group that sets direction and makes decisions, with teams free to execute without coming back for approval at every step. They're blunt about the alternative: "multiple committees with people opining" that result in nothing getting denied and nothing getting done.

The decision group doesn't need to be large. Three to five people is usually right. It needs a senior sponsor, someone from the business side who owns the problems, and someone from IT who understands what's feasible. It meets fortnightly or monthly. Its job is not to evaluate technology. Its job is to decide which problems are worth solving, and then get out of the way.

The conversations this group has are often more valuable than the agents they end up building. When business and IT leaders sit in the same room and talk about real operational problems - not in the language of technology, but in the language of what's actually slowing the organisation down - the right ideas surface naturally.

2. A value pipeline

Ask most organisations how they decide which AI projects to pursue and you'll get one of two answers: the CEO saw a demo and told someone to build it, or a team put their hand up because they had a problem and knew someone who could help.

Neither of those is a strategy. Both produce the same result - a handful of disconnected pilots, no way to compare them, and no framework for deciding what comes next.

A value pipeline is the missing piece. It's a structured way to capture ideas from across the organisation, score them against consistent criteria, and stack-rank them so the decision group has something real to work with.

This doesn't have to be complicated. A simple intake process - surveys, a submission form, interviews during workshops - feeding into a scoring framework that weighs business impact against feasibility. Microsoft publishes a useful one called BXT (Business value, Experience, Technical feasibility) that works well for this purpose.

The point is to create a repeatable process, not a one-off exercise. Ideas should flow in continuously, get scored consistently, and sit in a backlog that the decision group reviews regularly. Without this, you're relying on whoever happens to be loudest or most politically connected to set the agenda.

Harvard Business Review's analytics research underlines the cost of getting this wrong. Their 2025 survey found that while 59% of organisations have AI in production, most are focused on incremental efficiency gains rather than strategic value. They're automating the easy things, not the important ones. That's what happens when there's no pipeline forcing the question: "Is this the highest-value thing we could be working on?"

3. A way to run experiments that actually teaches you something

Here is the number that should worry everyone: Gartner predicted that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. The actual figure turned out to be over 50%. More than half of all gen AI pilots never made it to production. And looking ahead, Gartner expects 60% of AI projects to be cancelled by the end of 2026.

The usual explanation is "poor data quality" or "unclear ROI." Those are real factors, but they're symptoms. The root cause is that most organisations treat a proof of concept as a mini-project rather than an experiment.

There's a difference. A project has a scope, a timeline, and an expected outcome. An experiment has a hypothesis, a cheap way to test it, and a willingness to learn from whatever happens - including when the hypothesis is wrong.

Jeff Bezos has been saying this for years. His line about Amazon's success being "a function of how many experiments we do per year, per month, per week, per day" isn't motivational fluff - it's an operating principle. The economic logic is straightforward: if you reduce the cost of each experiment, you can run more of them. If you run more of them, you find more things that work. And as he puts it, "big winners pay for so many experiments."

Eric Ries, who popularised the lean startup methodology, makes a related but subtler point. He actually dislikes the phrase "fail fast" - he thinks it misrepresents what good experimentation looks like. The goal isn't to fail. The goal is validated learning: structuring each experiment so it teaches you something specific, quickly and cheaply, regardless of whether the outcome is what you hoped for. That distinction matters, because "fail fast" without structure is just failing.

In practice, this means PoCs need to be time-boxed (two to four weeks, not two to four months), built around a specific hypothesis ("We believe automating invoice matching will reduce processing time by 60%"), and evaluated on whether the hypothesis was confirmed or disproven - not on whether the demo looked impressive.

It also means the organisation needs to be culturally comfortable with experiments that don't work out. Amy Edmondson's research at Harvard Business School on psychological safety is relevant here. She found that higher-performing hospital teams reported more errors than lower-performing ones - not because they made more mistakes, but because they felt safe enough to surface them. The same principle applies to PoCs. If the team is afraid that a failed experiment will reflect badly on them, they'll either avoid running experiments or they'll quietly bury the ones that don't work. Either way, the organisation stops learning.

These three things work together

It's tempting to treat these as separate problems, but they're connected. The decision group creates institutional permission to move. The value pipeline gives that group something substantive to decide on. And a disciplined approach to experiments means each decision gets tested quickly and cheaply, with results feeding back into the pipeline.

Without the decision group, ideas stall in committee. Without the value pipeline, the decision group is guessing. Without structured experiments, good decisions never get validated.

None of this requires new technology. It requires a small amount of structure, a group of people willing to meet regularly, and a cultural willingness to treat AI adoption as a series of small bets rather than a single large one.

The organisations that are actually getting value from AI agents aren't the ones with the biggest budgets or the most advanced technology stacks. They're the ones that built the plumbing first.