A few years ago I was asked to look at an AI programme that had, by every visible measure, succeeded. The consultancy that built it had delivered on time. The tools worked. There was a handsome deck. Eighteen months later, almost none of it was in use, and the organisation could not say why.

I could. The people who understood it had left. Not the organisation's people; the consultancy's. They had rolled off to the next client, taking with them the only working knowledge of why each part existed. What remained was a set of artefacts nobody owned, and an organisation slightly more nervous about AI than it had been before it spent the money.

I do not think that consultancy did anything wrong, by the standards of consulting. They were asked to build, and they built. The mistake was upstream, in what was asked for, and it is the mistake I now spend most of my working life trying to prevent.

Here is the principle. Capability bought from outside decays when its builders leave. Capability built by an organisation's own people lasts, because they know why it exists.

Knowing why is not a soft sentiment. It is the thing that lets a team adapt a process when the model changes, when the regulation changes, when the customer changes. Every one of those will happen within a year. A team that built the thing will adjust it in an afternoon. A team that inherited it will file a ticket, wait for a quote, and quietly go back to the old way.

This is why I founded Bellamy Alden as the AI Empowerment Company rather than as another delivery firm. We equip organisations to build their own AI programmes with their own people. We do not run the programme for them. That distinction confuses procurement departments, who are used to buying outcomes, and it is the whole point.

It also changes what leadership has to do, and this is the part I want to be precise about, because it is where the effort goes.

You have to decide who in your organisation is going to become capable, by name. Not a centre of excellence in the abstract; specific people, in the functions where the work that matters happens. They are usually not the people who volunteered first. They are the people who already understand the work well enough to know what a wrong answer looks like.

You have to give them the time to build it, and protect that time when the quarter gets tight. Capability is built in the work, not in a course, and the work does not pause for it. Something else has to.

And you have to accept that the first version will be worse than what a consultancy would have delivered. It will be slower and rougher, and it will be yours, and in a year it will still be running while the polished version would have been gathering dust.

The objection I hear most is that this does not scale. I think the reverse is true. What does not scale is a dependence on people you do not employ, renewed at every change in the technology. Building it in is slower once. Buying it in is slower forever.

There is one more reason it matters, and it is not about efficiency. When people build their own capability, they end up more powerful and more fulfilled than they were. When it is built around them, they end up managed by it. Given that the work is never finished, because what counts as full use of these tools rises with every release, I would rather have the first kind of organisation. It is the only kind that keeps pace on its own.

If you have a programme that was delivered, ask a simple question of it: who here could change it? If the honest answer is nobody, you did not buy capability. You rented some, and the lease is up.