Where a person stays on the path

Two reasons to hand the run back

A person stays on the path. That handoff is the human-in-the-loop practice for AI, and it has two triggers you write down before the system runs. The agent has used up the retries you allowed. Or it is about to do something that cannot be undone.

OpenAI’s guide of 15 January 2026, A practical guide to building agents, names both, in its section on planning for human intervention. It describes the handoff as the agent passing control back gracefully when it cannot finish: to a human agent in customer service, or to the user in a coding tool.

There is a third route, and it should not be confused with the first two. A good agent will sometimes stop on its own to ask. Anthropic’s note of April 2026, Trustworthy agents in practice, treats this as one of the harder problems in agent design. An agent that stops at every question gives up the autonomy that made it useful. One that always pushes on misreads what people want. Anthropic reports that on complex tasks Claude checks in about twice as often as on simple ones. That is welcome, but it is the model’s judgement. The two written triggers are yours, and they hold whatever the model decides.

The method around the build is in How to build an AI agent that holds.

When the retries run out

OpenAI’s first trigger is a limit on retries or actions. Their example is a customer request the agent still has not understood after several attempts.

You write the number before the system runs, and the person who owns the process chooses it. Count in two places: attempts at the same step, and total actions in the run. The second catches the loop where an agent makes slow progress in circles and never repeats a step exactly. A model that keeps trying is not that limit.

What the person receives matters as much as when. A handoff that says “agent failed” makes the person start again from nothing, and they will soon stop trusting the system. The handoff should carry the original input, what was tried, what each attempt returned, and why the run stopped. In the invoice process used across these guides, that means the invoice, the purchase orders the agent considered, the mismatch it found, and the rule that stopped it. The person resolves the case in minutes instead of redoing it.

When the action cannot be undone

OpenAI’s second trigger is a high-stakes action, one that is sensitive, irreversible, or costly. The examples are theirs: cancelling an order, authorising a large refund, making a payment. These wait for a person until confidence in the system has grown.

The same split applies to any step the process cannot undo. A read can continue. A write that moves money waits. In practice, give each action one of three settings: always allowed, needs approval, or blocked. Anthropic describes this model for the tools in its own apps. A user might let Claude read a calendar freely but require approval before it sends an invitation. Your guardrails decide which actions are blocked outright. This step decides which ones wait.

An approval only works if the person approving actually looks. Two failure modes are well documented.

Approval fatigue. Anthropic notes that when a task needs dozens of actions, repeated approval prompts become friction and people start to tune them out. Their answer in Claude Code is to show the whole plan up front for review and editing, and to let the person step in at any point during the run. Apply the same idea to a batch. Approve forty matched invoices as one plan, with the three that differ from normal shown first, rather than as forty separate prompts.

Automation bias. People tend to accept what a machine proposes. The EU AI Act names this directly. Article 14, which covers human oversight of systems the Act classes as high-risk, requires that the people assigned to oversight can understand what the system can and cannot do, stay aware of the tendency to over-rely on its output, interpret that output correctly, override or ignore it, and stop the system. Whether or not your system falls under that article, the list is a sound specification for an approval screen.

In practice that means the person sees four things before deciding: the proposed action, the evidence behind it, what makes this case different from a normal one, and a reject option that is as easy to use as approve. Then measure. If the approval step never rejects anything, either the agent is excellent or the step has become a rubber stamp, and only the data can tell you which. One way to find out is to place a few known-bad cases in the approval queue now and then and see whether they get caught. That is our practice, not a requirement from either source.

How we take one measured process into production sits on the AI agents page.

Early runs set the limits

OpenAI says the handoff matters most early on, because that is when the failures and the odd cases show up, and when an evaluation cycle gets built. The limits you wrote are revised from those runs. They are not a slogan added after a launch.

Every handoff is data. Each case a person had to take over is a candidate for the evaluation set. It shows the agent where it failed, and it gives the next version a case to pass.

Loosen limits one action at a time, and only on evidence: the case set passes reliably on repeated runs, and the handoff log shows the person approving that action without changes over a sustained period. Tighten immediately after a single bad outcome on an irreversible action. Trust in a system that moves money should be earned slowly and withdrawn quickly.

The two questions stay in front of the person who owns the process. How many tries are allowed? Which actions wait for a person? Add a third once the system is running: when the person approves, are they checking?