Operational handover
How to Hand Over an AI Agent to Operations
Transfer agent operating responsibility through receiver-led exercises, explicit decision routes and a precise acceptance record.
Handing an AI agent to operations means transferring an ability and an obligation: the receiving team can operate the defined service, and both teams know when that team becomes accountable for it. Delivering a repository, a training session or a folder of documents can support the transfer, but none establishes it alone.
This guide is for delivery leads and service owners approaching the end of an agent implementation. It focuses on the operational transfer within AgentOps: ownership, access, evidence, supervised practice and acceptance. The work is complete when the receiving team demonstrates the agreed capability and accepts the residual issues within its authority.
State what is transferring before choosing a date
Identify the agent, deployments, users, permitted actions, environments and support calendar. Record the development team, receiving operator, business decision owner and specialist support roles. If the transfer covers only part of the service, describe the retained responsibilities explicitly.
Separate operational ownership from product ownership and domain approval. The operations team may own monitoring and recovery while the business team continues to decide whether a proposed result is acceptable. Engineering may retain responsibility for defects and major changes without remaining the informal first responder forever.
Google's discussion of production-readiness reviews and SRE engagement describes progressive preparation, training and transfer rather than a document-only handoff. The process below applies that principle to agents with uncertain outcomes, tool actions and human decision dependencies.
Build a transfer pack around operating questions
| Item | Required content | Question for the receiver |
|---|---|---|
| Service boundary. | Purpose, permitted actions, excluded work and accountable owners. | What am I responsible for operating? |
| Current state. | Active versions, deployments, identities and known limitations. | Which system is actually running? |
| Outcome evidence. | Acceptance rules, task states, evaluations and evidence locations. | How do I recognise useful, failed and uncertain work? |
| Response procedures. | Tested runbooks, containment, recovery and escalation routes. | What can I do when operation changes? |
| Change control. | Release authority, verification, rollback limits and emergency path. | How do I change the service without losing control? |
| Open work. | Backlogs, incidents, exceptions, owners and next decisions. | What unresolved responsibility am I accepting? |
| Transfer evidence. | Observed exercises, access verification and acceptance record. | What proves the team can perform the role? |
Keep the pack linked to maintained systems of record. Copying a deployment list into a static document can make it stale before acceptance. Use the agent inventory for durable relationships and identify the version or snapshot inspected during the handover.
Illustrative case: a research-library accession assistant
Imagine an agent that prepares accession-record drafts for a research library. It extracts bibliographic fields from approved submissions and proposes associations with existing catalogue records. A qualified catalogue reviewer accepts the record; the agent does not decide acquisition rights or overwrite an established edition record without approval.
The development team has been quietly resolving ambiguous edition identifiers in a private work queue. If that queue is absent from the transfer pack, the new operator inherits a service that appears complete but relies on unavailable human knowledge. Include the unresolved cases and explain their permitted dispositions.
For a controlled rehearsal, prepare an illustrative set of 12 accession submissions: ten with the required evidence and two with ambiguous edition information. The objective is not to force all 12 through. The receiving team should demonstrate correct processing of the supported records and a visible review state for the ambiguous ones.
Use three stages of operational practice
Observe: the receiving team watches the current operator perform routine work and a representative exception. The receiver asks why each decision is permitted, what evidence supports it and what would make the procedure stop. Capture undocumented assumptions as transfer work.
Perform with supervision: the receiver operates the service while the delivering team observes. Use the receiver's actual access and evidence views. If the developer intervenes, record what they supplied and whether the receiver could repeat the action later.
Operate with defined backup: the receiver leads within the agreed scope, with a named escalation route to the delivering team. State the conditions for ending this transitional arrangement. A fixed calendar period can help scheduling, but time elapsed is not proof that competence or access gaps are resolved.
For the accession assistant, the receiver should locate the two ambiguous cases, preserve their evidence, route them to the catalogue reviewer and distinguish a draft from an accepted record. The operator should not invent an edition match merely to demonstrate a clean queue.
Rehearse controls that matter after the developers leave
Test a permitted pause, a controlled restart, an evidence lookup and the handling of an uncertain destination result. Verify whether queued work continues when intake is stopped. Record the resulting task state so that recovery does not depend on someone remembering what happened.
Demonstrate an approved credential rotation or equivalent access-change exercise in a controlled environment. The receiver must know which identity is changing, which deployments depend on it and how to verify the new access without exposing the secret in the handover document. Avoid disrupting shared services through an unplanned production exercise.
Include a bounded restoration or recovery rehearsal using the actual documented mechanism. Distinguish restoring configuration from restoring external state: a reverted agent version does not erase actions already completed in a catalogue or another destination. The recovery guide explains the reconciliation work that remains.
Transfer the decision routes as well as technical access
The receiver needs to know who can approve a category change, accept an unresolved case, authorise an exceptional action or change a service commitment. Access to a dashboard does not grant those decisions. Test a real route to the responsible role, including the agreed substitute.
For the library example, the catalogue reviewer owns the edition ambiguity, while the operator owns the queue state and evidence. If the reviewer is absent, the service should retain the case in the agreed waiting state. The oversight model describes these boundaries in more detail.
Establish who receives alerts during the transition and at the moment of transfer. Parallel support can be useful, but only if incident ownership is unambiguous. A duplicated alert route should not create two teams independently changing the same service.
Make open issues acceptable or blocking explicitly
List defects, missing controls, unresolved tasks and temporary workarounds. For each, record its consequence, current protection, owner and the evidence needed for closure. Distinguish an accepted limitation from a problem merely acknowledged in a meeting.
An operator may accept a documented non-critical reporting limitation within their remit. They may not have authority to accept a missing action boundary or an unreviewed privacy consequence. Route such decisions to the appropriate owner and retain a hold when the required acceptance is absent.
Use the readiness checklist to establish whether the service is acceptable, then use the handover record to establish who has accepted operating it. These are related but different decisions. A ready service can still have an incomplete transfer if the receiver lacks access or capability.
Write a precise acceptance record
The record should identify the transferred scope, active versions, receiving owner, effective time, completed exercises, accepted limitations and retained responsibilities. State where the current runbooks and evidence live. Include the escalation arrangement for defects that emerge after transfer.
Do not use acceptance to erase engineering responsibility for delivered defects, nor leave engineering permanently accountable for every operational action through vague wording. Agree the support boundary and change process. Where a supplier is involved, align the record with the actual commercial agreement.
Require the receiving owner to affirm that the agreed evidence supports the transfer. A generic email saying “files received” is a receipt, not proof of operating acceptance. If conditions remain, record how they restrict the transferred service and when the decision will be revisited.
Control changes while the transfer is being accepted
Agree how releases during the handover affect the evidence pack. If engineering changes a tool permission after the receiver's exercise, the earlier exercise may no longer prove the current operating boundary. Record the changed component and repeat the affected verification before the receiver accepts it.
This does not require stopping all development. Maintain a visible transfer baseline and a clear route for incorporating approved changes. The receiving team should be able to identify which version it rehearsed, which version is now running and what evidence connects the two. If a release introduces a new responsibility, update the scope and obtain acceptance from the appropriate owner rather than assuming that the original handover covered it. This prevents an operational transfer from becoming an accidental acceptance of work that neither team discussed.
Review the first operating period for hidden support
After transfer, inspect interventions, escalations, unplanned developer help and unresolved queue age. These observations reveal whether the operating model works outside the rehearsal. Do not penalise the receiver for surfacing a gap that the transition failed to expose.
Update the runbooks with verified improvements and keep the former team's temporary access under review. If external support continues, formalise it through the managed operating scope rather than relying on personal favours.
Discuss an operational handover for an AI agent with the transfer boundary, current open issues and one recorded exercise. The aim is a demonstrable transfer of responsibility, with the receiving team able to recognise limits and operate the controls it has accepted.
FAQ
Your questions, answered.
What proves an AI agent handover is complete?
The receiving team demonstrates the agreed operating capability with its own access, accepts the defined scope and records any retained or conditional responsibilities. Evidence should cover normal work, exceptions, containment, recovery and escalation. Files received and training attended are useful inputs, but they do not by themselves prove that operational responsibility has transferred.
How is handover different from a readiness review?
Readiness asks whether the defined service can be accepted under stated conditions. Handover asks whether a named receiving team can operate that service and has accepted responsibility for it. A service can pass technical checks while transfer remains incomplete because operators lack access, knowledge or reachable decision owners. Keep the two decisions linked but explicit.
What should happen to unresolved tasks during handover?
Include their identities, current state, evidence, owner and next decision in the transfer record. Distinguish accepted limitations from unaccepted risks and assign the authority needed for each disposition. Do not clear the queue by inventing successful outcomes or dropping ambiguous cases. The receiver should know exactly which unresolved obligations it is accepting.
Should developers keep access after operational transfer?
Only according to the agreed support role and access policy. Temporary backup may be useful, but it needs a scope, owner and review or expiry trigger. Reassign alert routes and remove unnecessary privileges deliberately. Continuing informal developer support can hide an incomplete transfer and make accountability unclear when incidents or changes occur.
How long should a supervised agent handover last?
Set the duration from the operating capability that must be demonstrated, the service calendar and representative conditions that need observation. A fixed period can support scheduling but is not proof of readiness. Define exit evidence, such as successful receiver-led recovery and correct exception handling, and record any conditions that remain at the end.
Does rolling back the agent restore all external records during handover tests?
No. Restoring an agent version or configuration does not automatically reverse actions already completed in an external system. The operating team needs a reconciliation procedure that establishes actual destination state and determines permitted correction. Demonstrate this distinction in a controlled exercise so the receiver does not mistake technical rollback for complete business recovery.