Put a Human in the Loop

The human needs a decision, not a progress bar

Module 6 showed that a failed route may require adaptation or a return to the human. Module 7 showed that some next steps have external consequences. Module 8 puts those together:

When should the agent stop and give the human a decision?

“Human in the loop” becomes vague very quickly. A person merely watching an agent work is not necessarily controlling anything — watching is not deciding, and a progress display is not a control.

A useful human checkpoint occurs when:

1. the agent has reached a decision point;
2. the proposed next action is made visible;
3. the human can allow, change, or reject it; and
4. the action has not happened yet.

A checkpoint matters because the decision still belongs to the human.

Human involvement matters most when the human still has something meaningful to decide.

Three more words to learn

These are the course’s practical teaching terms. Products use different labels and implement them differently: Stanford writes about confirmation and human-in-the-loop controls, OpenAI about human intervention, Anthropic about configurable permissions. Those are not three names for one standard thing, and the Sources section keeps them apart. One housekeeping note as well: every module in this course ends with a section called Checkpoint, meaning a self-check before moving on. The glossary term above is a different thing — a pause in the agent’s run.

Where a checkpoint fits

Back to the briefing. The research is complete and the agent has prepared the one-page briefing. The available action is send_briefing, described as send the current briefing to a selected recipient, and the proposed input is recipient = "faculty-member@example.invalid".

Look at what is true at this exact moment. The content exists. The target exists. A consequential tool exists. And the side effect has not occurred.

That gap is the whole opportunity. It closes the instant the tool runs.

The agent can choose a tool without getting the final say

The agent may decide that send_briefing is a useful next action. That decision does not require the environment to execute the action immediately.

The system can instead surface what is being proposed, and ask.

Choosing the next action and authorizing its consequence can belong to different actors.

Everything this course has said about model-directed routes stays true. The model still chose. It simply does not also get to decide that its choice happens.

A proposed action, made visible

These are teaching choices, not claims about any particular product’s buttons. Nothing above is a screenshot, a real interface, or an executable action.

Approve what, exactly?

An approval is only as useful as what it shows. For this fictional action, a human deciding well would want to know which capability will run, the important input, the target or destination, the expected side effect, and whether the approval applies only to this action or more broadly. “Allow” is not very informative if the human cannot tell what is being allowed.

That said, the standard is legible, not omniscient. A system may not know every downstream consequence: a recipient may forward a message, another service may create logs, a published item may be copied. No approval interface can predict all of that. The checkpoint should make the proposed action understandable enough for the human to decide — not pretend to predict the entire future.

Before means before

Which one is an approval? Only B.

A may be review, notification, or after-the-fact oversight, and those can all be worth having. But it is not approval of the action that already occurred, because that action is not waiting for an answer.

A checkpoint cannot prevent a consequence that has already happened.

Not every step needs a permission slip

The opposite failure is just as real. Compare open_source on a permitted public source with send_briefing to another person.

Depending on the job and the environment, requiring a human click before every ordinary read may add friction without giving the human a meaningful decision. Anthropic notes the practical consequence directly: when a task requires dozens of actions, repeated prompts become a source of friction, and users sometimes tune them out.

That last part is the real risk. A checkpoint a human has learned to dismiss without reading is worse than no checkpoint, because it produces a record of approval without the judgment.

A checkpoint becomes more useful where factors such as external consequences, sensitivity, irreversibility, ambiguity, important uncertainty, or repeated failure make human judgment valuable. There is no formula here, and this course is not going to give you one. The goal is meaningful human control, not maximum interruption.

Sometimes the checkpoint is “I need you”

Not every checkpoint is about a consequence. Suppose the agent has adapted the query, tried the permitted fallback, and still cannot obtain the required evidence — Module 6’s stop condition, arriving.

The appropriate checkpoint here is not approve an action. There is no action to approve. It is closer to:

I cannot complete this part of the job within the current
    boundaries. What would you like to change?

So human intervention serves at least two different purposes: authorizing a consequential proposed action, and resolving a problem the system should not decide alone. Both are checkpoints. Only one involves a side effect.

Three of this course’s terms now sit close together, so it is worth separating them:

A boundary describes the limits. A stop condition describes when continuing should end. A checkpoint creates a human decision point.

Approval answers the proposal in front of you

Suppose the human approves send_briefing to one recipient. That approval does not, by itself, mean: send future briefings, send to other recipients, publish the briefing, modify the briefing, or use every messaging tool.

