Human-in-the-Loop Agent Design: Where to Put the Person

Human-in-the-loop agent design means deciding, for each action an agent can take, whether a person approves it beforehand, reviews it afterward, is merely notified, or never sees it at all. The choice is driven by how far a mistake travels and how expensive it is to undo, not by how capable the model is. The common mistake is treating it as one setting for the whole agent instead of a decision you make per action.

Everyone agrees you need a human in the loop. Almost nobody says where. That vagueness is why agent rollouts tend to land in one of two failure modes: a person rubber-stamping every step until they stop actually reading, or an agent running unattended on actions nobody would have approved if asked.

The timing makes this practical rather than theoretical. Gartner projected in August 2025 that 40 percent of enterprise applications would feature task-specific AI agents by the end of 2026, up from less than 5 percent in 2025. That is a projection, not a measurement, but the direction is visible in the field. July 2026 technology-radar coverage describes the same pattern from the other side: agents are entering production faster than governance is keeping up.

Where can a person actually sit in an agent workflow?

There are four positions, and most systems need more than one.

The fourth one is the least used and the most valuable, which we will come back to.

Notice that none of these is "monitored." Watching a dashboard is not a position in the loop. It is a thing people say they will do and then do for about two weeks.

How do you choose which one an action gets?

Two questions, asked per action rather than per agent.

How far does a mistake travel? An agent writing a draft to a file affects one file. An agent publishing to a live site affects everyone who visits it, plus search engines, plus anyone who screenshots it before you notice. Same agent, same underlying model, wildly different blast radius.

How expensive is it to reverse? Deleting a row you have a backup of is cheap. An email to a customer list is not reversible at all. Reversibility, not importance, is what should drive the gate.

Those two questions sort most actions quickly:

• Public, irreversible, or money-moving gets approve-before. No exceptions worth making.
• Internal and reversible gets review-after. The record matters more than the gate.
• High-volume and low-stakes gets notify-only, or the reviewer will stop reading everything, including the things that mattered.

We run this split across our own systems every day. Content that publishes to a live brand site sits behind a hard quality gate that will refuse to ship rather than ship something wrong. Drafts written to local disk do not need that treatment, because a bad draft costs a delete. Those are the same pipeline and the same models, separated only by where the output lands.

Why does review everything fail first?

Because attention is the scarce resource, and blanket review spends it evenly on things that do not deserve it.

Approval fatigue is not a character flaw. A person who approves 200 items a day is not reviewing 200 items, they are clicking 200 times. By item 40 they have learned that approving is nearly always correct, and they are right, which is exactly the problem. The base rate teaches them not to look.

A gate nobody reads is worse than no gate at all, because it manufactures confidence. Now the organization believes every action was reviewed by a person. The audit trail says so. The reality is that a human hand moved a mouse.

The fix is not more discipline. It is fewer gates, placed where reversal is genuinely hard, so that the ones remaining still feel like decisions.

What does an agent need to stop safely?

This is the part we got wrong first, and fixing it changed more than any other single design decision.

Permission to do nothing. An agent that must produce output will produce a confident guess. If the only successful outcome available is a finished artifact, then when the inputs are bad or the sources are missing or the task is ambiguous, the model will fill the gap. It has no other move. Making "produced nothing, here is why" a legitimate success state removes the pressure that generates the worst failures.

That single change did more for output quality than any amount of added review, because the failures we most needed to catch were the ones a reviewer was least likely to catch: confident, well-formed, plausible, and wrong.

A concrete escalation path, and something specific to say. "I am not sure" is not an escalation. "I could not verify the second source for this claim, so I stopped before publishing" is. The stop has to arrive with enough context that a person can act on it in under a minute, or it becomes another notification nobody opens.

A written record of why it stopped. One stop is noise. Fifteen stops for the same reason is a design finding. You only see that pattern if the reasons are logged somewhere durable, and it is usually the highest-value data an agent system produces.

How do you know the loop is working?

Three signals, and only one of them is about output.

Track what the agent declined to do. Most teams measure what shipped. The refusals tell you more, because they show where the boundary is actually landing versus where you drew it.

Watch the human override rate. Zero overrides is not a passing grade. It almost always means nobody is reading, or the gate is on the wrong action. A healthy gate gets used occasionally. A gate that has never once changed an outcome is decoration.

Sample the unattended actions on a schedule. Whatever runs without review should still get looked at periodically, on a cadence, even when nothing appears wrong. Especially when nothing appears wrong. That is how you find out the notify-only bucket quietly grew to include something that should have been gated.

Where does this fit alongside evals and guardrails?

These three get blurred together constantly, and they solve different problems.

Evals tell you whether the thing works before it ships. They are pre-deployment, they run on a fixed set of cases, and they catch regressions.

Guardrails constrain what the agent is able to touch at all. They are structural. An agent with no credentials for your payment processor cannot make a payment mistake, regardless of what it decides.

Human-in-the-loop is about who is accountable at the moment an action happens. It is not a testing strategy and it is not a permission model.

You need all three, and none of them substitutes for another. An agent with excellent evals and no human position on irreversible actions is still one bad edge case from a public mistake. An agent with a person approving everything and no evals is a person manually catching regressions that a test suite should have caught for free. Designing how those layers fit together is most of the work, and it is the core of the agent orchestration methodology we build every system on.

The takeaway

Stop asking whether your agent has a human in the loop. Ask which actions have which position, and whether the person in each of those positions is actually reading.

Then go one step further and ask what your agent is allowed to do when it is not sure. If the answer is "produce something anyway," you have built a system whose failure mode is a confident guess, and no amount of review at the end will reliably catch that. The agent has to be able to stop.

Get those two right and the rest of it is tuning. Get them wrong and you will find out from a customer.

If you are putting an agent in front of something that matters, that is the conversation worth having before the build starts, not after. Tell us about it and we can work through where the person should sit.