AI agent production readiness checklist

A pilot can earn a Continue decision and still be unready for production.

The pilot proved a bounded case. Production introduces real operators, broader case variation, persistent permissions, handoffs, exceptions, and an obligation to recover when something goes wrong. Moving forward responsibly means defining that operating boundary before the agent goes live, not after the first surprise.

This AI agent production readiness checklist is a practical production gate. Use it after the AI agent pilot decision template supports Continue or Change and before anyone expands access or volume. Complete it for one workflow, one production boundary, and one accountable decision. If required proof is missing, write UNPROVEN.

Production gate worksheet

Keep the answers short enough to review on one page. Link supporting test evidence, logs, runbooks, and approvals rather than copying them into the worksheet.

AI agent production gate

1. Approved workflow and outcome: Workflow ___; intended operating outcome ___; pilot decision/date ___; evidence link ___.
2. Production scope: Allowed users, case types, systems, data, actions, volume, and operating hours ___.
3. Explicitly out of scope: Excluded users, cases, records, decisions, commitments, channels, and actions ___.
4. Accountable business owner: Name/role ___; authority to approve, pause, or stop ___; backup ___.
5. Technical owner: Name/role ___; deployment, monitoring, incident, and rollback responsibility ___; backup ___.
6. Identity and least-privilege permissions: Runtime identity ___; approved tools/data ___; read/write/action rights ___; credential owner ___; access review date ___.
7. Human approval points: Action requiring approval ___; approver ___; evidence shown ___; timeout or no-response behavior ___.
8. Prohibited actions: The agent must never ___; detection/blocking method ___; stop and escalation response ___.
9. Representative-case testing: Routine, ambiguous, missing-information, disputed, sensitive, and out-of-scope cases tested where relevant; results/evidence ___.
10. Failure and recovery testing: Tool unavailable, permission denied, bad input, stale source, timeout, duplicate, and partial completion tested where relevant; safe behavior ___.
11. Exception queue and escalation owner: Queue/location ___; named owner ___; response expectation ___; unresolved-case visibility ___.
12. Audit and evidence retention: Inputs, sources, approvals, actions, outputs, corrections, exceptions, and control events retained at ___ for ___.
13. Business-outcome monitoring: Outcome measure ___; baseline/target boundary ___; review owner/cadence ___.
14. Quality and correction monitoring: Acceptance rule ___; material correction measure ___; review sample/cadence ___; owner ___.
15. Latency, failure, and control monitoring: Completion/failure signals ___; latency signal ___; missed approval/prohibited-action signals ___; alert owner ___.
16. Deployment and cutover plan: Release owner/date ___; initial users/volume ___; parallel or phased check ___; communication/support path ___.
17. Rollback trigger: Failed control, prohibited action, quality, workload, reliability, data, or service condition that requires pause/rollback ___.
18. Rollback procedure: Who acts ___; disable/revoke/revert steps ___; in-flight work handling ___; evidence and notification path ___; test date/result ___.
19. Change-control boundary: Changes requiring a new review include scope, identity, permission, data, tool, instruction, model, approval, owner, or monitoring changes; change owner/process ___.
20. User and operator training: Who is trained ___; correct use ___; prohibited use ___; approval/exception/stop steps ___; support owner ___.
21. Review date and evidence window: First production review ___; cases/time period ___; evidence required ___; attendees ___.
22. Final disposition: Ready / Ready with conditions / Not ready; decision owner/date ___; conditions, owners, due dates, and next evidence date ___.

The gate is not complete because every checkbox contains text. The evidence must support the answer, and the person named as owner must understand the authority and work attached to the role.

A compact readiness rubric

There is no universal production score that fits every workflow. A low-consequence internal lookup and an agent that can commit money or communicate externally should not share the same thresholds. Judge the evidence against the approved workflow, consequence, case mix, and pilot charter.

Ready

Use Ready only when the production boundary is explicit, required owners have accepted their roles, permissions are least-privilege, human approvals and prohibited actions are enforced, representative and failure tests passed, the exception path works, monitoring is active, operators are prepared, and rollback has been tested.

Ready authorizes the boundary recorded in the worksheet. It does not authorize unrelated workflows, new systems, broader permissions, higher-consequence actions, or silent removal of human approval.

Ready with conditions

Use Ready with conditions when a narrow production start is justified but named conditions must remain in force. Examples might include limited users, limited volume, retained parallel review, a shorter monitoring cadence, or one evidence item that can be closed safely inside the approved boundary.

Each condition needs an owner, due date, evidence expectation, and consequence. If a condition expires or fails, the agent pauses, rolls back, or returns to review as recorded. Do not use this disposition to hide an unresolved control failure.

Not ready

Use Not ready when the production boundary or evidence cannot support go-live. Record what failed, who owns the next step, what evidence would reopen the gate, and whether the pilot remains paused, returns to a changed test, or stops.

A missing owner, unbounded permission, untested rollback, prohibited action, failed control, or unowned material exception prevents an unconditional Ready result. Missing proof stays UNPROVEN even when average pilot metrics look positive.

