Forty agent actions, approved in about four minutes. I was watching an operations lead work through the queue, tap, tap, tap, each one a button that said “Approve” next to a one-line summary and nothing else. She was not being careless, just human, in front of a queue that punished her for thinking. By the time the agent moved a payment to the wrong counterparty, the approval had already happened, logged, signed, with her name on it. The human-in-the-loop step worked exactly as built. The build was the problem.
Teams keep getting this wrong. They design an agent, suspect it might do something stupid, and reach for a human as the airbag. Put an approval gate in front of the risky action, ship it, and tell the auditors there is a human in the loop. The claim is technically true and operationally a fiction. You have not added judgment to the system, only recruited someone to absorb blame for decisions they were never given the means to make.
A gate is not a control
A human approval step adds safety only if the human can actually exercise judgment at the moment they are asked. That is a high bar, and most loops fail it before the human even shows up.
Think about what it takes for a person to make a real decision about an agent’s proposed action. They need to know what the agent is about to do, in specific terms, not a summary that launders the detail away. They need the before state, what it is acting on, so a diff means something. They need a sense of how sure the agent is and why. They need to know whether the action can be undone if it is wrong, and they need enough time, and few enough of these, that the question lands as a question and not as friction to clear.
Strip any one of those and what you have is a ceremony, not a control. The operations lead above had a summary and a button. She did not have the diff, the counterparty detail, the confidence, or the time. The system asked her to be accountable for a decision while withholding everything she needed to make it. What you have built there is not a safety net but a liability transfer with a nice UI.
The two loops
The contrast is sharp enough to draw.
The bad loop asks a human to ratify; the good loop asks a human to judge, and does the legwork first.
In the bad loop, the agent decides, renders a button, and waits. The human is downstream of a decision that has, in every meaningful sense, already been made. Their job is to not get in the way. Approval rate climbs toward a hundred percent, which everyone reads as “the agent is good” when it actually means “the gate is off.”
In the good loop, the machine does the unglamorous preparation that makes judgment possible. It assembles the context a reviewer would otherwise dig for, renders the diff, states its confidence and the basis for it, flags whether the step is reversible, and only then asks. The human is making a real decision now, not ratifying one already made, with the machine having cleared the desk in front of them. The decision, and what was on screen when it was made, gets logged as a unit. (If your audit trail records the click but not the context the human saw, you are recording theater, not accountability.)
The difference is not the presence of a human, since both loops have one. It comes down to whether the architecture put the human in a position to add anything.
Reversible and irreversible are different problems
The single highest-value design move I know is to stop treating every action as needing the same gate, because most do not need a gate at all.
If an action is cheap to undo, let the agent take it and make the reversal one click away. Drafting a message, tagging a record, proposing a categorization: act first, surface it, allow a fast correction. A human reviewing every reversible action is wasted judgment, and worse, it trains the reflex of approving without looking. Alert fatigue is not a discipline problem; it is what a well-functioning brain does when ninety-nine of a hundred alerts were safe to ignore. You manufacture it by gating things that did not need gating, and then it bleeds into the one decision that mattered.
Irreversible actions are the opposite. Moving money, deleting the source of truth, sending something to a regulator, anything you cannot take back. Those deserve a real stop, the full context, sometimes a second human, and an interface that deliberately refuses to be fast. I have built screens that would not let you confirm an irreversible action until the page had been open for a few seconds, because the slowness was the feature. If the reviewer wants to think and the UI lets them rush, the UI is fighting the control it claims to be.
Sort your actions on that axis first. Reversible ones get an action and a one-click undo. The irreversible ones earn a hard stop, the full context, and time the reviewer cannot skip. Almost every loop I have seen in trouble had it backward, gating the cheap stuff into a blur and waving the expensive stuff through on momentum.
Design the loop, then automate around it
One reframe changes how a team builds. The human-in-the-loop stops being the agent’s safety net and becomes a first-class part of the system, designed as deliberately as the retrieval layer or the tool schema. Where does human judgment have the highest marginal value, and how do you get the machine to do everything up to that point, so the person spends their attention only on the call that needs a person?
That is a UX question and an architecture question wearing a trench coat, pretending to be a compliance checkbox. The compliance team will accept the checkbox. Your operations lead, four minutes into a queue of forty, will not be protected by it. She will be exposed by it, and so will you, the first time the agent is confidently wrong and her name is on the approval.
A good loop is more work than a button. It means building the diff renderer, the context assembler, the confidence surface, the reversibility classifier, the audit record that captures what the human saw and not just what they clicked. None of that is the agent, yet all of it is the safety.
When someone tells me their agent is safe because there is a human in the loop, I ask what the human sees and how long they have to look at it. A summary and a button means there is no loop, only a person positioned to take the fall.
My money is on the teams that spend as much on the review surface as on the model behind it, and that is where my own effort goes now: the boring half of the work, the preparation and the context and the record of what was on the screen when someone clicked yes. I would rather build that than hand another operations lead four minutes, forty buttons, and her own name on the counterparty that got paid by mistake.