Answer
What happens to an AI automation when the person who built it leaves?
It keeps running until something changes, then stops in a way nobody can diagnose. The risk is invisible until then.
It runs fine until something upstream changes, then fails in a way nobody remaining can diagnose. The departure creates no visible problem at the time, which is why the exposure is almost never addressed while it is cheap.
The risk here is delayed and that is what makes it dangerous. On the day someone leaves, everything they built continues working, so nothing prompts action. The exposure only materialises when an upstream system changes, a credential expires, a format shifts or the business needs the process to do something different, and by then the person who understood it is unreachable and whatever they knew is gone.
The specific things lost are worth naming, because they are not the code. Why it was built that way. What was tried and did not work. Which of the choices are deliberate and which are incidental. What it deliberately does not handle. Where the fragile parts are. Someone reading the automation afresh sees a set of decisions with no indication which are load-bearing, and their first change will land in the wrong place a reasonable proportion of the time.
The mitigation is not documentation in general, which nobody writes and nobody reads. It is four specific artefacts, each short. What this does and what it touches. How to turn it off. What it deliberately does not handle. And the decisions with their reasons — which is the one that matters and the one always omitted, because at the time of writing they seem obvious.
The second mitigation is that the automation should run somewhere institutional. An automation on a personal machine, under a personal account, using a personal credential, with the code in a personal repository, disappears with the person in a much more literal sense. This is common in small businesses precisely because the person who builds things is often working around a lack of shared infrastructure, and it converts a knowledge problem into an access problem.
The third is that someone else should have watched it work at least once. Not a training session — a occasion where a second person ran it, saw the output, and dealt with a failure. That single experience transfers more than any document, and it identifies the gaps in the document while the author is still available to fill them.
Where none of this was done and the person has already gone, the realistic options are to keep it running untouched until it breaks, to rebuild it deliberately while it still works, or to revert to the manual process. The second is usually right for anything the business depends on, and it is much cheaper done in a quiet month than during the failure.
The automation does not leave when the builder does; it waits several months and then stops during your busiest week.
Siddharth Sharma, Context Theory
Related questions
Is it worth rebuilding an automation nobody understands?
If the process matters, yes, and while it is still working rather than after it breaks. A rebuild with the existing one running gives you a reference to compare against, which is the cheapest possible way to establish what it actually does. That reference disappears the moment it fails, which is when most businesses attempt this.
Does using a low-code platform reduce this risk?
It reduces the technical barrier and not the knowledge loss, which is the larger part. A visible flow is easier to read than code and still does not say why a branch exists or what it deliberately excludes. The platform helps a successor make a change and does not help them know which change is right.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | The exposure created by a builder's departure is delayed until an upstream change, expiry or new requirement arrives, so nothing at the time of departure prompts the action that would still be cheap. | Identifying automations in the business whose builder has left and checking whether anything was done at the time. |
| Constraint | What is lost is the reasoning rather than the code: which choices are deliberate, what was tried and abandoned, what is deliberately unhandled and where the fragile parts are, none of which is visible to a fresh reader. | Asking someone unfamiliar with an existing automation to identify which of its behaviours are intentional. |
| Procurement | An automation running under a personal account, machine, credential or repository converts a knowledge problem into an access problem, and this arrangement is common in small businesses because the builder was working around missing shared infrastructure. | Checking whose account each running automation executes under and where its code is stored. |
| Response | A second person running the automation once and handling a failure transfers more than documentation and identifies the gaps in the documentation while its author remains available. | Having a second person operate the automation while the builder is present and recording what needed explaining. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one