Monitor the operating result, not just uptime

Technical availability is necessary, but an agent can be online while creating bad work or moving hidden effort to people. A useful production review keeps five views together:

1. Business outcome: Did the approved workflow improve in the same unit used for the baseline and pilot decision?
2. Quality and corrections: How often did outputs meet the agreed standard without a material correction, and where did correction work concentrate?
3. Exceptions: Which cases left the routine path, how quickly did they reach the named owner, and what remains unresolved?
4. Latency and failures: Did the agent complete the job inside the operating expectation, and did timeouts, duplicates, partial work, or tool failures increase?
5. Controls: Did required approvals, source boundaries, prohibited-action blocks, and stop behavior work every time they were needed?

Use the AI agent pilot metrics scorecard to preserve comparable measures. Do not average a control failure into a favorable result.

Run the production readiness review in 45 minutes

Pre-read: send the boundary and evidence

Before the meeting, send the pilot decision, completed production-gate worksheet, permission map, representative and failure test results, exception path, monitoring view, rollback runbook, training record, and every UNPROVEN item. The review should decide whether the evidence supports go-live, not spend its time finding documents.

Minutes 0-10: confirm scope, identity, and permissions

Read the approved workflow, intended outcome, in-scope actions, and out-of-scope actions aloud. Confirm the runtime identity, tools, data, and least-privilege rights. Make sure the production boundary matches the pilot decision and has not expanded through implementation convenience.

Minutes 10-20: review human authority and controls

Walk through each human approval point, prohibited action, and no-response behavior. Confirm what evidence the approver sees and how the system behaves when approval is absent, late, or denied. A human approval label is not a control unless the action actually waits.

Minutes 20-30: review tests, exceptions, and evidence

Review representative cases, failure cases, exception routing, unresolved items, and audit retention. Confirm that out-of-scope and failure inputs lead to a safe stop, handoff, or bounded response instead of improvisation.

Minutes 30-38: confirm monitoring, cutover, and rollback

Check that business outcome, quality, corrections, exceptions, latency, failures, and controls have owners and visible signals. Review the initial users and volume. Name the rollback trigger, then have the owner explain the rollback steps and evidence from the latest test.

Minutes 38-45: record the disposition

Choose Ready, Ready with conditions, or Not ready. Record the accountable decision owner, date, conditions, next evidence date, and first production review. If the required proof is missing, mark it UNPROVEN and choose the disposition the actual evidence supports.

Keep production change inside a governed boundary

The readiness gate should reopen after a material change to the workflow, identity, permissions, source data, connected tools, model or instructions, human approval, prohibited actions, exception path, ownership, or monitoring. A production agent should not accumulate authority through a series of changes that each looked too small to review.

Microsoft 365, Teams, Copilot Studio, Power Platform, Fabric, and Power BI can provide useful delivery, evidence, and monitoring rails where they fit. The platform does not own the operating decision. A named business owner retains authority, supported by a technical owner who can observe, pause, and roll back the system.

That pattern connects practical AI Agents with Executive Intelligence and AI strategy: the work is visible, ownership is explicit, evidence travels with the decision, and human authority stays intact.

If the workflow has not earned a production decision yet, return to the AI agent readiness checklist and the 30-day AI agent pilot plan. If the pilot is complete, use the pilot decision template before opening this gate.

Bring one approved workflow, its pilot evidence, and the owners who will operate it. Leave with a bounded production decision and a rollback path everyone can explain.

Once the agent is live, use the AI agent post-launch review to compare the first 30 days of business results, quality, human burden, exceptions, controls, and scope changes before choosing Continue, Change, Pause, or Roll back.

Book an AI Operating Review

FAQ

What should an AI agent production readiness checklist include?

Record the approved workflow and outcome, in-scope and prohibited actions, accountable owners, least-privilege permissions, human approval points, representative and failure tests, exception handling, evidence retention, monitoring, cutover, rollback, change control, operator training, review date, and a final Ready, Ready with conditions, or Not ready disposition.

When is an AI agent ready for production?

An agent is ready when the approved boundary is explicit, required evidence is current, owners and human approval points are named, permissions are bounded, representative and failure tests pass, exceptions have a working path, monitoring is active, and rollback has been tested. Positive pilot averages do not override a failed control.

What does Ready with conditions mean for an AI agent?

Ready with conditions authorizes only a named production boundary while specific evidence, safeguards, volume limits, or review conditions remain in force. Give every condition an owner, due date, evidence expectation, and consequence. It is not permission for an open-ended rollout.

What should prevent an unconditional Ready decision?

A missing accountable owner, unbounded permission, untested rollback, prohibited action, failed control, unowned material exception, or missing required proof should prevent an unconditional Ready decision. Record missing proof as UNPROVEN.

How often should production readiness be reviewed?

Set the first review date before go-live, then use a cadence matched to the workflow’s consequence, change rate, exception pattern, and operating volume. Reopen the gate after a material scope, permission, data, tool, instruction, approval, or ownership change.