Human in the Loop

An agent that tidies a project folder may decide that an old draft is no longer needed and ask to delete it. An agent that handles your inbox may decide to send a reply in your name. Both actions have effects that stay after the agent has finished, and one of them cannot be taken back.

For actions like these, most people do not want the agent to act alone. They want to see the action first and say yes or no.

Human in the loop is the name for this arrangement. The agent stops before certain actions, a person is asked, and the action runs only if the person allows it. The human has the final say.

After this lesson you can tell which actions call for approval, explain which part of the software does the stopping, and describe how the builder of an agent sets this up tool by tool.

1. Which actions need a person

Take six things an agent might do and sort them into two groups.

The dividing line is not how difficult the task is. Summarising a long file is harder than deleting one. The dividing line is what the action leaves behind.

The actions on the left only read. When they are finished, every file is as it was, no message has gone out, and no account balance has changed. If the agent searched the wrong folder, the only loss is a little time.

The actions on the right change something. A change that an action leaves behind is called a side effect. A deleted file is gone. A sent email is in someone's inbox and cannot be called back. Transferred money is in another account. If the agent got it wrong, the mistake is already out in the world.

So the question to ask about a tool is: if this runs by mistake, what remains afterwards, and can it be undone. The less an action can be undone, and the more it affects other people or money, the stronger the case for asking a person first.

2. Where the pause is built

An agent system has three layers. Each has a different part in human in the loop.

Start from the bottom. The model produces text. When it wants an action, it produces a tool call, which is a written request such as "delete this file". It has no way to run the request, and it also has no way to block it. A model can be instructed to check with the user before risky steps, and it often will, but that is a habit and not a guarantee. If the model is confused or has been misled by text it read, it may ask for the deletion straight away.

The harness is the software around the model. It receives every tool call and is the part that would run it. This is the one place where a call can be reliably stopped, because nothing runs without passing through it. So human in the loop is built into the harness.

The application is the part with a screen. When the harness holds a call, the application displays the question and collects the answer.

This has a practical consequence. Human in the loop exists only if the software you use supports it. It is not something the model brings along. At the time of writing, ChatGPT, Claude, and many other agent products do support it.

3. The approval prompt

Most people who have used an agent have already seen this on screen. Here is the sequence for one action.

The model sends a tool call, and it looks like any other tool call:

delete_file("draft-07.txt")

The application does not run it. It shows a question:

Delete draft-07.txt ?

    [ Allow once ]
    [ Deny ]

While the question is on screen, the tool call is waiting. Nothing happens until you answer. The file is still there, and the agent does not move on to its next step.

"Allow once" means this one call may run. The next deletion will be asked about again. Many products also offer a broader choice, such as allowing the same kind of action for the rest of the session. A broader choice means fewer interruptions and less checking.

The same kind of question can appear for milder actions, for example before the agent opens a file or reads a folder for the first time. That is the folder-by-folder permission described in the lesson on sandboxes. The mechanism is identical: a call is held, a person answers, and only then does anything run.

4. Where the call stops

The next diagram shows the path of a tool call through the harness.

flowchart LR
    M["The model asks<br/>for a tool call"] --> W["The wrapper<br/>around certain tool calls,<br/>not all.<br/>The call is held here"]
    P["A person<br/>allows or denies"] --> W
    W -- "allowed" --> T["The tool runs"]
    W -- "denied" --> N["Nothing happens"]

The model asks for a tool call. Before the call reaches the tool, it meets a piece of code called a wrapper. A wrapper is code placed around something else, so that every request has to pass through it first. Here it is placed around certain tool calls, not all of them.

At the wrapper, the call stops instead of running. The person is asked. There are two ways out:

• Allowed. The call continues and the tool runs as requested.
• Denied. The call ends there. The tool does not run, and nothing changes on disk, in the mailbox, or in the bank account.

In most harnesses the model is then told about the outcome. After a denial it receives a message such as "the user did not allow this action". It can then choose another approach or ask what you would like instead. This is how the pause fits into the agent loop: the loop waits at the approval step and continues with whatever result comes back.

The name "human in the loop" comes from this picture. The agent runs in a loop of asking, acting, and reading results. For some steps, a person is placed inside that loop.

5. The setting is written per tool

Which calls stop and which do not is not decided by the model. Someone wrote it down in the harness, tool by tool. A simple version looks like this:

the agent's tool table

search_files    auto
read_file       auto
write_file      ask
delete_file     ask
send_email      ask

Each line names a tool and gives it one of two settings.

The table follows the rule from section 1. Searching and reading leave nothing behind, so they are auto. Writing, deleting, and sending leave something behind, so they are ask.

The table is written by whoever built the harness. If you build an agent yourself, that person is you. Many products also let the user adjust these settings, for example to switch file writing from ask to auto inside one trusted project.

Because the setting belongs to the harness, the same model can behave very differently in two products. In one, it deletes files without a question. In another, every deletion waits for approval. The model is the same in both. The tool table is different.

6. Choosing the setting for each tool

A person who builds an agent decides, for every tool that is added, who is able to say no to it.

Two mistakes are possible, and they point in opposite directions.

• Too few tools ask. If send_email is auto, one wrong decision by the model sends a real message before anyone sees it.
• Too many tools ask. If read_file and search_files are ask, the agent stops every few seconds. An agent that reads forty files would show forty prompts. The work becomes slow. A second effect is that people who see constant prompts stop reading them and click "Allow" by habit, so the prompts no longer protect anything.

So some tools must ask first, and some must never stop to ask. These criteria help with the decision:

Human in the loop and sandboxes work together. A sandbox limits where the agent can act. Human in the loop limits which actions run without a person seeing them. Using both gives two separate layers of protection.

One limit should be stated plainly. Approval helps only if the person understands what is being approved. A prompt that says "Run command" without showing the command gives the person nothing to judge. A useful prompt shows the exact action: which file, which recipient, which amount.

Interview points

• Human in the loop means an agent pauses before certain tool calls and a person allows or denies each one. The call does not run until the person answers.
• The criterion for requiring approval is the side effect of the action, not its difficulty. Reading, searching, and summarising change nothing. Deleting, sending, and paying leave changes that may not be reversible.
• The model only requests tool calls and cannot reliably enforce a pause on itself, so approval is implemented in the harness, which is the code that receives and executes tool calls.
• The application layer displays the approval prompt, with choices such as allowing once or denying.
• A wrapper around selected tools holds the call. If allowed, the tool runs. If denied, the tool does not run, and the model is normally informed so that it can continue differently.
• The approval policy is configuration in the harness, commonly one setting per tool: auto to run immediately, ask to wait for a person. It is not a property of the model.
• The same model can run with or without approvals depending on the product that hosts it.
• Asking for too little lets harmful actions through. Asking for too much slows the agent and trains users to approve without reading.
• Human in the loop complements sandboxing: the sandbox limits reach, and approval limits which actions run unseen.

Summary

• Human in the loop gives a person the final say over selected agent actions.
• Actions that leave nothing behind can run freely. Actions that leave a change need approval.
• The pause is built into the harness, because the model can only ask.
• The application shows the question, and the tool call waits for the answer.
• An allowed call runs. A denied call does not run.
• Each tool has a setting, such as auto or ask, written by whoever built the harness.
• A builder decides for every tool whether it must ask first or must never stop to ask.
• An approval prompt is useful only when it shows exactly what will happen.