Back to blog
AI Capability

What happens when the external party leaves

Success means you no longer need us. That is an uncomfortable sentence for a company that sells engagements to write down, which is precisely why it is worth writing down.

Radical AI Team23 September 20264 min read
A hand holding a key to a door. The test of the work is what still runs after we leave.

This is the last piece in this series, and it is the one that states the standard we would like to be held to.

The only honest measure of an AI engagement is not the quality of the deliverable, the sophistication of the model, or how the final presentation went. It is what still works six months after the last invoice, when nobody from the external party has been in the building for half a year.

By that measure, a great many engagements fail, including ones that everyone involved considered a success at the time.

The two ways an engagement ends

The first way: the thing keeps running and the team changes it. Someone internal adjusts a threshold, adds a new case, fixes something that broke after a system update. They do not call anyone. This is what success looks like and it is unglamorous, which is part of why it is rarer than it should be.

The second way: the thing keeps running until it does not. It works for a while because nothing has changed yet. Then the ERP is updated, or a supplier alters a file format, or the one person who understood it takes another job. At that point the company discovers that what it bought was an artefact rather than an ability, and the choice is to call the external party back or quietly stop using it. Most quietly stop.

The difference between those two endings is decided at the start, not at the end.

Someone opening a door. Six months after the last invoice is when you find out what was built.Someone opening a door. Six months after the last invoice is when you find out what was built.

Four things to arrange before the work begins

One: name the internal owner in the contract, not after. Not a sponsor, not a steering group. The person who will still be responsible when the external party is gone. If nobody can be named at the start, that is genuinely useful information about whether to start.

Two: agree that someone internal does part of the work, badly at first. This is the one clients resist most, and understandably: it is slower and the first attempts are worse. It is also the entire mechanism by which capability transfers. Watching someone competent work is not learning; doing it while someone competent is still there to correct you is.

Three: require that failures get written down as they happen. Not a final report. A running note of what went wrong and what was done about it, kept during the work. That is the part of the knowledge that cannot be reconstructed afterwards, as covered in Hoe je AI-kennis verankert.

Four: agree the six-month test in advance. A specific change that the internal team will make alone, six months after the end, with no support. Name it at the start. If it turns out to be impossible then, the engagement did not do what it claimed.

Two endings, side by side

Capability was builtA dependency was built
At handoverLooks similar, both workLooks similar, both work
First system updateSomeone internal fixes itThe external party is called
Threshold needs changingChanged the same afternoonAdded to a backlog for the next engagement
The person who understood it leavesOthers can read the failure notesThe knowledge leaves with them
After twelve monthsStill running, changed several timesStill running, unchanged, or quietly abandoned
Revenue for the external partyEndsContinues

The first row is why this is hard to judge at the time. At handover the two look identical, and everyone is pleased. The difference only becomes visible at the first thing that was not anticipated, which is by definition after everyone has gone home.

The uncomfortable part

We are describing a standard that works against our own commercial interest, and it is worth being precise about how rather than waving at it.

An engagement that ends in genuine independence produces no recurring revenue. A dependency does. Every incentive in professional services pushes toward the second, not through bad faith but through drift: the client keeps asking, you keep answering, and after a year nobody can remember agreeing that this would be permanent.

Writing the six-month test into the arrangement is what stops that drift, and it protects both sides. It gives the client a checkable claim rather than a promise, and it gives us a clear definition of finished, which is worth more than an open-ended relationship where neither party can say what done means.

What we will not claim

Independence is not the same as never speaking again, and pretending otherwise would be its own kind of dishonesty. There are legitimate reasons to keep working with an external party: genuinely new problems, a second capability area, a periodic outside view precisely because it is outside. The distinction is whether the client could stop, not whether they do.

A client who continues because it is useful is a good outcome. A client who continues because stopping is not an option is a failure that happens to be profitable.

The question to ask any party you are considering

One question, and how they answer it tells you most of what you need.

"What does it look like when you are finished, and what will we be able to do without you that we cannot do now?"

A party that has thought about this has a specific answer, usually including something they will refuse to keep doing for you. A party that has not will describe an ongoing relationship in warm terms and change the subject.

About this page

The standard described here is Radical's own position and is the closing piece of this capability series. It runs against our short-term commercial interest and that is stated explicitly rather than implied. The related arguments are in Waarom een adviesrapport geen capability is and Zelf bouwen, kopen of samen doen. Written by Radical's own team; no client data was used.

Frequently asked questions

By what still works six months after the last invoice, and specifically whether the internal team can make a change alone without calling anyone.

Sources

  1. Waarom een adviesrapport geen capability is (Radical)radicalai.nl
  2. Hoe je AI-kennis verankert (Radical)radicalai.nl
  3. Zelf bouwen, kopen of samen doen (Radical)radicalai.nl
Looking for AI talent?

Tell us what you need.

We respond within 24 hours, from a real human.

Get in touch

Related reads

Pallets stacked outside and going nowhere. AI projects rarely fail loudly, they simply stop moving.
AI Capability

Why AI projects run aground in mid-sized companies

They do not crash. They go quiet. Five places an AI project runs aground in a mid-sized company, and why more technology fixes none of them.

4 August 20269 min read
A team around one laptop. The gap between mid-sized and large companies is twenty-one percentage points.
AI Capability

Five signals that your AI ambition is stalling on your organisation

Cost is named by 3 per cent as the reason for not using AI. Lack of experience inside the company by 11 per cent. Here is what that looks like on your own floor.

10 August 20269 min read
A calculator on a desk. The real cost is not on the invoice.
AI Capability

What AI really costs, and the budget nobody plans for

A licence of six hundred euro a month against twenty-eight thousand in staff hours. The ratio nobody puts in a business case, and how to budget it yourself.

12 August 20268 min read