An AI agent rarely stays with the team that built it. People change roles, a project moves to a platform group, or a pilot becomes a product with a different owner. The agent keeps working, so the change looks small. In practice, the new team inherits a system whose quirks lived in somebody's head.
This article is for the manager who takes over the operation of an existing agent, or who has to hand one over. It builds on the earlier guides about operational review after launch and incident response. If the agent is being replaced rather than moved, read the guide to retiring or replacing an agent instead.
What usually goes wrong
- Unwritten knowledge. The previous team knows that the agent struggles with one customer segment, or that a certain job must not be restarted during month-end. None of it is written down.
- Unclear ownership. The old owner has moved on, the new one has not been named, and for a few weeks alerts go to a mailbox nobody reads.
- Orphaned access. Credentials sit with people who no longer work on the agent, while the new team borrows a shared login to get anything done.
- No path for escalation. When the agent misbehaves at night, nobody knows who may switch it off.
Step 1: Agree what is being handed over
Start with the scope. Write down the agent itself, its prompts and configuration, the connected systems, the test set, the dashboards and the vendor relationship. Also state what is not included, for example a shared knowledge base that another team keeps. Ambiguity at the edges is where responsibility gets lost.
Set a date range: when the handover starts, when the new team becomes accountable, and when the old team stops being a safety net. Three clear dates are better than one vague "transition period".
Step 2: Write a runbook the new team can use alone
A runbook is a short operating manual. The test is simple: could a competent person who has never seen the agent use it at 2 a.m.? Google's engineering guidance on on-call practice makes the same point for services in general: the people on duty need documentation they can act on, not a history of the project.
A useful runbook for an AI agent contains:
- Purpose and boundaries. What the agent is for, what it may decide alone and what needs a human, in the terms of your approval and audit setup.
- Normal behaviour. Typical volumes, response times, error and correction rates, so that the new team can recognise a bad day.
- Known weak spots. Case types where quality drops, with the workaround used so far.
- Routine tasks. Reviewing samples, updating the knowledge base, rotating credentials, renewing the vendor contract, with frequency and owner.
- Failure procedures. For each likely failure, the first check, the person to call and the switch-off step. Link the kill-switch procedure rather than copying it.
- Change history. The last significant changes to prompts, models and tools, and why they were made.
Keep it to a few pages. A long runbook that nobody reads is worse than a short one that is current.
Step 3: Name the owner, deputy and escalation path
On the receiving side, name one accountable owner and one deputy. The owner decides about changes and about stopping the agent. The deputy covers absences, so that the agent is never ownerless during holidays.
Then draw the escalation path on one page: who is the first contact for an alert, who decides to switch the agent off, who informs affected customers or regulators, and who can approve exceptions. Include contact details and the hours each person is reachable. The NIST AI Risk Management Framework stresses that roles and responsibilities for AI systems should be defined and documented; a handover is the moment to make that concrete for this particular agent.
Also decide how the owner is informed about the vendor side: status pages, notices of model changes and contractual contacts, as described in the guide on vendor contracts and exit.
Step 4: Transfer access properly
Access is the part most often done in a hurry. Follow a fixed order:
- List every identity and permission the agent and its operators hold, using the approach from the guide on identity and least privilege.
- Grant the new team their own named accounts with the roles they need.
- Let the new team confirm that they can perform each routine task with their own access.
- Remove the access of people who are no longer involved, and rotate any secret they have seen.
Do not hand over a shared password or a personal token. If the old owner's account was the only way to do something, treat that as a defect to fix before the handover ends.
Step 5: Shadow, then reverse the roles
Documents do not prove readiness. Use a short period of two phases:
- Shadowing. The old team operates the agent while the new team watches, asks questions and updates the runbook wherever it was unclear.
- Reverse shadowing. The new team operates and the old team watches and steps in only on request.
During this period, rehearse at least one failure from the runbook: simulate an alert, follow the escalation path and practise the switch-off and restart. This is the same idea as the staged rollout, applied to people instead of software. Rehearsals also show whether the contact list is correct. Google's SRE material on learning from failure is a good model for treating gaps found this way as improvements, not as blame.
Step 6: Keep the old team reachable, with rules
After the formal cutover, agree a fixed period, often four to eight weeks, in which the previous team can still be asked. Set the rules in writing: which questions they answer, how fast, and when the period ends. Without an end date, the old team stays the real owner and the new one never becomes confident.
Close the handover with a short sign-off by the new owner: the runbook is current, access has been checked, one rehearsal has been done and the escalation path works. Record the date and keep it with the operational review records, so the first review under the new owner can compare against the old baseline.
A short checklist
- Scope, exclusions and three dates agreed.
- A short runbook, tested by someone who did not write it.
- One owner, one deputy and a one-page escalation path.
- Named accounts for the new team, old access removed, secrets rotated.
- Shadowing in both directions and at least one rehearsed failure.
- A time-limited support arrangement and a written sign-off.
A good handover feels dull. The agent keeps working, the alerts reach the right person, and nobody has to call the previous team after the agreed date.
