When automation should ask for approval instead of acting alone

The Dangerous Part Is Not The Script

Most automation problems do not start with a clever system doing something obviously wild. They start with a system doing exactly what it was built to do, in a situation where the consequences changed.

A script archives a thread because it matched the usual pattern. An agent posts a generated update because the checklist says the draft is complete. A deployment bot promotes a build because tests passed. A workflow sends a message because a template was filled. Each individual step looks reasonable. The problem is that reasonableness is local, while impact is global.

This is the part of automation I think about more now than I did a few years ago. Early in my career, I mostly measured automation by how much manual work it removed. If a process had ten repetitive steps and I could reduce them to one command, that felt like progress. It often was progress. But the more I worked with production systems, business workflows, and AI agents, the more I noticed a second question hiding behind the first one.

Should this system be allowed to finish the job by itself?

That question is not anti-automation. It is what makes automation usable in serious environments. A system that asks for approval at the right moment can be trusted with more work than a system that acts confidently until someone has to clean up after it.

Autonomy Is A Product Decision

Engineers often treat approval as a technical detail. We add a confirmation dialog, a dry-run flag, a review step, or a permission check. Those details matter, but the real decision is product-level: what kind of responsibility are we giving the system?

If an automation only rearranges local files in a temporary folder, it can probably act alone. If it sends a public message, changes customer-facing state, spends money, deletes data, modifies permissions, or commits the user to a position, the standard should be different. At that point, the automation is no longer just saving time. It is representing intent.

That distinction becomes sharper with AI agents. A traditional script usually follows a narrow path. An agent can interpret instructions, use tools, summarize context, make assumptions, and choose between actions. That flexibility is useful, but it also means the agent can be wrong in more interesting ways. It may understand the general goal and still misunderstand the boundary.

When I design agent workflows now, I try to separate execution from authorization. The agent can gather context, draft the change, run checks, explain tradeoffs, and prepare the exact command. But whether it should cross a boundary depends on the cost of being wrong, not on how confident the model sounds.

The Approval Boundary

I use a simple mental model: an approval boundary is any point where the system's action becomes hard to undo, externally visible, financially meaningful, legally sensitive, or reputationally risky.

Hard to undo does not always mean impossible. A bad commit can be reverted. A wrong deployment can be rolled back. An email can be followed by a correction. But reversibility has a cost. It consumes time, attention, credibility, and sometimes trust. If the rollback is technically easy but socially awkward, that still counts.

Externally visible actions deserve special care because they leave the private workspace. Publishing a post, sending a customer email, replying in a group chat, updating a status page, or posting on social media changes how other people experience the system. Even when the content is generated correctly, timing and tone can be wrong. Automation does not understand embarrassment unless we encode the possibility of it into the workflow.

Financial actions are obvious: payments, refunds, purchases, bids, subscriptions, ad budgets, invoices. Legal and compliance-sensitive actions are obvious too: contracts, personal data, access changes, regulated claims. But the everyday boundary I see teams underestimate is permission. Changing who can access something is a small technical action with a large blast radius.

The approval boundary is where I want the system to stop and say: here is what I am about to do, here is why, here is the evidence, and here is the exact effect.

Not Every Confirmation Is Useful

There is a bad version of approval that just trains people to click yes.

If every harmless action asks for confirmation, the confirmation becomes noise. The user stops reading. The approval step protects the designer of the system more than the person using it. This is the same problem as modal dialogs that ask "Are you sure?" without explaining what will happen. They add friction without adding judgment.

A useful approval request should improve the decision. It should surface the information a human needs at that moment: the target, the scope, the diff, the recipients, the cost, the irreversible part, the confidence level, and the fallback. If the approval screen does not change what the human knows, it is probably just ceremony.

This matters for AI agents because they can generate extremely polite requests for approval that still hide the important part. "I am ready to proceed" is not enough. Proceed with what? Which files? Which branch? Which message? Which environment? Which audience? Which data source? If the user has to ask those questions, the system did not prepare the approval properly.

Good approval is specific. It should feel closer to reviewing a pull request than clicking a vague browser alert.

I Classify Actions By Blast Radius

One practical way to decide whether automation should ask is to classify actions by blast radius.

Low blast radius actions are private, local, reversible, and easy to inspect. Formatting a file, sorting imports, generating a draft, refreshing a cache, extracting logs, or creating a local report usually belongs here. These are good candidates for autonomous execution. Asking every time would slow the workflow without reducing much risk.

Medium blast radius actions affect shared work but remain easy to review and revert. Creating a branch, opening a pull request, updating a draft document, preparing a migration file, or changing a non-production configuration can often be automated, especially if the output is reviewed before merge or release. The approval may happen later in the existing workflow.

High blast radius actions affect production, money, access, customers, public channels, or data durability. These should usually require explicit approval unless the system has a very strong, narrow contract and a tested rollback path. Even then, approval may be replaced by policy rather than removed entirely. For example, a deployment pipeline may auto-promote low-risk services during business hours but require manual approval for database migrations or major permission changes.

This classification is not perfect, but it stops the discussion from being philosophical. Instead of asking whether the automation is smart enough, I ask what happens if it is wrong.

The Agent Should Earn Autonomy

I do not think agent systems should start with maximum freedom. They should earn autonomy through repeated, observable correctness.

At first, I want the agent to work in draft mode. It can inspect the repo, propose edits, generate the content, run tests, and produce a diff. A human approves the final action. Over time, if the same workflow is reliable, the approval boundary can move. Maybe the agent can commit changes but not push. Later it can push to a feature branch but not deploy. Later it can deploy low-risk changes when tests pass and no protected files changed.

