When Agents Should Ask a Human
Approve everything and the agent crawls. Approve nothing and, sooner or later, it does something you cannot take back. Most teams pick one of those two settings and call it a policy.
We think that framing is wrong. The question is not how much autonomy an agent gets in general. It's which specific actions earn a pause, and what a person can realistically decide in the seconds you are asking for. Get those two things right and approval stops being a tax on every run. Get them wrong and you get the worst outcome of all: a reviewer who clicks yes out of habit, standing between the agent and the damage, providing the appearance of oversight and none of the substance.
That habit forms fast. Anthropic's study of agent autonomy in practice found that, in Claude Code, the share of sessions using full auto-approve rises from roughly 20% for new users to over 40% by 750 sessions, while experienced users also interrupt more often. Read that carefully. Experienced people do not stop supervising. They stop approving step by step, because step-by-step approval stops carrying information, and they switch to watching and intervening when something looks off. A deployment that forces the first style onto people who have learned the second one will be routed around or rubber-stamped. Probably both.
Judge each call by what it can do
A pause should be triggered by properties of the action, not by the tool's name alone. Three properties do most of the work.
Can it be undone? Reading, drafting, searching, and summarizing can almost always be discarded. Sending, paying, deleting, publishing, and changing a record of truth cannot. Or they can only be undone with a phone call and an apology. Irreversible actions are the first candidates for a gate.
Who else does it reach? An action inside the run affects the run. An action that leaves the system (a message to a customer, a filing, a payment) affects people who never agreed to be part of an experiment and cannot see the reasoning that led there. Reach raises the bar.
How wrong could the inputs be? An agent acting on a document it just retrieved, naming an account it has never paid before, is in a different position from one repeating a well-formed action it has completed correctly a hundred times. Novelty and low confidence in the inputs should lower the threshold for asking, even for actions that are usually safe.
Modern frameworks already express this as a per-call decision rather than a global setting. In the OpenAI Agents SDK, a tool declares that it needs approval always, or through a function that inspects the actual arguments of this call, and the run pauses with the pending call surfaced for a decision. That second form is the important one. "Approve all sends" is a blunt rule. "Approve a send when the recipient is outside the account's known contacts, or the amount in the body differs from the amount in the source record" is a policy a reviewer can stand behind, because it only fires when something specific is unusual.
The reviewer needs a packet, not a prompt
"Approve this action? Yes / No" is not a review interface. It is a coin flip with extra steps. A person can only decide well if the pause hands them, in one place, what the agent is about to do in plain terms, the inputs it is acting on, why this call was gated, and what happens on each answer.
That is also where the decision types matter. A binary yes/no forces a reviewer who spots a small error to either approve a flawed action or reject the whole run and start again. LangChain's human-in-the-loop middleware, built on LangGraph, gives the reviewer four moves: approve the call as proposed, edit its arguments before it runs, reject it with feedback the agent reads, or respond directly where the human's reply is itself the answer. Edit is the underrated one. Most near-miss actions do not need stopping. They need one field corrected: the recipient, the date, the amount. Then they should run, with the correction on record.
The pause has to survive real life, too. People answer in minutes or hours, not milliseconds, and sometimes from a different process or device than the one that started the run. Both frameworks treat the paused run as saved state that can be stored and resumed after the decision, rather than a process left hanging. Design for that from the start: the state the reviewer sees must be the state that runs if they approve it, unchanged in between. If the underlying record can change while a call waits, re-check it at resume time and send it back for review when it no longer matches what was approved. An approval for one version of an action must never execute a different version.
A worked example: the payment that should wait
Here is the gate doing its job on one ordinary case.
Nothing here required the reviewer to supervise the agent's whole run. The retrievals, the invoice matching, the drafting — all of that ran unimpeded. The one action that was irreversible, externally visible, and based on a freshly changed input is the one that waited. And the rejection did useful work: it came back with an instruction the agent could act on, so the task moved forward instead of dying at the gate.
Where asking stops working
There are limits, and pretending otherwise is how approval queues become theatre.
Volume kills review first. If a deployment generates fifty pauses a day for one person, that person will build a habit, and the habit will be yes. When the queue grows, the answer is rarely more reviewers. It is a better policy: look at what gets approved 100% of the time, unchanged, for weeks, and ask whether the gate is catching risk or just recording it. Some of those actions should graduate to running unimpeded, with the trace kept for audit. Graduation should be deliberate, evidence-based, and reversible. And it should never be applied to the irreversible, external actions at the top of the risk list.
Some questions should never reach a reviewer as an approval at all. If the honest answer is that no person can judge the action from the packet — the evidence is too long, the domain call too specialised, the consequence too unclear — then the action does not need a gate. It needs to not be automated yet. A pause that nobody can evaluate is not a safety mechanism. It just moves the signature.
Finally, timeouts are decisions. A paused call that nobody answers cannot default to running. It expires, the agent reports that the action did not happen, and the task either ends or finds a route that does not need the gated step. No answer has to mean no action. Building the opposite assumption into the resume path is a small design choice with very large consequences.
The goal was never a human in every loop. It is a human at the few points where judgment changes the outcome: seeing a clear packet, able to correct rather than just consent, with everything else free to run. Build the gate that narrow, and people will still be paying attention on the day it really matters.
Work with us
If your agents either stall on approvals nobody reads or run actions nobody should have let through, the gate is in the wrong place. Bring us that deployment through Trida AI's intake.