Your AI agent is live. The engineer who connected it to the customer system is moving to another rollout. Now someone else needs to answer a basic question: what happens when this stops working? A prompt file and a demo recording don't answer that. The receiving team needs a runbook they can use while a job is stuck, a customer is waiting and the original builder is unavailable.
This guide focuses on operations after launch. Use it when handing an agent from a forward deployed engineer to customer operations, support or an internal engineering team. The goal is a clear route from an alert to a safe decision.
Start with a one-page operating record
Write down the workflow in plain language. State what starts a run, which systems it reads, which systems it can change and what a completed run means. Name the person who decides whether the business result is acceptable. Name a different recovery owner if that person doesn't manage the integration.
Include the current prompt, model and tool versions in the operating record. Record where configuration is changed and who can approve a change. Keep secrets out of the document. Point to the approved credential store and describe the access process instead.
| Runbook item | Required answer | Handoff check |
|---|---|---|
| Business scope | Allowed inputs and outcomes | Owner explains a case the agent must refuse |
| Service identity | Account and permitted systems | Receiver locates the access settings |
| Pause control | How to stop new work and writes | Receiver pauses a test run |
| Recovery | Retry, inspect or escalate | Receiver handles a known failure |
| Ownership | Primary contact and backup | Both acknowledge responsibility |
Document permissions at the action boundary
List actions individually. Reading a candidate record, drafting an email, sending that email and changing an ATS stage need separate entries. For each action, record the allowed account, customer scope and approval requirement. Don't write only that the agent has access to the ATS. That leaves too much unanswered.
OpenAI's Agents SDK distinguishes automatic guardrails from human review. Its approval flow pauses a tool call and returns resumable state instead of executing the action immediately. Its documentation also says agent-level input and output checks don't cover every point in a workflow. Put action validation next to the tool that performs the write.
In the runbook, explain how an operator sees pending approvals, rejects an action and handles an unavailable reviewer. Define expiry rules. A review that was valid before a role closed shouldn't silently authorize a later outreach message.
Give operators a real pause procedure
Define what pause means in your application. Stopping new runs and preventing writes from existing runs are different controls. Document both. State whether a running task finishes its current read, waits at an approval boundary or exits immediately.
Provide a manual fallback for the business process. For a scheduling agent, that could mean assigning the conversation to a recruiter and recording the transfer. Specify how ownership moves back to automation so a person and an agent don't independently work the same item.
Separate retryable failures from work that needs review
AWS reliability guidance recommends exponential backoff, jitter and a maximum retry limit. It warns against retrying permission or configuration errors that need intervention, repeating non-idempotent actions and allowing retries at several layers to compound.
Turn that guidance into a workflow-specific failure table. A temporary dependency outage may qualify for a bounded retry. An invalid field mapping should go to the integration owner. A denied permission should go to the access owner. A write with an uncertain result should wait for reconciliation.
Record which layer owns retries. Inspect the SDK and job runner configuration rather than assuming either provides the intended policy. Set a maximum attempt count and an elapsed-time limit for the operation. Test the exhausted-retry path and show operators where that work waits.
Make replay a controlled procedure
Define a stable business operation identifier before you offer replay. Use the destination's supported idempotency mechanism where available. Otherwise, design a durable operation record and a destination check appropriate to the action. Don't assume a local completion flag alone proves what happened outside your system.
- Find the failed operation and identify the intended customer action.
- Inspect the destination for evidence of an accepted write.
- Compare the original inputs with current business state.
- Confirm any required approval still applies.
- Replay only the incomplete step through the normal permission checks.
- Verify the destination result and record the recovery decision.
Use a hypothetical scheduling example in the handoff exercise. The calendar request times out, but an event might exist. Ask the operator to locate that event before repeating the create action. Then ask what should happen if a recruiter has already booked the candidate manually.
Show the evidence needed for escalation
Give every run a traceable identifier. Record the customer scope, triggering event, version information, action state and external request identifiers where available. Record approval outcomes without copying credentials or unnecessary personal data into logs. Define who may read the evidence and how long it should remain available.
Separate business exceptions from technical incidents. Missing information can go to the workflow owner. Repeated dependency failures can go to engineering. Suspected access outside the agreed customer scope should trigger the documented security escalation and a pause on affected work.
Specify alert routing, acknowledgement and fallback contacts. Include where an operator records the impact, affected work and next update. A channel name alone isn't an escalation plan.
Test the receiving team, not just the software
Run a handoff exercise using test data and the actual operator permissions. Ask the receiving team to find a run, pause work, diagnose a failure, inspect a destination record and recover or escalate. Let them follow the document without the builder taking control.
Include a denied permission, an exhausted retry and an uncertain write outcome. Record gaps in the procedure. Acceptance should depend on demonstrated recovery and named ownership, not a completed presentation.
Mistakes to check before handoff
- Only the original engineer can open the monitoring view.
- Pause stops new jobs but leaves existing writes enabled.
- Replay restarts the whole workflow and repeats completed actions.
- Approval state is lost when a worker restarts.
- Business exceptions have no assigned reviewer.
- Prompt and tool changes have no change owner.
How Remqa supports AI agent handoffs
Remqa provides forward deployed engineers for customer rollouts and builds AI agents for recruiting teams. Use the handoff discussion to define operating ownership alongside the integration work. If your rollout already has a pilot, the pilot to production guide covers the earlier launch decisions. Bring one real workflow and the team that will operate it. Start with who can pause it and who owns recovery.