# Autonomy is a dial, not a switch. > Full autonomy is rarely the right target. Set the autonomy dial per action using reversibility, blast radius, and confidence, then earn each click upward. Canonical URL: https://techtideai.io/blog/human-in-the-loop-by-design Markdown URL: https://techtideai.io/blog/human-in-the-loop-by-design.md Publisher: TechTide AI, Columbus, Ohio (https://techtideai.io) Author: Alex Cinovoj, Founder & CTO, TechTide AI · CTO & Co-Founder, CPG Playbook Type: Field Note Published: 2026-04-08 Reading time: 8 min Topics: human in the loop, AI autonomy levels, approval workflow AI, agent guardrails Site index: https://techtideai.io/llms.txt Offer summary: https://techtideai.io/offers.md --- FIELD NOTE / 8 MIN READ ## Autonomy is a dial, not a switch. By [Alex Cinovoj](https://alexcinovoj.com/), Founder & CTO, [TechTide AI](https://techtideai.io/about) · CTO & Co-Founder, CPG Playbook Published April 8, 2026 Teams keep arguing about whether their agent should be autonomous, as if it is one setting for the whole system. It is the wrong unit of analysis. An agent that drafts a customer email is a different risk than an agent that sends one, which is a different risk than an agent that issues a refund. Set autonomy per action, not per agent, using reversibility, blast radius, and measured confidence as the inputs. Then earn each increase with evidence instead of granting it on a launch date. This article explains how to set those approval rules per action. ## Key takeaways - Autonomy should be set per action, not per agent, since a drafted email, a sent email, and a refund carry very different risks. - Reversibility, blast radius, and measured confidence from real production data are the three inputs that should set the autonomy dial. - Autonomy for a specific action should only increase once its human override rate stays below a set threshold over real production volume. - A good escalation handoff shows the human the plain-language request, the agent's findings, its proposed action, and its measured confidence. - Some actions, like legal disclosures or irreversible deletions, should stay gated by a human permanently rather than graduating to full autonomy. ## Why 'is the agent autonomous' is the wrong question 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. ## The three inputs that actually set the dial 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. Further reading - [When to hand an agent back to a human.](https://techtideai.io/blog/when-to-hand-an-agent-back-to-a-human) Also on human in the loop and agents · 8 min - [Who approves the AI's work? A practical operating guide](https://techtideai.io/blog/ai-approval-queue-operating-guide) Also on human in the loop and governance · 6 min ## A working procedure for setting the dial 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. ## What a good escalation payload looks like 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](https://techtideai.io/critical-system-implementation), where the reviewer queue is designed alongside the tool itself, not bolted on after launch. ## The 2026 take on this, and where it falls short 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. ## Common failure patterns to watch for 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](https://techtideai.io/critical-system-implementation). ## Where this fits in a broader production readiness plan 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](https://techtideai.io/what-is-ai-production-readiness) 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. ## Frequently asked - For a narrow set of low-stakes, easily reversible actions, yes. For anything with real blast radius, like sending money, deleting data, or contacting a customer, keep a human checkpoint until you have months of evidence the agent handles the edge cases correctly, not just the common case. About the author ## Alex Cinovoj AI & Infra Engineer. Building AI that survives outside the demo. Founder & CTO, TechTide AI · CTO & Co-Founder, CPG Playbook I spent 13 years in US enterprise IT, the last 2 focused entirely on AI implementation. I run [TechTide AI](https://techtideai.io/), an implementation studio that takes stalled AI pilots into production. I write about the work in progress at [alexcinovoj.com](https://alexcinovoj.com/) and on [Substack](https://alexcinovoj.substack.com/). Logs over vibes. Production over theater. [alexcinovoj.com →](https://alexcinovoj.com/)[More on the studio](https://techtideai.io/about) Related field notes - EXPLAINER · 4 min · Human in the loop, Governance ### [Reviewing AI output after launch: reduce review only with evidence](https://techtideai.io/blog/ai-output-review-sampling) How to move an AI workflow from full human review to sampling: written criteria, reviewer agreement, per-risk groups, staged reductions and reset triggers. - GUIDE · 6 min · Human in the loop, Governance ### [Consulting scope changes: turn client requests into approval decisions](https://techtideai.io/blog/consulting-scope-change-workflow) A proposed scope-change workflow that compares client requests with the current agreed scope and prepares the decision for the delivery owner to approve. [All field notes →](https://techtideai.io/blog) ## Have a stalled build that needs to work? [Send the project brief→](https://techtideai.io/contact)