Autonomy is a dial, not a switch.

Decide which individual actions need approval. Drafting a reply, sending it and issuing a refund carry different risks, so one autonomy setting for the whole agent hides decisions your team needs to make.

The fix is to stop asking the question at the agent level and start asking it at the action level. A support agent might have twelve distinct actions it can take: look up an order, draft a reply, send a reply, issue a refund under $50, issue a refund over $50, escalate to a human, close a ticket, and so on. Each of those has a different reversibility profile and a different blast radius if it goes wrong. Treating them identically throws away the information you need to make a good decision.

Three factors determine where an action's autonomy dial should sit. None of them is "how good is the model."

• Reversibility. Can this action be undone cheaply if it turns out to be wrong? Drafting an email is fully reversible, nothing happened yet. Sending it is not. Issuing a refund is reversible in theory but costs a support ticket and a customer's trust to unwind.
• Blast radius. If this action is wrong, how many people or systems does it affect, and how expensive is the wrong outcome? A refund of $20 has a small blast radius. A bulk email to your entire customer list has a large one, even if each individual send is low stakes.
• Measured confidence. Not the model's self-reported confidence score, which is unreliable, but your own measured accuracy on this specific action type from real production data or a solid eval set. An action the agent gets right 99.5 percent of the time on real traffic is a different decision than one it gets right 85 percent of the time.

Score each action on these three dimensions and you get a natural autonomy tier, not an opinion. Low blast radius, high reversibility, high measured confidence: let it run unattended. Anything with high blast radius or low reversibility: gate it, no matter how confident the model claims to be.

1. List every distinct action the agent can take, not every intent it can recognize. "Refund" is not one action if refunds under $50 and over $50 have different approval requirements in your business already.
2. Score each action on reversibility and blast radius using a simple low/medium/high scale, agreed with whoever owns the business risk, not just engineering.
3. Set the starting autonomy tier conservatively for every action, regardless of how well the model performs in testing. Testing is not production traffic.
4. Route gated actions to a human with full context: what the agent found, what it plans to do, why, and its measured confidence for that action type based on real data so far.
5. Track the human override rate per action for at least two to four weeks of real volume, not a demo period.
6. Raise autonomy for a specific action only when the override rate stays below your threshold, commonly 5 percent, over a large enough sample to trust the number, typically several hundred instances.
7. Re-check periodically. Model updates, prompt changes, and shifting user behavior can all silently degrade an action that used to earn its autonomy. Autonomy earned is not autonomy permanent.

The quality of a human-in-the-loop system is decided almost entirely by what the human sees when the agent hands off. A bad handoff just says something went wrong and forces the human to reconstruct the agent's entire investigation from scratch, which is slower than if the human had done the task themselves. A good handoff includes:

• The original request in plain language, not a raw JSON payload.
• Every tool call the agent made and what it found, summarized, not as a raw trace dump.
• The specific action the agent is proposing and why, in one or two sentences.
• The agent's measured confidence for this action type, based on historical accuracy, not a self-reported number.
• One-click approve, reject, or edit-and-approve, so the human's decision takes seconds, not minutes.

Teams that get this right turn human review into a fast rubber stamp for the 90 percent of cases the agent gets obviously right, with real attention reserved for the genuinely ambiguous cases. Teams that get it wrong turn every review into a full re-investigation, which is slower than not having an agent at all. This is a core piece of what we build inside scoped MCP tool development, where the reviewer queue is designed alongside the tool itself, not bolted on after launch.

The popular framing this year, pushed by a lot of agent tooling vendors, is a maturity ladder: start with human in the loop, graduate to human on the loop, graduate to full autonomy, as if autonomy is a destination every agent should eventually reach for every action. That framing sells more of the vendor's autonomy tooling, but it is wrong for a meaningful share of production actions.

Some actions should never graduate past a human checkpoint, not because the model is unreliable but because the cost of a rare wrong outcome is asymmetric. A refund policy exception, a legal disclosure, an irreversible data deletion: these are not maturity problems waiting to be solved with more evals. They are decisions where an organization has decided a human should be accountable, independent of model accuracy. Confusing "we have not yet earned full autonomy" with "this action should never be fully autonomous" leads teams to keep pushing for a graduation that was never the right goal for that specific action.

The dial framing handles this correctly, because it treats "gated forever, on purpose" as a valid, permanent setting for some actions, not a temporary state on the way to full autonomy for everything.

Three patterns show up repeatedly in agents that get autonomy wrong:

• Autonomy creep without new evidence. A team raises the dial because the deadline arrived, not because the override rate data supports it. This is the single most common cause of an autonomous agent doing something publicly embarrassing.
• Confidence theater. Relying on the model's self-reported confidence score instead of your own measured accuracy from real outcomes. Self-reported confidence correlates weakly with actual correctness and should never gate an autonomy decision on its own.
• One dial for the whole agent. Treating the agent as a single autonomy unit forces every action to inherit the risk profile of the riskiest one, which either blocks useful automation or exposes you to unnecessary risk, depending on which way the team compromised.

Watching for these three during a build review catches most of the incidents before they happen, and it is a standard part of the review checklist in our Claude and Anthropic implementation work.

Autonomy design is not a standalone feature, it is one axis of the broader question of whether an AI system is ready for production. It sits alongside eval coverage, cost ceilings, and observability as one of the checks that separates a demo from something you can trust with real customers and real money. See our production readiness framework for how the autonomy dial fits alongside the other checks we run before recommending a go-live.

The mechanical work of building a good approval queue is genuinely simple: a table, a UI, and a webhook. Deciding which actions need review requires checking their consequences and the capacity of the review team. The dial framework in this piece is the tool we use to make that judgment call explicit instead of implicit.