Human-Agent Interaction Models

The vocabulary comes from supervisory control of automated systems, and it transfers cleanly to agentic software because it asks the right question: at what point in the loop does a human have authority? What has changed by 2026 is that a single product often occupies all three positions within one session. An assistant reading a page needs no permission, filling a form wants a glance, and moving money needs an explicit yes.

Human-in-the-loop

When to use it

When the action is irreversible, externally visible, or expensive — sending a message under the user’s name, deleting records, committing to a purchase, changing permissions. Also when the agent is new to a user or a domain and has no track record to draw trust from, and whenever the cost of a wrong action clearly exceeds the cost of an interruption.

This is the model behind agents that work in a side panel next to the thing they are operating. Claude’s Cowork client in Chrome works this way: the agent operates the page in view while the person watches, and it asks before the steps that commit. ChatGPT applies the same shape when it confirms consequential steps rather than proceeding on inference alone. The side-panel arrangement is doing design work — the object being acted on stays on screen, so the approval is not abstract.

What the interface must provide

• A statement of the proposed action in the user’s terms, including the specific target (“send this reply to Dana at 4:15”, not “execute send_email”).
• The evidence behind it: what the agent read or inferred that led to this step.
• An edit path, not just approve and reject. Most bad proposals are nearly right.
• A way to widen the grant — approve this action, approve this class of action for the session, approve it always — so the user can trade confirmations for autonomy deliberately.
• Preserved context on refusal: rejecting one step should not discard the whole run.

Failure modes

• Approval fatigue. Confirming everything trains users to confirm without reading, which is worse than no confirmation because it manufactures a record of consent that never happened.
• Illegible prompts. A confirmation showing raw parameters transfers responsibility without transferring understanding.
• Lost throughput. If every step blocks, delegation stops being worth it and users revert to doing the task themselves.
• Injected consent. If the agent’s proposal is derived from untrusted page content, the confirmation dialog may be faithfully relaying an attacker’s instruction. Gating is not integrity.

Human-on-the-loop

When to use it

When the task is long, multi-step, and mostly composed of low-consequence operations, but the trajectory still matters. Research, browsing, comparison, monitoring, and multi-file edits all fit: each individual step is cheap, and the risk is going the wrong direction for twenty steps rather than any single move. Gemini’s agentic browsing behaves this way — it navigates and gathers on its own while the user watches the run and can take the wheel — as do background information agents that keep working on a standing brief.

What the interface must provide

• A live trace at the right altitude: what it is doing now and why, summarized as steps rather than streamed as logs. Supervision requires something a person can skim.
• A stop that actually stops — immediate, always visible, and honest about what had already completed when it landed.
• Mid-run correction. The most valuable intervention is not stopping but redirecting: adding a constraint the agent should have had, without restarting from zero.
• Automatic hard stops. Certain classes of action should drop out of on-the-loop and demand approval, no matter how autonomously the run began.
• A durable record of the run, so the person can reconstruct what happened after they looked away.

Failure modes

• Supervision theater. A scrolling trace nobody reads looks like oversight and provides none. If the interface cannot be skimmed at a glance, the human is effectively out of the loop while the product claims otherwise.
• Out-of-the-loop performance problems. The long-documented cost of monitoring automation: attention degrades, situational awareness fades, and the person is least prepared to take over exactly when the system hands them control.
• Stop with no rollback. Halting a run that has already changed six things is only half a control if the interface cannot tell the user which six.
• Silent drift. The agent quietly reinterprets the goal — still busy, still reporting progress, no longer doing what was asked.

Human-out-of-the-loop

When to use it

When the task is scheduled or triggered rather than requested, when nobody is present to supervise, and when the action space is narrow enough to be bounded in advance. Nightly digests, monitoring and alerting, recurring data pulls, triage passes, scheduled research briefs. The distinguishing feature is not that the agent is more capable — it is that the human is asleep.

What the interface must provide

• Explicit, inspectable boundaries: which tools, which accounts, which spending limits, which data, for how long. Delegation happens at setup time, so setup is where the design effort goes.
• A report built for someone who was not there. Lead with what changed and what needs attention, not with a chronological transcript.
• Honest reporting of what it could not do. Silent partial completion is the characteristic failure of unattended work.
• Post-hoc reversal: a durable action log with undo or a documented compensating action for every entry.
• A kill switch and expiry. Standing authority should lapse by default rather than persist until someone remembers it.

Failure modes

• Compounding errors. With nobody watching, a wrong premise gets applied to every item in the queue before anyone notices.
• Stale authority. Permissions granted for one purpose in one context remain live months later under circumstances the user never considered.
• Unreadable reports. A summary too long to read reproduces the supervision-theater problem asynchronously.
• No accountable trail. When something turns out wrong days later, the person needs to identify the action, its inputs, and its authorization. If that record does not exist, neither does recovery.

A second axis: where the user reaches the agent

These three models answer how much oversight an action needs. They say nothing about a separate question that turns out to matter just as much: how many places a person can reach an agent from, and whether those places share anything.

A product can get the oversight model exactly right and still be unusable because the user faces four disconnected assistants and has to guess which one owns their problem. The two axes are independent, and the second one is where most products currently go wrong — see entry points and orchestration.

Escalation: moving between models as stakes rise

The interesting design work is not picking a model but defining the transitions. A single delegated request — “find me a flight and book it” — crosses all three: unattended searching, supervised comparison, gated purchase. The user should never have to ask for that escalation; the system should apply it.

A workable approach is to classify every action the agent can take along two axes — consequence (who is affected, how visibly, at what cost) and reversibility (can the system itself undo this, is there a compensating action, or is it permanent) — and bind an oversight level to the classification rather than to the product. Reading is autonomous. Drafting is autonomous with review. Sending, buying, deleting, and granting access are gated.

Beyond the intrinsic properties of the action, four signals should tighten oversight:

• Novelty. A step outside the pattern of the current task, or the first time this agent has touched this system for this user.
• Scope expansion. The plan grew: more items, more systems, more accounts than the original request implied.
• Low confidence or ambiguity. Where the agent had to guess, the guess should be surfaced rather than absorbed.
• Untrusted provenance. The instruction driving this step originated in fetched content rather than from the user. That should escalate on its own, regardless of the action’s cost.

De-escalation deserves as much care. Trust earned over many successful runs is a legitimate reason to loosen oversight — but it should be an explicit user choice with a visible current state (“this agent can spend up to $50 without asking”), reversible in one step, and it should not carry over into a materially different context.