AI workflows that survive staff turnover

Here is a quiet little disaster that happens in a lot of organisations right now, and almost nobody calls it what it is.

Someone on the team gets good with AI. Really good. They figure out how to draft the funding report in twenty minutes instead of two days. They have a prompt that turns messy meeting notes into a clean action list. They know exactly how to phrase things so the model stops hallucinating and starts being useful. The whole team starts routing work through this person, often without noticing. And then that person leaves. New job, parental leave, end of contract, whatever. The knowledge walks out the door with them, and the team is suddenly slower than before they ever touched AI, because now they have unlearned how to do the work by hand and never learned how to do it with the machine.

I have watched this happen. I have nearly been the cause of it. So this piece is about the unglamorous part: how to build AI workflows that keep working after the person who built them is gone.

The clever-operator trap

The trap is seductive because it feels like progress. One person becomes a force multiplier, output goes up, everyone is happy. But what actually happened is that you concentrated a critical capability inside a single human's chat history and intuition. That is not a workflow. That is a dependency with a pulse.

I think of AI capability inside a team on two axes. The first is how good the output is. The second is how many people can reliably reproduce it without the original author in the room. Most teams obsess over the first axis and completely ignore the second. A brilliant prompt that only one person knows how to run is worth less to the organisation than a merely good prompt that five people can run, because the good one survives.

This is the same thing I keep coming back to in everything I build: scale runs on systems, not goodwill. Goodwill is the talented colleague who always helps. Systems are what is left when they are on holiday.

How handoffs forced me to document

I learned this the hard way at Nuoret Kotkat, the youth organisation where I ran national projects and led the AI adoption. The detail that did it was a structural one. Roughly thirty percent of my role was, in practice, sold to the Savo regional organisation. They paid for a slice of my time to handle their administration.

That arrangement changed everything about how I worked, and it took me a while to understand why. When the work is all yours, you can be sloppy with your own knowledge. You hold it in your head, you improvise, and it mostly works because you are always there. But the moment a chunk of your output belongs to someone in another city who needs it to keep running whether you are sick, on leave, or hit by a tram, you can no longer be the single point of failure. The Savo work had to be reproducible by people who were not me.

So I started writing things down, not as documentation theatre, but because the alternative was a phone call every Tuesday explaining the same process again. The AI workflows were the first thing I documented properly, because they were the most opaque. A colleague could look at a spreadsheet and roughly guess what I did. Nobody could look at a finished, AI-drafted grant report and reconstruct the four prompts and three rounds of human editing that produced it.

That constraint, having to hand work across to people who could not read my mind, is the best forcing function for good systems I have ever had. If you do not have it, you have to manufacture it on purpose.

The four things that turn a workflow into a system

A real AI workflow, the kind that survives turnover, has four parts. Skip any one and it quietly reverts to living in someone's head.

1. Documented prompts, with the why attached

Not a screenshot of a clever prompt. A versioned, named prompt that explains its own purpose. The killer addition is the reasoning: why the prompt is shaped the way it is, and what happens when you change it.

I keep these as plain files in the repo or shared drive, never buried in a chat thread. Something like:

# grant-report-draft.md
# Purpose: turn quarterly project data into a grant-format draft.
# Owner: operations
# Why this shape: the model invents impact numbers if you don't
#   give it the real figures up front, so we paste data BEFORE
#   the instruction. The "do not estimate" line is load-bearing;
#   remove it and it will confidently make up participant counts.

[data block]
[instruction block]

The comment about the load-bearing line matters more than the prompt itself. The next person needs to know which parts are safe to touch and which parts are scar tissue from a real failure.

2. Shared context files the model can read

Half of what makes one person's AI output good is not the prompt. It is the context living in their head: how the organisation talks, what the funder cares about, which numbers are real, what last year's report said. If that context only exists in one skull, the workflow cannot transfer.

So you externalise it. A short, maintained context file: voice and tone, key facts, the things the model must never get wrong, links to source data. The point is that the quality moves from the person to the file. A new colleague who reads the context file and runs the documented prompt should get roughly eighty percent of what the original author would have produced, on day one.

3. Runbooks, not just prompts

A prompt is one move. A runbook is the whole game. It is the boring step-by-step: pull this data from here, run this prompt, check these three things in the output, send the draft to this person for sign-off, file the result there.

The verification step is the part people skip and the part that matters most, because AI output is fluent and confident even when it is wrong. The runbook has to say, in plain language, here is how you catch the model when it lies. For grant reports that meant: cross-check every number against the source spreadsheet, because the model will smooth a gap with a plausible figure if you let it. A runbook without a verification step is just a faster way to ship mistakes.

4. A named owner

Documentation rots. Models change, the funder changes their template, the org changes its tone. Without a named owner, a runbook is accurate the day it is written and slowly becomes a liability. The owner does not have to be the original author. In fact it is healthier if it is not, because that proves the handoff actually worked.

A worked example: the grant report that kept running

Here is the concrete version. We had a recurring funding report that I used to produce with a fair amount of AI assistance and a lot of personal judgement.

In the bad version, it lived entirely with me. The prompts were in my chat history. The context, what this funder responds to, which framing wins, was in my head. If I had left mid-cycle, my replacement would have been handed a deadline and a blank page.

In the documented version, the same report became: a folder with three named prompt files (data structuring, narrative draft, compliance annex), a context file holding the funder's priorities and the organisation's real numbers for the period, and a one-page runbook ending in a verification checklist. The actual test came when part of this had to serve the Savo region, run by people who were not me. It worked. Not because they were AI experts, but because the expertise had been moved out of my head and into files they could read.

The output was very slightly worse than my personal best. Maybe ten percent. And it was massively better than the realistic alternative, which was a panicked handover or a return to doing it all by hand.

The tradeoffs, honestly

This is not free, and pretending otherwise would be dishonest.

It is slower at first. Documenting a workflow takes longer than just running it. The payoff is entirely in the future, which is exactly why busy teams never do it. You have to treat it as insurance, not productivity.

Documentation can drift from reality. A runbook that quietly stops matching the actual process is worse than none, because people trust it. This is why the named owner is not optional.

You can over-systematise. Not every clever one-off needs a runbook. If you only run something twice a year and the stakes are low, a documented prompt is plenty. The full treatment is for the work that genuinely cannot stop when a person does.

The best operator may resist. Being the indispensable AI person feels good. Writing it all down makes you replaceable. The honest reframe is that being replaceable in your current job is how you become promotable into the next one. Nobody gets to move up while they are the only person who can run the machine.

The deeper point is that the goal was never the prompt. The prompt is the cheap part. The expensive, fragile, valuable part is the judgement around it, and judgement is exactly the thing that disappears when a person leaves unless you have deliberately pulled it out of their head and written it down where the next person can find it.

So the question to ask about any AI workflow on your team is not "how good is this?" It is "what happens to this the day the person who runs it doesn't show up?" If the honest answer is we'd be in trouble, you do not have a workflow yet. You have a clever colleague and a stopwatch running on their notice period.