This is how trust works in human teams too. A new engineer does not get production access on day one just because they can explain the architecture. They earn broader permissions by showing judgment, asking good questions, and making mistakes that are small enough to learn from.

Agents should be treated the same way. Give them a sandbox first. Watch the traces. Measure the quality of their assumptions. Improve the tooling. Then expand the scope where the evidence supports it.

Approval Is Also A Debugging Tool

An approval step is not only a safety brake. It is a debugging interface.

When an agent stops before a significant action, it has to explain its state. That explanation can reveal misunderstandings before they become side effects. Maybe it selected the wrong repository. Maybe it misunderstood "publish" as "deploy." Maybe it used an old topic from memory instead of the current queue. Maybe it found a failing test but decided it was unrelated. Maybe the final URL is based on a route that does not exist.

A well-designed approval request exposes those assumptions. It forces the system to make the hidden plan visible. The human can then correct the plan while the work is still cheap to change.

This is especially useful in long-running workflows where the agent has many chances to drift. The final approval acts like a checksum: does the intended action still match the original request and the current state?

When I Let Automation Act Alone

There are plenty of cases where asking for approval is the wrong default.

If the action is fully internal, cheap to reverse, and covered by a clear contract, I want automation to move. Running tests, generating static output, formatting code, collecting metrics, checking a calendar, summarizing logs, resizing an image, or updating an internal checklist should not require a human tap every time. The whole point is to remove boring coordination overhead.

I also let automation act alone when the user's instruction already includes the authorization and the workflow is narrow. If a scheduled publishing job explicitly says to build, commit, and push a specific blog post, then the approval happened at the workflow level. The agent should still verify what it did, but it does not need to ask again unless something unexpected happens.

The important phrase is "unless something unexpected happens." Autonomy should be conditional. If the build fails, the target branch is not what the workflow expected, the diff includes unrelated files, the image download is not an image, or the remote rejects the push, the agent should stop and report the issue instead of improvising through a risky path.

Good automation is not timid. It is bounded.

When I Want A Human In The Loop

I want approval when the system is about to cross a boundary that changes external reality.

Sending messages is the clearest example. A draft can be automated. Research can be automated. Tone cleanup can be automated. But sending a message on behalf of a person is different. The system is no longer producing content; it is speaking in a social context. Even a technically correct message can be wrong because of timing, relationship, or implied commitment.

I also want approval for destructive operations. Deleting a branch may be fine. Deleting production data is not the same kind of verb. Removing old files can be safe if they are generated artifacts. Removing user-owned files should require more care. In my own workflows, I prefer recoverable deletion when possible because "undo" is a design feature, not a moral victory after a mistake.

Access control is another category where I slow down. Adding a user, removing a user, changing group permissions, exposing a private site, or rotating credentials all deserve explicit evidence. The system should show who will gain or lose access, which resource is affected, and whether the owner remains allowed.

Finally, I want approval when the agent is uncertain in a way that matters. Uncertainty itself is not a failure. Hiding it is. If the agent cannot verify the source, cannot reconcile conflicting instructions, or cannot prove that the generated artifact includes the intended route, it should stop before the risky action.

The Best Approval Requests Are Boring

The best approval requests I have seen are not dramatic. They are structured and boring.

They say what will happen. They show the diff or the payload. They name the target environment. They list the files or records affected. They include test results. They call out assumptions. They make the next action explicit: approve, reject, edit, or ask for more information.

For an AI coding agent, a good approval request before a push might look like this: changed three files, generated route X, build passed, untracked unrelated files remain untouched, commit message will be Y, remote is origin master. That is enough for a human to make a real decision.

For an email agent, it might show recipients, subject, full body, attachments, source context, and whether the message is being sent as the user or as the agent. For a finance workflow, it might show amount, currency, recipient, account, invoice reference, and whether the action is reversible.

The structure matters because it turns approval from a feeling into a review.

Policy Beats Prompting

It is tempting to solve approval with one more prompt instruction: "Ask before doing risky things."

That helps, but it is not enough. The model still has to decide what "risky" means. It may classify the action correctly most of the time, then fail exactly when the context is weird. If the boundary matters, I prefer to encode it in the tool or workflow.

A sending tool can require explicit approval metadata. A deployment tool can reject production deploys without a passed build. A file tool can refuse destructive operations outside a workspace. A publishing workflow can compare the final diff with the expected files. A payment workflow can enforce limits and require approval above a threshold.

Prompts are good at shaping behavior. Policies are better at enforcing boundaries. The strongest systems use both: the prompt teaches the agent how to reason about approval, and the tooling makes dangerous shortcuts unavailable.

The Goal Is Confident Delegation

The goal is not to make automation ask for permission forever.

The goal is confident delegation. I want systems that can handle boring work without supervision, prepare complex work for review, and stop before actions that require human intent. That is a more useful target than full autonomy as a slogan.

When automation asks at the right moment, the user does not feel interrupted. They feel protected. When it acts alone in the right places, the user does not feel replaced. They feel freed from mechanical work. The difficult engineering is finding that boundary and making it visible.

In practice, I keep coming back to the same question: if this action is wrong, who pays the cost?

If the answer is "almost nobody," let the automation move. If the answer is "a customer, a colleague, the business, the user's reputation, or future trust in the system," ask first.

Reliable automation is not the automation that never pauses. It is the automation that knows which actions require intent, not just execution.