Offboarding checklists usually cover the laptop, the badge and the email account. In a company that uses AI, a quieter group of items is easy to miss: the agent a colleague built last spring, the API key they created under their own login, the scheduled job that runs every Monday morning because they once set it up.
None of these are unusual, and none of them are anyone's fault. They exist because it was quick to build them under a personal account. The problem appears on the day that person leaves or changes role. This article gives a technology lead a checklist to handle that day calmly.
Two ways it goes wrong
There are two opposite failures, and both are common.
The process stops. Someone in IT closes the account on the last day, as the policy says. The key tied to that account stops working, the scheduled job fails, the agent can no longer read the folder it depended on. Nobody notices until a customer or a colleague asks why the weekly report did not arrive.
The process keeps running with no owner. The account is not touched, or the key is not tied to the account at all. The agent keeps working for months. Nobody reviews its answers, nobody knows which data it reads, and nobody can change it when the business changes. If it starts making mistakes, there is no one to call.
Both come from the same cause: ownership was never written down. The fix is not a heavier process, but a short habit of recording who owns what.
What to look for
Before you can hand something over, you need to know it exists. For a departing employee, go through these places.
Agents and assistants. Custom assistants, workflows in automation tools, and prompts saved in personal accounts. Ask the person, their manager and their team, and look at the list of assistants in your AI tools, filtered by creator.
Keys and tokens. API keys for AI services, tokens for integrations, and credentials stored in scripts or in a personal password manager. Check which are tied to the person's account and which are shared. For the principles of limiting what such credentials can do, see least privilege for AI agents: read, write and credentials review.
Scheduled jobs and triggers. Anything that runs on a timer or reacts to an event: a nightly export, an email rule, a webhook. These are the items most likely to be forgotten, because nobody sees them until they fail.
Shared accounts and services. Subscriptions bought on a personal card, trial accounts that became permanent, and tools signed up for with a personal email address. These can also hold company data.
Data and outputs. Folders, spreadsheets and knowledge bases the agent reads from or writes to, and where the results go.
Knowledge in the person's head. Why a setting was chosen, what the agent should never do, which edge cases came up. This is often the most valuable item and the least likely to be written down.
The handover checklist
For each item you found, go through the same short list.
- Name the new owner and a deputy. One person, not a team alias. The new owner must agree to it, and their manager should know about the extra responsibility.
- Decide: keep, change or retire. Not everything deserves to survive. If the process is no longer needed, retire it deliberately, as described in retiring or replacing an AI agent safely.
- Move the credentials. Create new keys under a service or team account, give them only the access the agent needs, and replace the old ones. Do not hand over the departing person's password or session.
- Move the schedules. Recreate scheduled jobs under the new owner or a service account, and confirm they run once before the old ones are switched off.
- Capture the knowledge. Ask the departing person to write or record a short note: what the agent does, what it reads, what can go wrong, who to ask. The structure in handing an AI agent to a new team: runbook, owner, escalation and access works well for this.
- Test after the switch. Run the process once with the new setup and have the new owner check the result. A handover is complete when it has been seen to work, not when the form is signed.
- Close the old access last. Only when the new setup runs, disable the personal keys and the personal account access. Keep a short log of what was disabled and when.
- Record it. Update the register with the new owner, the date and a pointer to the handover note.
Order matters
The order of these steps is the main point. Many organisations close the account first and then try to repair what broke. Turning it around costs a few days of planning and avoids the surprise.
If the departure is sudden or access must be removed immediately, for security reasons, do not wait. Disable the access, accept that some processes will stop, and work through the list using the register. This is where having a register helps most: you know within an hour which processes are affected and who should fix them. For a wider plan of what to do when an agent must be stopped quickly, see incident response and kill switches for AI agents.
Keep a register so the next exit is easy
The best preparation is a simple list, kept up to date, with one row per agent or automation. Useful columns:
- name and short description of what it does
- owner and deputy
- where it runs, and under which account or service identity
- which systems and data it can access
- which keys it uses and where they are stored
- schedule or trigger
- date of the last review
Review the register on a fixed rhythm, for example quarterly, and whenever the HR department reports a departure or a change of role. When the notice comes, you filter the list by name and see at once what needs a new owner.
Add one rule to the way you build things: new agents and keys are created under a team or service identity from the start, and a personal account is used only for experiments. This single rule removes most of the problem.
Changes of role and long absences
The same list applies when someone moves to another team, goes on parental leave or is away for several months. In these cases the person is still there, which makes it tempting to do nothing. But their old agents now sit with someone who has no time for them, and an unreviewed agent drifts over months. Hand over the ownership, or agree explicitly that the person remains the owner and name a deputy for the absence.
Common mistakes
Trusting memory. Asking "is there anything else?" in the exit interview finds the items the person remembers, not the ones they forgot. Use the register and a check of your tools.
Handing over the credentials. Passing on a personal password hides who did what and breaks when the account closes. Create new credentials for the new owner.
Skipping the test. A job that was recreated but never run is a job that may not work.
Forgetting the deputy. If only one person knows about a process, the problem has only moved from one person to another.
A short checklist
- Every agent, key and scheduled job has a named owner and a deputy in a register.
- New agents and keys are created under team or service identities, not personal ones.
- The departure notice from HR triggers a search of the register and of the AI tools.
- Each item is kept, changed or retired on purpose.
- Credentials are replaced, not passed on, and schedules are recreated and tested.
- The departing person leaves a short note about how the process works.
- Personal access is closed only after the new setup has been seen to run.
- The register is updated and reviewed on a regular schedule.
An exit will always cost something. With a register and a fixed order of steps, it costs a few hours of planned work instead of a week of finding out what stopped.
