The approve-every-step problem
You build an automation that uses AI to do something useful — draft invoices, move files between systems, respond to support tickets. You want it to just work. You do not want to press Y twelve times a day.
You also do not want it deleting your customer list because a confused prompt talked it into doing so.
The naive options are both bad. Approve every action and you create approval fatigue — Anthropic reports that users approve 93% of their permission prompts anyway, so the prompts stop protecting you and become pure friction. Skip all approvals and you get the customer-list scenario.
The right answer is somewhere in between: let the AI act freely within clearly bounded operations, and gate the ambiguous ones.
The pattern Anthropic landed on
Their new "auto mode" for Claude Code, the coding assistant, maps to an architecture that carries over cleanly to business automation. Three tiers.
The first tier is always-safe actions. Reading files, looking things up, navigating the system. No state change, no damage possible. No approval needed, ever.
The second tier is routine changes inside a bounded scope. In Claude Code's case, that is file edits inside the current project — reviewable later via version control. In a business context it might be drafting a reply (not sending it), creating a draft invoice (not finalising it), or adding a record to a staging queue (not the live ledger).
The third tier is everything else. Shell commands, external API calls, actions outside the bounded scope. These go through a check. In Anthropic's implementation the check is a second AI that reads just the command and asks "is this reasonable?" — it cannot see the first AI's prose, which keeps the first AI from talking the checker into agreeing.
The specific mechanism is less important than the shape. Safe operations run by default. Risky ones get a structured review. The pattern applies to any AI automation you build, even if you are not running Claude Code.
What the tiers look like for a business automation
Tier one is always-safe. The AI reads, looks up, matches, pulls information from your systems. Nothing it does here changes state; nothing can cause damage.
Tier two is bounded. The AI produces work inside a reversible scope — draft documents, entries on a staging table, notes on records. All inside your own systems, all visible through the normal audit trail, all catchable before they reach anywhere that matters.
Tier three is gated. Anything that moves money, goes to an external party, or otherwise affects customers requires a human. Because all the drafting and matching is already done by the time you look at it, the human check is a quick confirmation rather than a full reconstruction of what the AI did.
The specific rails depend on your business. What "reversible scope" means in a law firm is different from what it means for a warehouse, and the tiers should be drawn around your actual systems and the actual risks in your operation.
You approve only the small number of actions that actually matter. The rest runs without you.
The trap: tier-two scope creep
The classic failure mode is starting with "we will approve everything that touches the outside world" and then gradually moving things into the always-safe bucket because the approvals feel tedious. A month later the AI is sending emails without oversight and nobody decided that.
The discipline is that tier membership is a deliberate choice, not a convenience default. Put the tiers in writing. Review which actions sit where every few months. Move something down only when you have evidence it is safe — weeks of clean runs, not one week.
Anthropic's own article is honest about this. Even their classifier has a 17% false-negative rate on overeager actions, which means roughly one in six cases where the AI does something it should not, the classifier misses. Their conclusion is that the system substantially improves on permissionless operation but does not replace careful review for high-stakes work. That is the right posture for your business too.
Where we land
The way we approach any AI automation is to start with one question: which actions need a human? Not "what does the AI do?" — that is the fun part and you design it second. The rails come first.
Sometimes the answer is that every action needs a human, and the AI becomes a drafting assistant. That is still a useful outcome — the drafting work is off your plate even if the decisions are not. Sometimes, once you look at the actual list, the set of actions that genuinely must be approved is short, and most of the automation runs itself.
Either way, you know what you signed up for. The AI is bounded, and you drew the boundary.
If you have an automation idea but you are nervous about AI running wild in your systems, that nervousness is the right instinct. The right move is to design the rails before you design the AI. Happy to talk it through.
—Further reading
- →Anthropic Engineering — Claude Code auto mode: a safer way to skip permissions. Source for the tiered permission design, the 93% approval-fatigue statistic, the two-layer classifier architecture, and the honest 17% false-negative number.