Building got cheap. Deciding what to build is the bottleneck

The request arrives as a solution

My colleague Aatif Basheer has spent years doing this work inside large organisations, and he describes the pattern more precisely than anyone else I work with. It goes like this.

A senior stakeholder comes to a delivery team and says: I need this report, every day, in a dashboard. The team builds the report, every day, in a dashboard. Everybody is satisfied and the exercise was almost entirely wasted, because the stakeholder did not want a report and did not want a dashboard. They wanted to know one number, and to be told when it moved.

Nobody in that chain did anything wrong by the standards they were measured against. The request was specific, the delivery was accurate. What was missing is the step where somebody says: that is the solution you have imagined. Tell me the outcome you want, and let us choose the tactic, because we understand the technology better than you do.

That step is the capability most large organisations do not have. It is not a tooling problem and it is not a training-course problem in the usual sense. It is about whether a team has the standing, and the vocabulary, to push back on an ask without it being read as obstruction.

Cost used to do this job for us

For most of the history of enterprise software, the wrong idea died of natural causes. It went for an estimate, the estimate said nine months and four engineers, and somebody senior decided it was not worth it. The gate was not wisdom. It was expense.

Generative tools took the expense out. A competent person can now stand up a working internal tool in an afternoon, and an agent that does something genuinely useful in a week. This is the good news and it is real.

The problem is that the gate went with it. Building is now cheap and deciding what to build has become the bottleneck, except most organisations have not noticed the swap and still have all their governance pointed at the old constraint. They still review spend carefully. Almost nobody reviews whether the thing being built should exist.

This is the mechanism underneath a lot of failed AI programmes, and it is a different failure from the ones we catalogued in why AI pilots fail. Those pilots mostly died of neglect. This one dies of abundance.

What it looks like from the inside

The symptom that gives it away is duplication. Once a few dozen people can each build their own agent, they do, and several of them build the same one. Three teams have an agent that summarises the same category of document, none of them knows about the others, and no two behave identically.

Ask an organisation in that state a few simple questions and the answers usually run out fast. How many agents exist? Who owns each one? Which are personal and which are shared? Where is the list? Is there a list?

There is rarely a registry, rarely an owner, and rarely any agreement on what is allowed to be shared. Aatif calls the missing piece an agent ontology, which is a precise way of saying nobody has decided what categories of thing exist, or where they live. The result is not dangerous on day one. It becomes expensive by month six, when the same work has been done four times and nobody can retire any of it because nobody knows who depends on what.

The questions worth asking before the rollout, not after

Most organisations answer these questions retrospectively, after somebody has built something awkward. They are cheaper to answer first, and they are mostly questions about permissions rather than policy.

• As an ordinary member of staff, what can I actually do in the tools we have licensed? Not what the vendor's marketing says. What our administrators have enabled.
• Can I connect the AI to our other systems, and which ones?
• Can I create a reusable skill, prompt or agent? If I can, can I share it, and with whom?
• Is there a shared library, or does everything I build live in my own account and leave with me?
• Who administers this centrally, and do they know how many things have been created?
• What proportion of the work in question is already being done with AI, quietly, by people who never told anyone?

That last one is usually the most revealing. Existing informal use is an asset, and the UK evidence agrees: the 2026 SKAI employer guide published with Skills England says explicitly that training should recognise and build on existing informal or self-taught AI use rather than assuming a zero start. Organisations that treat their quiet early adopters as beginners lose them.

Challenging the ask is not tearing things down

There is an important limit here, and Aatif is more insistent about it than I would naturally be. Teaching a delivery team to challenge the ask is not the same as teaching them to deconstruct the organisation.

In a large business, a workforce of people who have all just been told to question everything is not an improvement. It is destabilising, and the people who suffer for it are the ones who took the message most seriously. The scope has to be narrow and specific: when a new request arrives, interrogate the request. Not the org chart, not the operating model, not last year's decisions.

So the target is narrow. On a new ask, or a change to an existing one, the team is equipped to step back and establish the outcome before agreeing the output. That is all. It sounds modest and it changes a surprising amount, because most of the waste enters at exactly that moment.

Design native, not design fluent

A related trap is in how this capability gets described when somebody tries to buy it. The usual phrase is design fluency, and fluency implies mastery. Nobody is proposing that engineers or analysts become designers, and promising that sets an expectation the training cannot meet and the audience does not want.

The more accurate word is native. The aim is people who instinctively apply a few design principles inside a job that is not a design job. Knowing that a field which cannot be edited should not look editable. Knowing that the person who asked for the dashboard has never once opened a dashboard. Knowing to watch somebody use the thing before declaring it finished.

That is a small body of knowledge and it transfers. It is also the part that does not go out of date when the tools change, which matters more than it used to.

It is a shift in thinking, not a new technology to learn

The framing I have found most useful comes from Aatif, and it is about maps. Before maps, you navigated by landmarks and memory and asking people. Maps did not simply add a tool to that process. They changed what kind of question you could ask about getting somewhere, and eventually what it meant to know a place at all.

His argument is that AI sits in the same category. Treating it as a technology to be learned, like a new framework or a new platform, produces training that teaches the interface and misses the shift. What actually changes is which questions are worth asking, and what you assume has to be true about how work gets done.

That is why the useful version of this training is not a tour of features. It is time spent on real requests, with somebody experienced asking why this, why now, and what happens if we do not build it at all. Our post on which workflow to automate first is the tactical version of the same instinct, and levels of AI autonomy gives you the vocabulary for how much of a decision you are actually handing over.

Where organisations actually are

It would be easy to read all of this as a problem belonging to unusually disorganised companies. The UK data suggests otherwise.

The SKAI employer guide, produced in June 2026 by Dr Nisreen Ameen at Royal Holloway under a British Academy fellowship with Skills England, placed its 536 surveyed organisations on an adoption pathway. Awareness accounted for 21% and exploration 19%. Integration was 7%, strategy 4%, and scaling 1%. So the overwhelming majority are experimenting without an operating model, which is precisely the condition in which duplicated agents and unchallenged requests multiply.

The same report lists, among its thirteen common pitfalls, that organisations often have no clear governance or strategic direction for AI use, and that unclear rules, responsibilities and goals limit adoption and reduce confidence. Separately, the Office for National Statistics found that only 11% of UK businesses with 10 or more employees had given AI training to more than half their workforce, while around 35% were already using AI.

Read together: the tools are in, the capability is not, and the decision-making layer that should sit between them mostly does not exist yet.

What to do about it

Four things, roughly in order, none of which requires a transformation programme.

• Find out what has already been built. Before any policy, take an inventory. It is almost always larger and messier than leadership expects, and it is the only honest starting point.
• Answer the permissions questions above, in writing, and tell people the answers. Most shadow use is not defiance. It is people filling a silence.
• Give one team explicit permission to interrogate incoming requests, and see what happens. Pick a team with a steady flow of stakeholder asks. Measure how many requests change shape once somebody asks about the outcome.
• Train the judgement, not the interface. The tools will change again within the year. Whether your people can tell a good request from a badly specified one will not go out of date, which is the argument we make at more length in AI training for business.

If you want somebody from outside to have this conversation with your teams, that is much of what our AI consultancy does. There is a reason organisations bring in an external voice for it: the person who has been raising it internally for two years has usually stopped being heard, and the same sentence lands differently from a stranger who has no stake in the last decision.