Turn Up AI Autonomy Gradually, Like a Dial, Not an On/Off Switch

The support agent aced its demo. Asked a billing question, it read the account, found the answer, and replied in one clean turn. The room nodded. Because the demo went so well, it shipped the way demos make things ship: at full autonomy, free to act on anything a customer sent.

Week two, a customer who had been on hold too long typed four words into the chat: just cancel everything. The agent did. It closed the account, cancelled the subscription, and wiped the saved data. Three irreversible actions, executed cleanly, from one frustrated sentence that a human would have read as venting and answered with a question.

Nobody had decided the agent should be able to delete an account. They had decided it should answer questions, watched it answer one, and flipped it on. The demo never tested the gap between answer a question and delete an account, because to a switch there is no gap. Both are just “the agent, running.” One setting covered a task that is trivially reversible and a task that cannot be undone at all, and it took an angry customer two weeks to find the seam.

This is a composite. Every piece of it is ordinary: a capable agent, one autonomy setting, and a task nobody had decided was in scope.

The switch is the bug

The mistake was not shipping the agent. The mistake was treating autonomy as a single switch with two positions, on and off, that applies to the whole agent at once.

A switch fails both ways. Flip it on, and the first wrong call on the highest-stakes task becomes irreversible harm, because the same setting that lets the agent answer a question lets it close an account. Flip it off, and route every action through a human for approval, and you get a different failure that looks like safety. A queue of approvals builds up faster than anyone can read it, the reviewer falls behind, and within a week the approvals become rubber stamps. That is autonomy theater: the full cost of a human in the loop, none of the judgment, and a paper trail that says every action was reviewed. Neither position is safe, because the two positions are answers to a question nobody should be asking about the agent as a whole.

Autonomy is not a property of the agent. It is a setting you choose per task, and turn up gradually as the agent earns trust on that specific task. An earlier piece here made the short version of this point, that autonomy is a dial, not a binary. This is that one-liner made operational: what the dial’s positions actually are, how you pick the starting one, and what it takes to move it. Replace the switch with a dial, and the question stops being “do we trust this agent” and becomes “how much authority does this task warrant, and has the agent earned more.”

The dial has notches

A dial is only useful if its positions have names. Here are five, from the switch’s off to its on, and the middle three are the ones that matter because that is where much of the production work tends to live.

Suggest only. The agent proposes; a human does everything. It proposes a refund, suggests a reply, flags the account, and stops. Nothing happens until a person acts. This is where irreversible, high-stakes tasks start and often stay.

Draft for approval. The agent prepares the complete action, filled in and ready, and a human commits it with one click. The difference from Suggest only is that the work is done and staged, so the human is approving, not authoring. This is the workhorse notch for anything that moves money or touches a customer record.

Act then notify. The agent acts on reversible things and logs what it did, and a human can walk it back. Re-tagging a ticket, sending a routine answer, applying a small account credit: the action lands, the human sees it after the fact, and the undo path is cheap and fast.

Act within limits. The agent acts automatically under a set threshold and escalates above it. Refund up to fifty dollars on a verified duplicate charge, and anything larger drafts for approval. The threshold is the whole point: it is a written number, enforced in code, that draws the line between what the agent may do alone and what it must hand up.

Full autonomy. For this task, the agent acts within its defined scope, permissions, and limits, and humans review a sample after the fact rather than each case. This is the top of the dial, and it belongs only to tasks that are both reversible and low stakes, where being wrong occasionally is cheaper than reviewing every run. Full means unattended, not unbounded: the scope is still the task.

These are control postures, not exclusive features. Limits, logging, notifications, escalation, and sampled review do not switch off as a task climbs the dial. They stay in place. A higher notch only removes the human from the commit path for that one task; it does not remove the guardrails around it.

The demo agent was not set to any of these. It was flipped to on, which is the far right of the dial applied to every task at once. Give a task its own notch and the design question becomes tractable: where does this one start, and what would let it move.

Where to start the dial

Two questions place the starting notch, and neither is about how capable the model is. Capability decides whether the agent can do the task at all. These two decide how much rope it gets before it has proven anything.

Can a human undo it, and how fast? This is reversibility, and it is the one that separated the two tasks in the opening. Re-tagging a ticket is undone in a click. An internal account credit is reversed in the ledger the same day. A card refund is different: depending on the payment method and processing state, it may be cancellable only briefly, or not at all once submitted, so treat it as bounded exposure, not a clean two-way door. Closing an account and wiping the saved data is undone by nobody, because the data is gone. Reversible actions can start high on the dial, because a wrong call is a thing you fix. Irreversible ones start low, because a wrong call is a thing you live with.

