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.
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.
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 built | A dependency was built | |
|---|---|---|
| At handover | Looks similar, both work | Looks similar, both work |
| First system update | Someone internal fixes it | The external party is called |
| Threshold needs changing | Changed the same afternoon | Added to a backlog for the next engagement |
| The person who understood it leaves | Others can read the failure notes | The knowledge leaves with them |
| After twelve months | Still running, changed several times | Still running, unchanged, or quietly abandoned |
| Revenue for the external party | Ends | Continues |
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
Sources
- Waarom een adviesrapport geen capability is (Radical)— radicalai.nl ↗
- Hoe je AI-kennis verankert (Radical)— radicalai.nl ↗
- Zelf bouwen, kopen of samen doen (Radical)— radicalai.nl ↗
Tell us what you need.
We respond within 24 hours, from a real human.
Get in touch



