A demo proves an agent can do the task once, on a good day, with someone watching. Production asks a harder question: what does it do on the bad day, unwatched, at 2 a.m., against an input nobody thought to test? The gap between those two is where most agent projects actually stall — not in getting something working, but in trusting it enough to remove the human from the loop.
These are the nine criteria we check before recommending a client give an agent write access to a real system. Not all nine apply with equal weight to every use case, but skipping any of them without a deliberate reason is how "the demo worked" becomes an incident report.
1. Bounded permissions
The agent should hold the minimum access the task requires, not the access that was easiest to grant during development. If it only needs to read three tables and write to one, its credentials should reflect exactly that — not a service account with broad access nobody's gotten around to narrowing.
2. A defined failure mode
Ask what the agent does when it's uncertain, not just when it's confident. A system that guesses plausibly when it doesn't know is more dangerous in production than one that stops and asks — because the failure is silent until someone downstream notices the damage.
3. Reversibility
Can the agent's actions be undone, and how expensive is the undo? An agent that sends an email can't unsend it; an agent that drafts one for a human to send can. Where the action is genuinely irreversible, that's the strongest argument for keeping a human in the loop at that specific step, even if everything upstream is automated.
4. Tracing, end to end
Every action the agent takes should be attributable to the specific input, reasoning step, and tool call that produced it. When something goes wrong — and eventually something will — "we don't know why it did that" is not an acceptable answer to give a customer or an auditor.
The check we run first
Pull up the trace for the agent's worst production output over the last week and ask the team to explain, from the trace alone, exactly what happened. If they can't, tracing isn't done yet — regardless of how complete the dashboard looks.
5. Evals that cover the edges, not just the happy path
A test suite that only exercises the cases the agent was designed for tells you nothing about the cases it wasn't. Production-ready evals include adversarial and malformed inputs, ambiguous requests, and the specific edge cases your domain experts already know break things — not just a clean set the model was tuned against.
6. Circuit breakers
Something needs to be watching for the agent doing the same wrong thing repeatedly, at volume, and stopping it automatically before a human notices. A rate limit on consequential actions, and an automatic pause when error rates spike, turns a bad ten minutes into a non-event instead of a cleanup project.
7. A human escalation path that's actually used
The agent needs a clear, well-tested path to hand off to a human when it's outside its competence — and that path needs to be one the team actually monitors, not a queue that fills up and gets checked once a week. An escalation path nobody watches is the same as no escalation path.
8. Monitoring tied to business impact, not just system health
Uptime and latency dashboards tell you the agent is running. They don't tell you it's right. Production monitoring for an agent needs a metric tied to the actual business outcome — resolution rate, error cost, customer escalations — not just whether the service is up.
9. A rollback plan that doesn't require a deploy
If the agent starts misbehaving, turning it off — or reverting to the previous prompt, model, or policy version — should be a fast operational action, not a code change that has to go through a release process. The teams that recover fastest from a bad agent release are the ones who built the kill switch before they needed it.
None of these nine criteria are about making the agent smarter. They're about making the system around it trustworthy enough that being wrong sometimes doesn't become a crisis.
Using this as a gate, not a checklist
The point isn't to treat this as a box-ticking exercise before launch. It's to have an honest, criteria-by-criteria conversation about which of the nine your agent is weakest on, and to decide deliberately — not by default — whether that gap gets closed before it touches a real system, or gets mitigated by keeping a human in the loop at that specific point.
Weighing whether an agent is actually ready for production? Talk to us — we'll run this checklist against your specific system.