How do you know if an AI agent is production ready?
The checks below are the ones that separate an agent you can run unattended from one that quietly costs you customers.
The short answer
5 things that decide this
- 01An AI agent is production ready when a fixed set of scored test cases measures its accuracy, rather than a demo someone runs by hand.
- 02Every tool it can call is scoped to one job. Actions you cannot undo need a person.
- 03Any past run can be replayed: the inputs, the tools it chose, the arguments, and what came back.
- 04A named person gets paged when it fails, and a stop rule ends a run that loops or overspends.
- 05You have a written plan for the day your provider retires the model underneath it.
A demo tests the happy path only
Demos are run by the person who built the thing, with an input they chose. Of course it works. What you actually care about is the other failure: the agent takes a defensible wrong action, and the run still reports success.
Readiness is not a feeling, and the usual signals mislead. A demo that impressed a board proves the model can do the task once, in conditions somebody chose. Production asks a different question: what happens on the input nobody anticipated, at 3am, when no one is watching. RAND also cites estimates that more than 80% of AI projects fail, about twice the rate of IT projects without AI. Note the hedge. RAND calls that an outside estimate, not its own finding. Its own evidence is 65 interviews with AI engineers.
So the readiness question is mostly an organisational one. Can you tell, next Tuesday, whether the agent is doing the job?
Six questions, and what a passing answer sounds like
Take these to whoever built the agent. Vague answers on the first two are the ones that cost money later.
| Check | A passing answer | What a failing answer sounds like |
|---|---|---|
| Accuracy | A fixed set of scored cases, run on every change, with the score written down. | "It's been working well in testing." |
| Permissions | Each tool scoped to one job. Irreversible actions need a person. | One API key with admin rights on everything. |
| Traceability | Any run from last month replayed: inputs, tool calls, arguments, results. | Logs show that the run finished. |
| Stop rules | A cap on steps, spend and time. Hitting it escalates to a human. | The loop ends when the model says it is done. |
| Ownership | A named person is paged, under an agreed service level. | "The team keeps an eye on it." |
| Model exit | A written plan for a model retirement, with the test set to prove the replacement. | The model id is hardcoded in one file and nobody has looked at it since. |
- CasesReal inputs, including the ugly ones.
- ScoreEach run graded against expected.
- CompareAgainst the last known-good score.
- GateBelow the bar, it does not ship.
- WatchSame scoring, live, after release.
The last node is the one teams skip. An agent that passed in March can drift by June with no code change at all.
Your model has a retirement date
Model providers retire models, and a retired model returns an error rather than a worse answer. Anthropic publishes a deprecation page listing retirement dates and promises at least 60 days' notice before retiring a publicly released model. Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August 2026, which is the pattern in practice, not a hypothetical.
Sixty days is enough time if you have a scored test set. Swap the model, run the cases, compare. Without one you are re-testing by hand under a deadline, and prompts tuned to a retiring model often score worse on its replacement.
- 01Keep the model id in configuration, never inline in a prompt file.
- 02Subscribe someone real to your provider's deprecation notices.
- 03Re-run the test set against the replacement before the retirement date, not after.
What people ask next
01How many test cases does an agent need before it goes live?
Enough to cover every failure you have already seen plus the ones that would be expensive, which usually starts around 30 to 50 cases for a single workflow. The count matters less than the source: cases pulled from real inputs beat cases someone invented, and every production bug should become a new case.
02What accuracy is good enough for an AI agent?
There is no universal bar, because it depends on what a wrong action costs and whether a human sees it first. Set the threshold from the cost of the mistake, then measure whether the agent clears it, rather than chasing a percentage someone quoted at a conference.
03Can you make an AI agent fully deterministic?
No, and trying usually means you wanted a workflow. If the same input must always produce the same output, write the steps in code and use a model only for the parts that genuinely vary.
04Who should own an AI agent after launch?
One named person or team, with the same on-call expectations as any other production service. Agents drift as inputs and models change, so an unowned agent degrades quietly rather than staying still.
