/

Human in the Loop Is a Design Decision

Product

9 min read

Human in the Loop Is a Design Decision

Human in the Loop Is a Design Decision

Human in the Loop Is a Design Decision

Where to put the person, and why the default answer is usually wrong.

Where to put the person, and why the default answer is usually wrong.

Human in the loop is treated as a safety setting, something you turn up when the stakes rise. It is better understood as a design decision about where judgement belongs.

Framed as a dial, the conversation is about how much to trust the model. Framed as a design decision, it becomes a much more useful question: which specific judgements should a person make, and what do they need in front of them to make those judgements well.

The three places a person can sit

There are really only three positions, and they have different costs.

Before the action, as an approver. The agent proposes, a person accepts or rejects, and nothing happens until they do. This is the safest and the slowest, and it only works if the volume is low enough that approvals actually get read.

After the action, as a reviewer. The agent acts, the action is logged, and a person audits a sample or reviews exceptions. Faster, and appropriate when actions are reversible and volume is high.

Outside the loop, as an escalation target. The agent acts autonomously and only involves a person when it cannot proceed confidently. This is where most mature deployments end up, and it is only safe when the agent is genuinely good at recognising its own uncertainty.

  • Approver: low volume, high consequence, reversibility poor.

  • Reviewer: high volume, moderate consequence, reversibility good.

  • Escalation target: high volume, low consequence, confident abstention.

Why the default is usually wrong

The default instinct is to put a person before every action, because it feels responsible. In practice it produces the least safe outcome of the three.

An approver facing forty low stakes decisions a day stops reading them. The approval becomes a keystroke. When the consequential one arrives, it receives the same keystroke as the thirty nine before it, and the organisation now has a control that exists on paper and nowhere else.

Worse, the friction usually kills adoption before that point. People route around the agent, and the project quietly ends without anyone deciding to end it.

What a person needs to judge well

Wherever the person sits, the same information determines whether their judgement is worth anything.

They need the proposed change and the current value side by side, not a description of the change. They need the source that triggered it, so they can assess the read rather than just the write. They need the agent's stated reasoning, including when it is thin. And they need a way to correct rather than only to reject, because rejection throws away the ninety percent that was right.

  • Show before and after, not a sentence describing the difference.

  • Link to the source input in one click.

  • Surface confidence honestly, including low confidence.

  • Allow edit and approve, not just approve or reject.

Corrections are the most valuable output

The under used property of a human in the loop is that corrections are data.

Every time a person changes a proposed value before accepting it, they have labelled a training example for free and told you exactly where the agent is systematically wrong. Most systems throw this away, recording only that the action was approved.

Capturing corrections separately from approvals turns the review step from pure cost into the mechanism by which the system improves. It is the difference between oversight and a feedback loop.

Moving the person over time

The position should not be fixed. A sensible deployment starts with approval on everything, watches the correction rate, and moves actions out of the approval lane as they earn it.

That migration should be per action, not global. An agent can be fully autonomous on logging activity and still require approval on merges for as long as merges exist. Treating autonomy as a single setting for the whole agent is what forces teams into an all or nothing choice they do not need to make.

The short version

Decide which judgements need a person, then place them where their attention is not wasted.

Approving everything is not caution. It is a way of having no control at all while appearing to have one, and it costs you the corrections that would have made the system better.