People and continuity
When AI stops, can your team take over?
Your team needs time to learn, tools they can use and practice handling real work without AI. Here's how to make that part of the job.
Adapted for KLOD from an essay first published on . This edition was updated on .
When an AI service goes down, customer requests keep arriving and invoices still need processing. Someone has to finish that work. Your team needs access to the right records, tools they know how to use and enough practice to make decisions without the model.
Having staff doesn't mean you're ready
Imagine a team using AI to sort customer requests. It handles the easy cases well, giving people more time for complicated ones. Over time, the team stops teaching new starters how to sort the queue themselves. Instructions fall out of date, permissions expire, and one experienced colleague becomes the only person who remembers the whole process.
There are still people on the team, but they would struggle to take over during an outage. To know whether your backup works, you need to measure what they can complete, how quickly they can do it and how long they can sustain that pace. KLOD's requirements for L2 and L3 include evidence that at least two current operators have done the work without supervision.
Give people time to practise
Practising the manual process takes time away from other work. Put that time in the plan and agree on the service you need to maintain during an outage. Support might handle urgent requests while routine ones wait. Finance might process invoices with approaching deadlines and queue the rest.
Work out who can do those jobs and what they'll need. Check their access as well as their instructions: if the manual tools use the same login service that could disable the AI workflow, that outage could block both. The self-check helps you work through these questions.
Make room for learning
In a January 2026 study, Anthropic asked 52 mostly junior engineers to learn an unfamiliar Python library. Developers who used AI averaged 50% on the follow-up quiz, compared with 67% for those who coded without it.
This was a small study, and the quiz happened shortly after the task. It doesn't tell us whether the difference would last. It does give teams a reason to check what someone has understood, as well as whether they've finished the task. Participants who used AI to ask questions and explore the concepts tended to understand more than those who handed the work over to it.
Give people regular chances to complete work themselves. Pair someone learning the process with a colleague who can explain difficult decisions, and discuss unusual cases together. Share responsibilities so a holiday or resignation doesn't leave the team relying on knowledge held by one person.
Practise the handover on real work
Choose a specific job, such as processing one type of customer request. Agree on the exercise with the people affected: when it will happen, who will take over and who can stop the exercise if necessary. Make the AI unavailable for the agreed period and have the team complete the work using the manual process.
Record:
- Time to the first correct result.
- How much work the team completed, and for how long.
- Which records, permissions or instructions were missing.
- Which decisions needed someone outside the planned team.
- Whether a second trained person could repeat it.
Fix the problems and try again. Repeat the exercise after significant changes to the process or team. The verification guide explains what software tests can check and what you need to observe people doing in a drill.
Keep the option to stop using a model
If your team can keep essential work going without a model, you have time to investigate unexpected behaviour, consider a new price or plan a change of supplier. You know what service people can maintain while you decide.
That's a practical reason to budget for training and manual tools alongside the automation. Track the time AI saves, and keep a record of what your team can still do without it.
Start with the welcome post for the pattern, or read about building the takeover into the software if you write the code.