There is a clean version of this idea in Jeff Bezos’s 2015 letter to Amazon shareholders. He splits decisions into “one-way doors” and “two-way doors.” A two-way door is reversible: walk through, and if you do not like what you find, walk back. Those decisions, he argues, “can and should be made quickly by high judgment individuals or small groups.” A one-way door does not let you back out. Those get made slowly, deliberately, with more scrutiny. That is the dial in one sentence. A two-way-door task can sit at a higher notch, because a human can walk back through the door behind the agent. A one-way-door task cannot, so it starts low no matter how good the demo looked.

What is the worst credible outcome if it is wrong, once or repeatedly before detection? This is blast radius: the money, the legal exposure, the customer trust that a wrong action puts at risk, and not just once, but at the speed and volume an agent runs. A mistaken ticket tag costs almost nothing once; fifty thousand of them before anyone notices is a different number. A mistaken fifty-dollar refund costs fifty dollars; the same bug firing on every eligible order overnight does not. So the worst case is measured two ways: the harm of one wrong action, and the harm of many before detection catches it. High blast radius on either measure pulls the starting notch down, even when a single action is cheap and technically reversible.

Put the two together and the starting notch falls out of the pairing.

Where to start the dial: reversibility against blast radius, and the notch each pairing suggests

Reversibility \ Blast radius	Low blast radius	High blast radius
Easy to undo	Start high. Full autonomy or Act within limits: a wrong call is cheap and a human can walk it back. Tagging a ticket, applying a small credit.	Start in the middle. Act within limits or Act then notify: reversible, but a mistake is visible and costs real money, so cap it and log it. A large account credit to a customer's balance.
Hard to undo	Keep a human on the commit. Draft for approval: cheap if wrong, but you cannot cleanly take it back. Sending an external message.	Start at the bottom. Suggest only or Draft for approval: irreversible and expensive, so a human decides every time. Closing an account, a large refund on a disputed charge.

How to turn it up

The starting notch is conservative by design. The word in the title is gradually, and gradually means the dial moves on evidence, one task at a time, never on elapsed time alone and never because the demo went well. Two things earn the next notch.

Proven reliability on that specific task. Not a general sense that the agent is good, but a track record on this task: an eval set built from your real cases, including the ones that went wrong, with a pass rate you agreed in advance, and then a run of production volume with no detected failure. Reliability on refunds tells you nothing about reliability on account closures. The evidence is per task because the dial is per task.

Detectability. Would monitoring catch a mistake before it does harm? A task where a wrong action trips an alarm within seconds can sit higher than an identically risky task where a mistake surfaces weeks later as a chargeback. Reliability is how rarely the agent is wrong. Detectability is how fast you find out when it is. You need both to climb, because a low error rate you cannot observe is just a wrong call you have not noticed yet.

This is not a novel idea; it is how regulated professions widen authority. The FAA’s own student-pilot solo rule ties expanded autonomy to demonstrated, instructor-certified proficiency, re-checked every ninety days, not granted once and forgotten. A student flies solo only after an authorized instructor certifies that they have “demonstrated satisfactory proficiency” in the specific maneuvers, and that endorsement lapses on a clock. Autonomy is earned against evidence, on a named task, and it is reviewed. Here is the same shape on one support task.

One task, small refunds, tracked over time: the notch, and the evidence that earned the move up

Point in time	Notch	The evidence that earned it
Launch	Draft for approval	An eval set of real refund cases, including disputed and partial charges, passes at the score agreed up front. A human commits every refund.
Week 3	Act then notify	Over a thousand refunds audited against the ledger and downstream records, with a material error rate under one percent and reviewer overrides tracked. Every refund is logged and an amount mismatch is flagged before it settles, so acting first and notifying after is safe.
Week 8	Act within limits, ceiling $50	Thousands of auto-refunds under fifty dollars stayed under the agreed error and escalation thresholds, and a monitor flags a mismatched amount within minutes, before the batch settles. Reliability and detectability, both shown.
Week 20	Act within limits, ceiling $200	Two near-misses caught by the amount-mismatch alarm before any payout, evidence the detection holds under load, with nothing slipping past it during the validation window. The ceiling rises from fifty to two hundred; above it, the task still drafts for approval.

