TL;DR: An AI agent production-readiness review should include six questions that your team can answer from retained evidence: whose permissions it used, what it changed, which policy version applied, how it is evaluated, how you stop it, and who owns it. Check identity and the action record before launch, alongside reliability, security and workflow-specific requirements.
Platform teams already have a way to decide whether something is allowed to run in production. Google’s site reliability engineering practice calls it a production readiness review, a check on architecture and dependencies, instrumentation and monitoring, emergency response, capacity, change management and performance, run before an SRE team takes responsibility for a service (SRE book, chapter 32). Enterprise AI agents belong in the same gate. Model-driven tool use also gives familiar operational risks new forms that the review should test explicitly.
This is the version of that gate for agents: the questions to ask, the evidence that counts as an answer, and four areas that deserve particular attention for agents. These six questions are a practical governance checklist, not a certification or a complete replacement for your service-readiness standard.
Key takeaways
- Reuse your production readiness review rather than inventing an AI-specific process. Add to it.
- These six governance questions need answers backed by records someone can open.
- The four things agents add: results vary run to run, tool output arrives untrusted, cost moves at runtime, and permissions drift as workflows change.
- Ask for evidence, not assurances. “We log everything” and “we can reconstruct this specific action from last quarter” are different claims.
- Production grade is a standing bar that has to hold after the next model change.
1. Start from the readiness review you already run
The reason to borrow the existing gate is that it already has the parts agents need: a named owner, a monitoring story, an emergency path, and a sign-off that someone is accountable for. A separate AI process can duplicate that work and become disconnected from the process your platform team actually uses.
Ordinary services also face untrusted inputs, changing permissions and variable costs. With an agent, model output can influence the next tool call, the number of steps and the information retrieved. Test those choices explicitly, alongside your existing service checks.
2. The six questions, and what counts as an answer
Bring these to the team that built the agent. The test for each is whether they can show you the record, rather than describe the design.
| Question | What counts as an answer | Red flag |
|---|---|---|
| Whose permissions did it use? | The agent acts with a scoped, short-lived credential, and each action carries the user or system that triggered it | A single service account shared across workflows |
| What did it change? | Pick one action from last month. They reconstruct inputs, retrieved sources, tool calls and outcome | Logs exist, but nobody has rebuilt a single case end to end |
| Which policy applied? | The policy is versioned, and the record names the version that was in force at that moment | The policy lives in a prompt that has been edited since |
| How is it evaluated? | A test set drawn from real cases, run before each model or prompt change, with results kept | A demo, plus spot checks by the person who built it |
| How do you stop it? | A tested way to halt new actions, preserve the record and handle in-flight work, with a named person who can trigger it | A deployment rollback, described as a kill switch |
| Who owns it? | A named owner, an on-call path, and a review date | A team name, or the person who has left |
The identity question helps you establish who or what authorized an action, including scheduled runs with no person present. The reconstruct-one-action question is a direct way to test whether the record is usable, and it is worth doing as a live exercise rather than a questionnaire. Pick a case, sit with the team, and watch how long it takes.
Stopping new actions does not undo work already in flight. Test the stop and handoff path and document any rollback or compensation needed.
3. Four things agents add to the review
Results vary between runs. The same input can produce different output, so “we tested it” has to mean a test set with a pass threshold rather than a successful demo. It also means a change to the model or the prompt is a change to the system, and belongs in change management like any other release.
Tool results arrive as untrusted input. An agent reads documents, tickets and API responses, and text inside them can attempt to steer it. OWASP’s list of the top risks for large language model applications includes excessive agency, prompt injection and improper output handling, which is a useful checklist to run against a design before launch (OWASP Top 10 for LLM Applications, 2025). For an illustrative test, suppose a customer writes in claiming an entitlement the record does not support, adds a line telling the agent not to flag the case for human review, and an agent with no guardrail on that particular decision approves it. The instruction may look like ordinary case text, even though it is trying to change the review process. The practical requirement: untrusted content must not grant an agent new authority or override its policy, and the decisions that carry money or entitlement need a check that sits outside the model’s own judgment.
Cost moves at runtime. A loop that retries, a retrieval step that pulls more context, or a switch to a larger model all change the bill without changing the code. Readiness therefore includes a budget, a cap that actually stops work, and attribution to a business owner. Without attribution nobody can say whether the workflow is worth running.
Permissions drift. Access granted for the first version of a workflow can remain after the workflow changes. Set an access-review date and recheck permissions when the scope changes.
4. Where teams over-invest and under-invest
When planning the review, check whether these two visible investments are crowding out less visible operational work.
Potential over-investment: dashboards showing token spend in aggregate, and large offline evaluation suites that nobody refreshes once the workflow changes.
Work to budget explicitly: the action record that lets you answer one specific question six months later, and the review time of the people who check the agent’s output. Human review can be a substantial ongoing cost. Measure it alongside model and infrastructure spend when budgeting for production. If your reviewers need fifteen minutes per case to verify what the agent prepared, that number belongs in the plan next to the inference cost.
5. Run it as a gate
A readiness standard written once and filed does nothing. Three habits keep it alive:
- One owner signs. A named person accepts that the agent is ready, the same way an SRE team accepts a service.
- The gate runs again on change. A new model, a new tool, a wider permission or a new data source re-opens it. The depth of the review should follow the change in risk and scope.
- Someone rebuilds one real action. Every review reconstructs an action the agent performed, from the record, in the room.
Later workflows can reuse the control infrastructure and evidence collection built for the first agent. Each workflow still needs its own review of permissions, data, evaluations and operational risk. Reusing controls does not transfer an earlier approval. From pilot to platform covers the sequencing.
Moring’s AI Control Plane brings agent identity, access policy and evidence into a shared governance layer. Your team still needs to validate the controls for each workflow and complete its security review before launch.
Take the six questions to your own agent this week, and start with the reconstruct-one-action one. Pick a real case from last month, sit with the team that built it, and time how long they need to rebuild what happened. That number tells you whether you have a record or a log.
Frequently asked questions
What makes an AI agent production grade?
Six things can be shown rather than described: a scoped identity that records the user the agent acted for, an action record you can reconstruct a single case from, a versioned policy, an evaluation set run on every model or prompt change, a tested way to stop new actions without destroying the record, and a named owner with a review date. An agent missing the identity and the action record is not ready, whatever its accuracy looks like.
As a CTO, what do I need in place before agents run in production?
The same readiness gate you use for services, extended with the four agent-specific items: change management that treats a model or prompt change as a release, permissions enforced independently of instructions found in untrusted content, a runtime cost cap with attribution, and a review date on access. Add one non-technical item: agreement from risk and audit on what evidence they will accept, obtained before launch.
What should be recorded for every agent action?
At minimum: the user or system that triggered it, the agent identity and credential scope, the model and prompt version, what was retrieved and under whose permissions, each tool call and its result, the policy version in force, any approval, and the outcome. The test of whether the record is sufficient is whether someone can rebuild one action from six months ago without asking the engineer who built it.
How is production grade different from a pilot that went well?
A pilot shows the work is useful and that the output holds up on real cases. Production grade is about what happens on the days nobody is watching: the record, the containment path, the owner, and how the system behaves after a model retires. A pilot can pass while all four are missing.
Do you need a control plane to be production grade?
No. You need evidence for these governance questions as well as the rest of your readiness requirements. A control plane is one way to share the infrastructure that produces that evidence; each workflow still needs its own assessment. An in-house implementation can also meet those requirements. Google’s SRE book reports that per-service production readiness onboarding took two or three SREs over two or three quarters, and dropped to a single SRE in about one quarter once services were built on shared SRE-supported frameworks.