Approval has a scope. The question worth asking is what the human actually authorized.

One action or a standing permission?

Different systems offer different scopes. Conceptually, an approval might cover:

• this one proposed action;
• this tool for the current task;
• a defined category of similar actions; or
• a broader continuing permission.

Not every product offers all of these, and the labels vary.

The second is not merely a faster version of the first. It changes where future human checkpoints occur — which is to say, it removes some of them.

Broader approval genuinely does reduce repeated interruptions, and given the tune-out problem above, that can be the right call. But the two things arrive bundled together. Convenience and continuing authority can be bundled into the same choice.

Before choosing broader permission, understand what actions it will cover.

Approval is a human decision, not a quality guarantee

A human may approve the wrong recipient, an outdated draft, a mistaken action, or an action they misunderstood.

An approval mechanism ensures that a decision reached the human. It does not ensure the decision was correct.

Human-in-the-loop adds human judgment. It does not make human judgment infallible.

What would you want to see before approving?

Four independent proposed actions. For each, ask what you would need to know before deciding.

Human involvement is not only Yes or No

A checkpoint framed as a pair of buttons hides most of its value.

A human looking at a proposal may notice the wrong target, the wrong draft, missing information, or a boundary problem. The useful next step might then be to correct the recipient, revise the draft, narrow the action, supply missing context, reject it outright, or hand the job back to the agent with new instructions. A checkpoint can improve the next action instead of merely stopping it.

Not every product lets you edit a proposal directly inside the approval step, and where it does not, the equivalent is rejecting and re-stating the job.

“Do not send” and “ask before sending” are different controls

Instructions shape what the agent should choose. Checkpoints can shape what the environment will allow to happen automatically.

Module 2 promised this second lever and deferred it; here it is. But be precise about the claim: not every approval system technically guarantees that every path is blocked. What a checkpoint actually enforces depends on how it was implemented, which is a question about the product rather than about agents in general.

Selection is not execution

This may be the most useful thing in the module. Written out as a sequence:

1. the agent selects send_briefing;
2. the system pauses;
3. the human reviews the proposed tool, its input, and its consequence;
4. the human decides; and
5. only if permitted, the action executes.

The model may control route selection while the surrounding environment controls whether a particular consequential action proceeds automatically.

That sentence is the whole course in miniature. Module 1 asked who decides what happens next; the honest answer, eight modules in, is that different parts of “what happens next” can belong to different decision-makers.

Stanford’s guidance puts the checkpoint before the external action

Stanford’s current Responsible Agentic AI guidance↗ (opens in a new tab) recommends human-in-the-loop controls that require confirmation before external actions, naming sending messages, changing permissions, publishing content, running deletions, deploying code, and making purchases.

That list is not exhaustive, and it is a list of effects rather than of tools. It sits alongside Stanford’s broader instruction to understand what an agent can read, what it can do, where its outputs and logs go, and who can access them.

If you completed MCP Without the Mystery: that tutorial showed a real observed approval step before a fictional local write. This module generalizes the idea — the model can propose a consequential tool call while the host retains a human decision point before execution. Note where the approval came from: the host product, not the protocol. A connection standard describes how a capability is reached; it does not by itself create a checkpoint.

A checkpoint only controls what passes through it

One caution to carry forward. Suppose some tools require approval and others do not, a second route can perform the same action, or permissions turn out broader than expected.

In that case one visible checkpoint does not prove every consequential path is covered. Seeing an approval prompt tells you that this action was routed through a human. It tells you nothing about the actions that were not. A human-in-the-loop design has to be understood in the context of the capabilities it actually controls.

Module 10 returns to supervising a whole system rather than a single action.

What to notice

A useful checkpoint has three qualities:

• the proposal is visible;
• the consequence has not occurred yet; and
• the human still has a meaningful choice.

The purpose is to place human judgment where the system should not decide alone, which is narrower than approving every step.

Before you continue

You are ready for Module 9 if you can:

• distinguish a proposed action from an executed action;
• explain why approval has to occur before the consequence;
• identify useful information to expose at a checkpoint;
• explain approval scope;
• distinguish one-time approval from broader continuing permission;
• explain why human intervention can also occur when the agent is stuck;
• distinguish a natural-language boundary from a technical checkpoint;
• explain why approval does not guarantee that either the action or human judgment is correct; and
• explain why a checkpoint only governs the actions routed through it.