Letting the people who do the work build their own AI tools is one of the fastest ways I know to get real value from AI. That might be someone in operations, a customer success manager or an analyst in finance. I would do it again without hesitation.

But there is a bill that arrives later, and almost nobody plans for it. Six months on, some of those tools have quietly stopped being experiments. A workflow the business depends on now runs on something one person built, on their own account, with no documentation and nobody else who understands it.

The answer is not to stop people building. It is to decide, before you need to, how a tool goes from experiment to something the organisation owns. And to be just as clear about what stays an experiment and gets switched off.

Letting people build works

The people closest to the work know where the friction is. They know which report eats half of every Monday, which customer query needs the same five lookups every time it comes in, and which month-end reconciliation means copying numbers between systems by hand. For years the only route to fixing those things was an engineering roadmap, where they competed with product work and usually lost.

AI changed the economics. A useful tool can now be built by someone who has never shipped production code. It takes days, not quarters, and it solves problems nobody would ever have prioritised.

The speed is the point. It is also what makes the approach worth the effort of setting up properly.

I wrote previously about the coordination layer, and how the hard part of an AI rollout was not the tools but the policy, approvals and framework that let non-technical teams build for themselves. This post is about what happens after that works.

Six months later

The pattern is consistent. A tool starts as one person’s shortcut. They mention it to a colleague. It gets shared with the team. A few weeks later it is simply how the work gets done. Nobody decided this. It just happened.

The sharing is informal. A link dropped in a chat thread. A prompt pasted into someone else’s account and tweaked until it is a slightly different tool. Other teams who would benefit never hear about it. The ones who do are each running their own variant, and nobody knows which one is right.

The failure modes are specific and predictable. The builder goes on holiday, or leaves. A model update changes the output and nobody notices for weeks. The API key sits on a personal account. The prompt has been edited so many times that no one can explain why it works, only that it does.

Then there is the data. Ask where the tool’s information comes from and you often get a shrug. It might be a spreadsheet someone downloaded months ago, or a source nobody has checked since the day it was connected. The output looks authoritative, so people trust it. The data underneath was never verified and may be out of date or simply wrong.

The real risk is not that the tool breaks. Tools break. The risk is that nobody knows it has become critical until it does.

We have been here before

This is the spreadsheet and macro problem again. Most finance and operations leaders have inherited a critical process running on a workbook someone built years ago, maintained by whoever was brave enough to open it.

What is different now is speed and opacity. People can build far more, far faster, and in far more corners of the business. And AI tools are harder to inspect than a formula. You can click on a spreadsheet cell and see what it does. A prompt chained to a model whose behaviour changes underneath you is another matter.

That makes the old lesson more urgent, not less.

The two wrong responses

The first is to lock it down. Route everything through IT or engineering for approval. This kills the speed that made the approach worth doing, and people will build anyway, just where you cannot see it.

The second is to ignore it. Let a thousand tools bloom and deal with problems as they come up. This works right up until the problem is a customer-facing failure or a data issue you have to explain to someone outside the business.

Both responses make the same mistake. They treat every tool the same. The fix is to treat them differently, on purpose.

Decide the rules before you need them

Start with a clear line between experiments and adopted tools. Experiments are encouraged and allowed to fail. Adopted tools are things the business has agreed to depend on. The line matters more than where exactly you draw it.

Then set simple triggers for when a tool has to be reviewed for adoption. Mine would be: it touches customers, it sits in a critical workflow, more than one team relies on it, or it handles sensitive data. Any one of those is enough.

Adoption needs to mean something concrete:

• A named owner, and a second person who understands how it works
• Basic documentation
• Data sources that are known and checked
• The account and costs moved to the company
• Someone watching for model changes

That list makes a tool safe. It does not make it useful to anyone beyond the person who built it.

Adoption also means publishing it properly, and this is the part that gets underestimated. Building the tool is the easy bit. Making it usable by people who did not build it is harder. It needs one known place to find it and a single maintained version. It needs a plain explanation of what it is for and, just as much, when not to use it. And the process around it has to change, so the tool becomes part of how the work is done rather than an optional extra some people use.

Different teams will need different things from it. A tool built in customer success might be just as useful to finance, but finance will come to it with different questions. The builder is rarely the best judge of what someone else needs to get started, because they already know everything the newcomer does not.

A tool that only its builder knows how to use has not been adopted, however often it gets used. If a new way of working depends on it, other people have to be able to pick it up without asking.

Ownership should stay close to the work. Moving every adopted tool to engineering recreates the bottleneck you set out to remove. The team that relies on it owns it, whether that is operations, customer success, finance or anyone else. IT sets the guardrails and provides support.

Switching things off is part of the job

Most experiments should not become adopted tools. That is fine. It is expected. A healthy building culture produces far more experiments than keepers.

Build in a regular review where unused or unowned tools are retired. The thing you are really looking for is the experiment that has drifted into daily use without anyone deciding to adopt it. That is exactly the risk this whole approach is meant to catch.

Saying no to adoption is a decision, not a failure. It tells the team the tool was useful for learning and it is time to move on. Sometimes it tells them the idea was right and it needs rebuilding properly. Either way, it is clearer than leaving it to run in the background until something goes wrong.

One commitment, not two

It is easy to see empowering people to build and taking responsibility for what they build as competing ideas. One is about speed, the other about control.

They are the same commitment. If you tell people to build, you are also telling them the organisation will deal with what they make. Some of it will be adopted and shared across teams. Some of it will be switched off. Both outcomes need a decision.

The organisations that get this right will keep the speed and avoid the hangover. Not because they built fewer tools, but because they decided in advance what happens when a good idea becomes something the business depends on, and how it reaches everyone who should be using it.

Let people build. Then decide what you are willing to own.