What do I check before approving an AI agent for production? I require evidence across seven gates: a defined job, controlled permissions, representative evaluations, observable actions, reliable escalation and recovery, accountable operational ownership, and acceptable economics. A strong demo is useful discovery evidence. It is not production approval.
I approve an operating system, not a model demo
When I review an AI agent, I am not asking only whether the model can produce a good response. I am asking whether the whole operating arrangement can do a bounded job repeatedly, inside explicit authority, with evidence that a business can inspect and act on.
That distinction matters because an agent combines probabilistic decisions with deterministic systems. It may retrieve data, choose tools, update records, send messages or wait for a person. A failure can therefore sit in the instructions, retrieved context, permission model, integration, tool result, retry logic, user interface or human process—not only in the model.
NIST's AI Risk Management Framework is useful here because it links governance, context mapping, measurement and management. It says systems should be tested before deployment and regularly in operation, with roles, oversight, incident response and deactivation mechanisms documented. My seven gates translate those broad outcomes into a practical production decision for one agent and one workflow.
Shuhaib's seven-gate production approval
I review the gates in order because weak foundations contaminate later evidence. There is little value in a large evaluation set when the job is still ambiguous, or a beautiful dashboard when the agent holds more authority than the workflow requires.
| Gate | Pass condition | Evidence I expect | Common failure |
|---|---|---|---|
| 1. Defined job | One bounded outcome, named users, accepted inputs and explicit non-goals | Role canvas, workflow map, acceptance criteria and out-of-scope list | The agent is described as a general assistant, so nobody can say when its work is complete |
| 2. Controlled authority | Least privilege, separated read/write powers, approvals and tested revocation | Tool register, data map, permission matrix and approval policy | A correct answer can still trigger an excessive or irreversible action |
| 3. Representative evaluation | The full system passes normal, edge, adversarial and failure cases at agreed thresholds | Versioned eval set, rubric, results, failure analysis and regression baseline | A polished demo hides failures on ambiguous records, missing context and conflicting instructions |
| 4. Observable execution | Operators can reconstruct what happened without exposing unnecessary sensitive reasoning or data | Run IDs, tool-call records, state transitions, outcomes, latency, cost and alert rules | The team sees a wrong record but cannot identify which input, decision or tool action caused it |
| 5. Escalation and recovery | The agent stops safely, preserves context and reaches an available accountable human | Trigger matrix, handoff packet, retry limits, rollback or compensation path and incident drill | Escalation exists in the prompt but no queue, owner or recovery procedure exists in operations |
| 6. Operational ownership | Named people own the workflow, controls, model or vendor changes, incidents and retirement | RACI, support rota, change process, dependency register and deactivation procedure | The builder finishes the pilot and nobody owns drift, policy changes or vendor outages |
| 7. Acceptable economics | Cost per accepted outcome and review burden are tolerable at realistic volume | Volume model, accepted-outcome rate, human-review time, exception cost and stop/scale thresholds | Low token cost masks expensive review, rework, latency, failed actions or support effort |
Download the seven-gate production-readiness review worksheet and use it to record evidence, owners, decisions and post-launch limits.
Gate 1: Is the agent's job defined well enough to test?
I start with the job because “help the operations team” is not testable. I want one primary outcome, a start event, authorised inputs, a completion state, non-goals and a named person who accepts the result. If the job crosses departments, I separate the responsibilities rather than pretending one broad instruction creates accountability.
A good production statement sounds like this: “For inbound service requests that meet the documented eligibility rules, collect the required evidence, draft a classification and prepare a proposed response. Stop before changing entitlement or sending the response when evidence is missing, policy conflicts or customer harm is plausible.” It defines useful work and also tells the agent when not to act.
The first failure I look for is scope drift. During a demo, a user may ask a nearby question and receive a plausible answer. In production, that helpful improvisation can bypass the workflow owner, use an unapproved source or create a commitment the business did not intend. Explicit non-goals and completion criteria turn “helpfulness” into a governed job.
Gate 2: Can the agent do only what the job requires?
Permissions should describe actions, not just applications. “CRM access” is too broad. The useful questions are whether the agent may read a contact, export a segment, create a note, change an opportunity stage, delete a record or message a customer. Each action has a different consequence, reversibility and approval need.
I expect least-privilege service identities, separated read and write tools, constrained parameters, data minimisation, a reliable revocation path and human approval before sensitive or irreversible side effects. OpenAI's current agent guidance similarly treats guardrails as layered controls that must sit alongside authentication, authorisation, strict access control and normal software security. Its human-review guidance distinguishes automated validation from an approval that pauses a sensitive action.
Prompt instructions are not an access-control system. If an agent should never issue a refund above a limit, the deterministic tool or business system should enforce that limit. OpenAI's 2026 prompt-injection guidance makes the same architectural point: assume an agent exposed to external content may be manipulated, then constrain the impact through capability limits.
Gate 3: Has the whole system passed representative evaluations?
I do not accept “we tried it with ten examples.” The evaluation set must reflect the production distribution: normal work, missing fields, stale data, conflicting records, unusual language, policy exceptions, adversarial instructions, tool timeouts, duplicate requests and cases that must escalate. It should test the full path, including tool choice, arguments, state changes and final outcome.
Before running the cases, I require a rubric and thresholds tied to consequence. The team should agree what counts as task success, a critical policy breach, an acceptable escalation, an incorrect write and an incomplete handoff. A single average score can hide a severe failure, so critical controls need gate metrics: for example, zero unapproved high-impact actions in the evaluated set, plus a documented response for every discovered critical defect.
OpenAI's evaluation guidance recommends task-specific tests that reflect real-world distributions, logs that can supply future cases, human calibration and continuous evaluation on changes. NIST likewise calls for deployment-like conditions, documented test sets and metrics, and production monitoring. I therefore want a versioned baseline that can be rerun when the model, prompt, tool, knowledge source or policy changes.
Gate 4: Can an operator reconstruct and diagnose a run?
Production observability is more than storing the final chat. I want a run identifier; versions for the model, instructions and knowledge source; the major state transitions; tool names and validated arguments; tool outcomes; approvals; escalations; final business outcome; latency; and cost. Sensitive content should be minimised or protected, but the operational record must still answer: what happened, what changed and who accepted it?
The dashboard should connect technical events to business acceptance. A low error rate is not meaningful if employees reject half the proposed work. I look for accepted outcomes, correction rate, exception rate, unauthorised-action attempts, handoff quality, time to detect, time to recover and cost per accepted outcome. Alert thresholds should map to an owner and a response, not merely generate another ignored notification.
A recurring review observation is that teams log model calls yet cannot trace the downstream write. The production unit is the workflow run. Evidence must connect the triggering request through decisions and tools to the final record or message.
Gate 5: Will it stop, escalate and recover safely?
I ask the team to demonstrate escalation rather than show me a sentence in the prompt. We trigger uncertainty, missing permissions, policy conflict, emotional customer language, repeated tool failure and a high-impact request. The agent should stop at the correct boundary, preserve the relevant context, explain what is unresolved and deliver the case to an available person with the authority to decide.
The handoff must be decision-ready: request, relevant evidence, checks completed, actions already taken, uncertainty, recommended next step and deadline. Retries need limits. Partially completed side effects need an idempotent retry, rollback or compensating action. The operator also needs a kill switch or deactivation procedure when behaviour departs from intended use.
OpenAI's practical guide highlights failure thresholds and high-risk actions as triggers for human intervention. NIST calls for appeal, override, incident response, recovery and decommissioning in post-deployment plans. I treat those as production functions, not policy-page promises.
Gate 6: Who owns the agent after the launch meeting?
Every production agent needs an accountable workflow owner, a technical steward and named control owners. The workflow owner accepts business outcomes. The technical steward manages versions, integrations and observability. Control owners maintain data, permissions, evaluation, escalation and incident procedures. One person may hold several roles in a small business, but the responsibilities cannot be anonymous.
I also check the change path. A model update, vendor change, new data source, expanded tool scope or policy revision can invalidate earlier evidence. The team needs impact classification, regression tests, approval for material changes and a record of what reached production. Third-party dependencies need contingency plans, because a reliable internal design can still fail when a model, API or knowledge source changes.
Gate 7: Does the agent create accepted value at a tolerable cost?
Token cost is only one line. I calculate cost per accepted outcome using model and tool charges, infrastructure, monitoring, human review, corrections, failed actions, vendor support and ongoing maintenance. I compare that with the baseline workflow's labour, delay, error and customer impact.
The volume model should include peaks, long-tail cases and the review burden that appears after launch. An agent that drafts quickly but requires a senior person to inspect every detail may be useful as an assistant, yet fail the case for autonomous action. That is not a failed project; it is evidence for a simpler operating mode.
I want explicit stop, hold and scale thresholds. If accepted-outcome rate drops, critical exceptions appear, cost rises beyond the tolerance or review capacity is exceeded, the team should know whether to restrict scope, return to manual processing or pause the system.
My approval outcomes are deliberately not binary
| Outcome | Meaning |
|---|---|
| Approve for limited production | All critical gates pass; residual risk is documented; initial scope, volume and authority stay bounded |
| Approve with conditions | No critical control is missing, but a dated action, tighter limit or enhanced monitoring is required |
| Return for rework | Evidence is incomplete or a control fails; the owner must correct it and repeat the affected evaluation |
| Reject or simplify | The use case, autonomy or economics remain unjustified; use a deterministic workflow, assistant or manual step instead |
Conditional approval is not permission to leave a critical gap unresolved. It is for bounded residual work with an owner and date—for example, increasing a low-risk evaluation sample during a limited rollout while a hard approval gate already protects every write. Missing revocation, no incident owner or failed high-impact controls require rework.
The review packet I expect before the decision
A production review should be possible from a compact evidence packet, not a tour of scattered documents. I ask for the job and workflow map; data and tool inventory; permission matrix; evaluation plan, results and unresolved failures; representative traces; escalation and recovery drill; architecture and dependency register; ownership and support model; security and privacy review; cost model; rollout limits; and post-launch dashboard.
The packet should show versions and dates. If a critical component changed after the evidence was produced, the team must identify which gates need to be rerun. Evidence freshness is part of readiness.
Production approval starts a tighter learning loop
I normally recommend a limited launch: narrow users, narrow cases, constrained authority, visible review and an explicit expansion decision. During the first day, verify identity, logging, approvals, alerts and escalation routing. During the first week, review every critical exception and a sample of accepted work. At 30 days, compare production outcomes, corrections, incidents, cost and user feedback with the baseline and approval thresholds.
After that, review on material changes and at a cadence proportionate to risk. New failure cases should enter the evaluation set. Permissions that are not needed should be removed. Controls and escalation rules should change when the workflow or consequence changes. The production system earns broader autonomy through evidence; it does not receive it because time has passed.
My final question is simple: if this agent is wrong at 2:00 AM, can the business limit the harm, see what happened, reach the right person, recover the workflow and learn from the event? If the answer is unclear, the agent is not ready for broader production authority.
Primary sources
- NIST — AI Risk Management Framework Core
- OpenAI — Evaluation best practices
- OpenAI — Guardrails and human review
- OpenAI — A practical guide to building agents
- OpenAI — Designing AI agents to resist prompt injection
Continue the implementation path
- How to evaluate an AI agent before launch
- AI agent observability for SMEs
- My framework for delivering AI automation projects
Replace launch confidence with launch evidence
Book an AI agent production-readiness review
I review the workflow, authority, evaluation evidence, traces, escalation path, operating ownership and economics before a team expands an agent's production scope.
Book a production-readiness review