The AI automation handover checklist
Use this checklist before an AI agent is allowed to affect customers, records, publishing, reporting, money, access, or staff workflows.
1. Workflow map and trigger
Show the real workflow from start to finish. Name the trigger, such as a new enquiry, CRM stage change, uploaded document, weekly report, inbox label, or website task. Then show where the agent acts, where the human reviews, and where the final decision is recorded.
2. Agent role and boundaries
Write the agent role in one sentence: "This agent helps [person/team] prepare [output] from [approved sources] so [reviewer] can approve [decision/action]." Also name blocked actions: no unsupervised emails, pricing changes, public publishing, legal wording, finance changes, sensitive CRM edits, or access changes.
3. Approved sources of truth
List the exact pages, folders, CRM fields, documents, templates, reports, policies, and knowledge-base entries the agent may use. Source lists matter because agents can produce plausible but wrong work when they rely on stale, unofficial, or incomplete material.
4. Tool access, credentials, and permission levels
Document what tools the agent can read, draft in, update, send through, publish to, delete from, or administer. "CRM access" is too broad. "Read contact notes and draft follow-up tasks, but do not change deal stage or send email" is clearer. Use the AI Agent Permissions Checklist NZ to make those access levels explicit.
5. Human approval gates
State which actions always need human review. Approval gates usually belong around customer messages, proposals, price or discount decisions, public pages, privacy wording, sensitive data, finance-adjacent actions, employment matters, and any output that could damage trust if it is wrong.
6. Escalation rules and exception handling
A useful agent knows when to stop. Include the conditions that trigger escalation: missing context, conflicting sources, customer complaints, unusual requests, private information, unsupported claims, tool failures, low confidence, or anything outside the approved workflow.
7. Test cases and acceptance results
Provide the examples used before go-live: normal cases, messy cases, edge cases, rejected outputs, and examples where the agent correctly stopped. This is where handover connects to AI Agent Acceptance Testing NZ.
8. Audit trail and log location
The business should know where to see what the agent read, produced, updated, escalated, failed, and handed to a human. Include the log location, review frequency, and who checks exceptions. For the evidence layer, read AI Agent Audit Trail NZ.
9. Rollback, pause, and repair process
Document how to pause the agent, remove access, revert a changed record, unpublish or correct public content, replace bad source material, and restart only after review. The business should not depend on the original builder just to stop a risky workflow.
10. Monitoring rhythm and named owner
Every AI agent needs a human owner after handover. The owner reviews logs, handles exceptions, approves source updates, requests changes, and decides whether the agent should expand, pause, or retire. Use the AI Agent Monitoring Checklist NZ to turn that into a routine.