Graduated deployment: raising agent autonomy without incidents
A five-stage path — dry-run, read-only, simulation, staging, production — for giving an AI agent more autonomy only after evidence says it is safe.
Definition
Graduated deployment is the practice of rolling out an AI agent's autonomy in stages — dry-run, read-only, simulation, staging, then production — where each stage adds real consequence only after the previous one has proven safe. It raises autonomy on evidence rather than optimism.
The fastest way to lose trust in an agent is to give it full autonomy on launch day and discover its failure modes in production. Graduated deployment is the opposite: autonomy is earned, one stage at a time.
The five stages
- Dry-run. The agent proposes actions but executes nothing. You read its intended tool calls and reasoning. This surfaces obviously bad plans for free.
- Read-only. The agent touches real systems but cannot change them. You confirm it retrieves the right things and chooses the right tools, without risk.
- Simulation. Actions run against a sandbox that mimics production. Now you see end-to-end behavior, including writes, with no real consequence.
- Staging. Limited real actions under heavy monitoring, ideally scoped to low-stakes or reversible operations.
- Production. Autonomy scoped to exactly what the evidence supports — and no further.
| Stage | What the agent may do | What you learn |
|---|---|---|
| Dry-run | Proposes actions, executes nothing | Whether the plan is sane |
| Read-only | Reads real systems, makes no changes | Whether it retrieves and chooses well |
| Simulation | Acts against a sandbox | End-to-end behaviour, including writes |
| Staging | Limited real actions, monitored | Behaviour under real consequence |
| Production | Autonomy the evidence supports | Ongoing, scoped operation |
When do you advance a stage?
The discipline is in the gates. Do not advance because a week passed; advance because the current stage cleared thresholds you set in advance:
- task completion rate above your bar,
- faithfulness / hallucination within limits,
- cost per task stable,
- zero critical incidents over a defined window.
These come from your evals and observability. If a stage cannot clear them, that is information, not a delay.
Per-action, not per-system
The biggest practical gain is granularity. The same agent can be in production for drafting suggestions and still in read-only for anything that moves money or data. Map each capability to its own autonomy level — this is the HITL / HOTL / HOOTL spectrum applied action by action.
Why this satisfies governance too
Regulators expect meaningful human oversight for higher-risk uses. A graduated rollout produces exactly the evidence trail they want: documented stages, thresholds, and a record of why each autonomy increase was justified. It turns “we were careful” into something you can show. See governance for the audit-log side, and the glossary for terms.
Starter checklist
- Start every new agent in dry-run.
- Write the thresholds before you start, not after.
- Keep a kill switch active at every stage.
- Advance one capability at a time, on data.
Frequently asked questions
Why not just launch the agent in production?
Because an agent's real failure modes only appear under real conditions, and in production a failure carries real cost — lost data, wasted spend, a damaged customer interaction. A demo or a test run shows you the happy path, but the loops, bad tool calls, edge cases and emergent behaviours that actually bite tend to surface only when the agent meets messy real inputs at volume. Graduated deployment lets you observe that behaviour with the stakes rising slowly, so you discover the problems while the blast radius is still small and recoverable rather than after they have caused an incident. It also gives you a defensible story: each increase in autonomy rests on evidence from the previous stage rather than on optimism. Launching straight to full production autonomy collapses all of that risk into a single moment with no safety net, which is the fastest way to lose trust in an agent and, often, to trigger the very incident that sets the whole programme back. Earn autonomy in stages; do not gamble it on a launch day.
How do I know when to advance a stage?
Advance on evidence, not on the calendar — the gate is data, not the fact that a week has passed. Before you start, define explicit thresholds the current stage must clear: a task completion rate above your bar, faithfulness or hallucination within limits, cost per task stable, and zero critical incidents over a defined window. Then you only move to the next stage when the current one actually meets them, drawn from your evals and observability rather than from a sense that it feels ready. The discipline cuts both ways: clearing the thresholds is permission to advance, and failing to clear them is information, not merely a delay — it tells you the agent is not yet safe at this level and points at what to fix. Writing the thresholds down in advance is what stops the gate from quietly softening under schedule pressure, where confidence substitutes for proof. The question at each boundary is never how long has it been, but has it earned the next level of consequence on the numbers you agreed to.
Does this apply to a single agent or the whole system?
Both, but the granularity that actually pays off is per action, not per agent or per system. Treating autonomy as one switch for the whole agent forces a false choice between caution everywhere and risk everywhere; in reality an agent's actions differ enormously in stakes. So the useful pattern is to let the same agent sit at different stages for different capabilities: in full production for low-risk, reversible actions like drafting a suggestion, while still in read-only for anything that moves money, deletes data or sends external communications. Each capability advances on its own evidence, so a strong track record on safe actions never silently buys autonomy for dangerous ones. This is the same per-action principle as the HITL, HOTL and HOOTL oversight spectrum, applied to rollout: you are not asking whether the agent is ready, but whether this specific action is ready. Mapping capabilities to their own autonomy levels is what lets you move fast where it is safe and stay cautious exactly where it matters.
What happens if a stage fails — do I roll back?
Yes, and the ability to drop back a level cleanly is one of the main reasons to deploy in stages in the first place. If the current stage fails to clear its thresholds, or a critical incident occurs, you return the affected capability to the previous, safer stage rather than ripping the whole agent out of production or pushing forward and hoping. Because each stage is a defined level of consequence, a rollback is a controlled move with a known-good state to return to, not an emergency. A failure should also feed back into the system: turn the specific failure into a regression test in your evals so it cannot silently recur, and only re-advance once the fix has cleared the same gate. Keep a kill switch active at every stage so you can halt immediately while you decide, and log the rollback for governance and post-incident review. Treat a failed stage as the process working as intended — it caught a problem early, while the blast radius was small — rather than as a setback, and re-earn the level on evidence.