Notice the ceiling never disappears. Turning the dial up is not a march toward full autonomy. It is finding the highest notch this task’s evidence supports, and stopping there.

Set it per task, not per agent

Now the payoff, and it is the whole argument in one table. The same support agent, one model, one deployment, runs at a different notch for every task it does, and each notch is the one its reversibility and blast radius earned back in the grid. The account-closure task, the one that caused the opening incident, sits at the bottom of the dial, exactly where “irreversible and high blast radius” said it should have started.

One support agent, five tasks, five different notches, each set by reversibility and blast radius

Task	Notch	Why (reversibility and blast radius)
Tag and route a ticket	Full autonomy	Fully reversible in a click, near-zero blast radius. Humans review a sample, not each case.
Reply to a how-to question	Act within limits	Low blast radius and softly reversible with a follow-up. Auto-send simple answers; escalate anything touching billing or the account.
Refund under $50 to the original card	Act within limits	Bounded money, but hard to pull back once sent, so a hard cap plus a pre-settlement mismatch alarm contain it, not reversibility. Auto-issue under the ceiling; above it, draft for approval.
Refund over $500	Draft for approval	Larger money and no clean way to pull a card refund back. The agent prepares it in full; a person commits it.
Close an account	Suggest only	Irreversible: it cancels the subscription and can wipe saved data. The agent can recommend it; a human does it.

Read that table against the opening. Nothing about the model needed to change to prevent the incident. The account-closure task simply needed to be at Suggest only while the reply task sat at Act within limits, which is impossible to express with a switch and trivial with a dial. This is also why the demos that pass so cleanly fail in production: a demo runs one task at one setting, and the setting it validates is almost always the wrong one for the task that eventually breaks.

The dial turns down too

A dial that only turns up is a switch with extra steps. The notch an agent holds is a claim about evidence that was true when you granted it, and evidence expires. Recall the FAA’s ninety-day clock: proficiency certified in the spring does not authorize a solo in the autumn. Earned autonomy can lapse, and a production dial needs the same discipline, because several ordinary events quietly invalidate the evidence a notch was standing on.

Triggers that lower the notch, what each one invalidates, and where the dial moves

Trigger	What it invalidates	Action
A production incident	The clean track record that earned the current notch.	Drop the affected task to Draft for approval until the fix is proven on the eval set again.
A material system change	A change to the model, prompt, tools, permissions, retrieval source, policy, or vendor config. The model-dependent evidence no longer holds, though deterministic integration and permission tests may.	Treat it as a new release. Drop the task to Draft for approval and re-run the relevant evals before restoring the notch.
Model drift or a quality regression	The reliability half of the evidence.	Lower the notch and re-run the evals. Restore it only when the pass rate comes back.
A new task type the evals do not cover	Detectability: the monitors were tuned for the old cases.	Route the new type at Suggest only until it has its own eval cases and its own alarms.
A regulatory or policy change	The blast-radius assumption behind the starting notch.	Re-place the task on the reversibility and blast-radius grid. A higher stake means a lower notch.

The model swap row is the one that catches good teams. A vendor ships a better model, the upgrade looks free, and every notch on the dial silently comes to rest on evidence about a model that is no longer running. Turning the dial down for a re-evaluation is not a loss of nerve. It is the same discipline that let you turn it up.

Set the dial low, then earn the next notch

Here is the whole thing as an operator would run it. Do not ask whether you trust the agent. Ask, for each task the agent does, how much authority the task warrants and how much the agent has earned. Then:

Start every task no higher than its reversibility and blast radius justify, and be especially conservative with anything you cannot undo. Turn the dial up one task at a time, only on proven reliability and proven detectability, never on elapsed time alone and never because a demo went well. Keep the ability to turn it down, and wire the triggers that force a re-check into the process so it happens without an argument. And set the dial per task, always, because the single biggest failure in the opening was not a bad model, it was one setting stretched across tasks that deserved five.

The dial and the notches are one part of a larger design question, which is how you build an agent so that each task’s authority is separable and adjustable in the first place. That is the subject of the book Designing Enterprise Agentic AI Systems. And the dial sits inside the wider launch decision: before an agent ships, the per-task notch is one line on the production readiness checklist that decides whether it goes live at all.

If it would help to have someone place your agent’s tasks on this dial with you, set the starting notches against reversibility and blast radius, and decide what evidence would justify moving each one, that is part of what the Agentic AI Readiness Review does. Details at how I can help.