Human-in-the-Loop: When AI Agents Should Ask for Help

The autonomy spectrum

There is a spectrum of agent autonomy, and every AI product sits somewhere on it.

At one end: full human control. The AI suggests an action. The human reviews it. The human clicks "approve." The AI executes. Then it suggests the next action, and the cycle repeats. Every step requires explicit human permission.

At the other end: full delegation. The human describes the goal. The AI plans the approach, executes every step, handles errors, and delivers the result. The human sees the output, not the process.

Neither extreme works well.

Full control is exhausting. If the agent needs permission to read a file, permission to write a file, and permission to run a script, a ten-step task requires ten approval clicks. The user becomes a button-pressing automaton. The agent has intelligence but no authority. The productivity gain over doing the work manually is marginal -- you have traded typing for clicking "approve."

Full delegation is terrifying. An autonomous agent with unrestricted access to your file system, network, and computing resources could delete your files, exfiltrate data, or rack up enormous costs before you notice anything is wrong. Unconstrained autonomy without safety boundaries is irresponsible engineering.

The interesting design space is in between. The agent acts autonomously on most operations but pauses for human input on specific categories of actions. The question is where to draw the line.

When agents should ask

Some actions warrant a pause. Not because the agent lacks the ability to execute them, but because the consequences of getting it wrong are severe or irreversible.

Destructive actions. Deleting files is the canonical example. If the agent misinterprets "clean up the project folder" and deletes source files instead of temporary files, the damage is real. Deletion is often irreversible -- or at least difficult to reverse. The cost of asking "should I delete these 14 files?" is a few seconds. The cost of not asking could be hours of lost work.

This does not mean every write operation needs approval. Creating files is not destructive -- if the agent creates an unwanted file, you delete it. Overwriting a file is potentially destructive, but an auto-backup mechanism makes it reversible. Deletion is the line because it removes information from existence.

Ambiguous intent. When the user's request has multiple valid interpretations, the agent should ask for clarification rather than guess.

"Summarize the financials." Which financials? The Q3 report on the desktop? The annual filing in the project folder? All spreadsheets in the current directory? A human colleague would ask. The agent should too.

The alternative -- the agent picks one interpretation and runs with it -- wastes time when it guesses wrong. The user receives a summary of the wrong documents and has to restart. Asking takes five seconds. Redoing the work takes five minutes.

High-stakes decisions. Some tasks involve judgment calls with significant consequences. "Restructure the client database to improve query performance" is a legitimate request, but the restructuring could break existing queries, destroy data relationships, or cause downstream failures. The agent should propose its plan and ask for confirmation before executing structural changes.

The common thread is irreversibility. Actions that are easy to undo can proceed autonomously. Actions that are difficult or impossible to undo should involve the human.

External communications. When an agent has the ability to send emails, post messages, or interact with external systems on behalf of the user, it should confirm before sending. An accidentally sent email to a client cannot be unsent. An erroneous API call to a production system might trigger real-world consequences. The latency of asking is negligible compared to the risk of acting without authorization.

When agents should not ask

The flip side is equally important. An agent that asks too often is almost as useless as one that cannot act at all.

Read-only operations. Reading files, listing directories, searching file contents -- these operations have no side effects. The agent is gathering information, not changing anything. Asking "can I read this file?" before every file read turns a five-second operation into a thirty-second interaction.

If the file is in the user's project folder and the user has asked the agent to work on that project, reading files is implicit authorization. The user does not need to confirm every file the agent opens, any more than they would confirm every drawer a human assistant opens while organizing their office.

Reversible write operations. Creating new files, writing analysis outputs, generating reports -- these operations add to the workspace without removing anything. If the agent creates an unwanted file, the user deletes it. If the agent writes output in the wrong format, the user asks for a different format. The cost of undoing is trivial.

Writing is the agent's primary output mechanism. If it needs permission to write, it cannot deliver results without interrupting the user. This defeats the purpose of delegation.

Clear intent with obvious execution. When the user says "extract all dates from this contract and list them," the intent is unambiguous and the execution is straightforward. The agent should read the contract, extract the dates, and present the list. Asking "should I read the contract?" or "should I extract the dates?" adds friction without adding value.

Clear intent means the user's request maps to a specific, well-defined action or sequence of actions. There is no ambiguity to resolve and no judgment call to make. The agent has enough information to act.

Intermediate steps in a multi-step workflow. When the agent is executing a complex task, the intermediate steps are implementation details. If the agent decides to write a Python script to process data, it should write and execute the script without asking. The user asked for the analysis, not for a play-by-play of the agent's implementation choices.

Interrupting a multi-step workflow at every intermediate step destroys the flow. The user is forced to approve each step without meaningful context for whether the step is correct. "Should I run this Python script?" -- the user cannot evaluate the script's correctness from a confirmation dialog. The interruption provides an illusion of control without actual control.

The problem with approval dialogs

Many agent products implement human-in-the-loop through modal approval dialogs. The agent proposes an action. A popup appears: "The agent wants to read file.docx. Allow / Deny." The user clicks Allow. Another popup: "The agent wants to run a Python script. Allow / Deny." Click Allow. Another popup: "The agent wants to write output.csv. Allow / Deny." Click Allow.

This pattern fails for several reasons.

Decision fatigue. After approving the tenth action in a row, the user stops reading the dialogs and clicks "Allow" reflexively. The safety mechanism has become a speed bump -- it slows the user down without actually protecting them, because they are no longer making informed decisions.

Loss of context. A modal dialog shows you the action in isolation. "Run this script" -- but you do not know why the agent wants to run it, what it expects to happen, or how it fits into the overall task. You cannot make a good approval decision without understanding the context, and a dialog box does not provide context.

Interruption of flow. Modal dialogs steal focus. They break the user's concentration. If the user is reviewing one agent's output while another agent is working in a different pane, approval dialogs from the second agent interrupt the first task. Multiply this by several concurrent tasks and the experience becomes unworkable.

False sense of security. Users believe that because they are approving each action, they are in control. But they are not evaluating the actions meaningfully. They are pattern-matching on "does this look dangerous?" -- and they are not qualified to assess most agent actions at the individual step level. The real safety comes from architectural constraints (sandboxing, cost limits, scope restrictions), not from user approval of individual tool calls.

The better pattern is to let the agent work autonomously within well-defined boundaries and ask questions in the conversation when it genuinely needs human input.

The "ask in chat" pattern

There is a simpler approach. When the agent needs human input, it asks in the chat. No modal dialog. No approval popup. Just a message in the conversation.

"I found 14 temporary files in the project folder. Should I delete them? Here is the list: [files]. Let me know and I will proceed."

This pattern preserves context. The user sees the question alongside the conversation history. They understand why the agent is asking, what it has done so far, and what will happen next. The question is not an isolated action requiring approval -- it is a natural part of the conversation.

It also respects the user's attention. The message sits in the chat until the user is ready to respond. There is no modal dialog stealing focus. The user can finish what they are doing, read the question, and reply when it makes sense. The agent waits.

The ask-in-chat pattern aligns with how human delegation works. When you delegate a task to a colleague, they do not ask for permission at every step. They do the work and come back when they hit a decision point that requires your judgment. The interaction is asynchronous and respectful of your time.

docrew uses this pattern exclusively. The agent has no approval dialogs, no permission popups, no confirmation modals. When it needs human input, it asks in the chat. When it does not, it acts.

Design principles for good handoffs

The line between "act" and "ask" is not arbitrary. Good agent design follows consistent principles.

Principle 1: Optimize for the common case. Most agent actions are non-destructive, non-ambiguous, and clearly aligned with the user's intent. The common case should be fast and frictionless. Asking should be the exception, not the default.

If 95% of actions are safe to execute autonomously, the interface should be optimized for autonomous execution. The 5% of actions that need human input should be handled gracefully, but they should not dictate the design of the entire interaction model.

Principle 2: The cost of asking must be lower than the cost of getting it wrong. Asking the user "should I delete these files?" costs ten seconds. Deleting the wrong files costs hours. Asking is clearly worth it.

Asking the user "should I read this file?" costs ten seconds. Reading the wrong file costs nothing -- the agent simply reads the correct file next. Asking is not worth it.

Apply this calculus to every category of action. The answer becomes clear quickly.

Principle 3: Provide context, not just the action. When the agent does ask, it should explain why it is asking and what the alternatives are. "Should I delete these files?" is less useful than "I found 14 .tmp files and 3 .log files in the build directory. These appear to be build artifacts. Should I delete them, or would you prefer I keep any of them?"

Context turns an approval request into a collaborative decision. The user has enough information to make a good choice, rather than guessing whether "Yes" is the right answer.

Principle 4: Let boundaries do the heavy lifting. Instead of asking permission for individual actions, constrain the agent's operating environment so that most actions are safe by default.

File access scoped to the project folder means the agent cannot read or modify files outside the workspace. Sandboxed code execution means scripts cannot access the network or the broader file system. Cost ceilings mean the agent cannot run up an enormous bill on model tokens. Maximum tool call limits mean the agent cannot get stuck in an infinite loop.

These architectural constraints provide stronger safety guarantees than user approval ever could. A user clicking "Allow" does not prevent a sandboxing violation. A properly implemented sandbox does.

Principle 5: Make autonomy earn trust incrementally. New users are naturally cautious. They want to see what the agent is doing, verify its decisions, and build confidence in its judgment. Experienced users want the agent to handle more without interruption.

This suggests a trust ramp: the agent starts more communicative, explaining its reasoning and showing its work. As the user demonstrates comfort (by not correcting the agent, by providing less detailed instructions, by delegating larger tasks), the agent can become more concise and more autonomous.

The trust ramp is not about changing the agent's capabilities. It is about changing its communication style. A new user might want to see "I read the contract, found 47 clauses, and identified 3 that contain unusual termination provisions. Here is my analysis." An experienced user might just want the analysis, without the narration of how the agent arrived at it.

The autonomy dial in practice

Different products sit at different points on the autonomy spectrum, and their positioning reveals their design philosophy.

Products that require approval for every action are optimizing for safety at the expense of usability. They are designed for environments where the cost of a mistake is extremely high -- or where the product team does not trust their own safety constraints enough to let the agent operate autonomously.

Products that offer no human-in-the-loop at all are optimizing for speed at the expense of safety. They work well in constrained domains (chatbots with predefined responses, for example) where the action space is limited and the consequences of errors are low.

Products that implement thoughtful autonomy boundaries -- acting on safe operations, asking on risky ones, constraining the environment architecturally -- are the ones that work for real tasks. They are fast enough to be useful and safe enough to be trustworthy.

docrew's position on the spectrum is decisively toward autonomy. The agent reads files without asking. It writes files without asking. It creates directories, runs code, processes documents, and delivers output -- all without interrupting the user. It asks before deleting. It asks when intent is ambiguous. It asks when the task involves a judgment call that the user should own.

This means the agent can complete a ten-step document analysis workflow without a single interruption. The user asks for the analysis and receives the finished output. The steps in between -- reading files, parsing documents, running extraction scripts, writing results -- happen autonomously.

When the agent does need input, the question appears in the conversation. The user responds. The agent continues. No modals, no popups, no approval queues.

The trust ramp

Trust between a user and an AI agent is not static. It builds over time through repeated successful interactions.

A user's first interaction with an agent is cautious. They give a small, low-stakes task. "Read this file and tell me what is in it." They watch the output. They verify it against the actual file. They confirm the agent did what they expected.

The second interaction is slightly bolder. "Read these three files and create a comparison." They check the output less meticulously. They trust the file reading capability because it worked correctly last time.

By the tenth interaction, the user is delegating complex, multi-step tasks. "Analyze all the contracts in this folder, extract the key terms, compare them against our standard template, and flag any deviations." They trust the agent's file reading, document parsing, analysis, and output formatting because each capability has been validated through repeated use.

This trust ramp has implications for agent design.

Early interactions should be transparent. The agent should show its work: which files it read, what it extracted, how it reached its conclusions. This transparency helps the user calibrate their trust.

Later interactions should be efficient. Once trust is established, the user does not need a play-by-play. They need the result. The agent can be more concise, showing less intermediate reasoning and more final output.

Trust is per-capability, not global. A user might trust the agent's file reading completely but be skeptical of its analytical conclusions. Trust builds independently for each capability. The agent should not assume that trust in one area extends to all areas.

Trust is fragile. One significant error can reset the trust level. If the agent produces a badly wrong analysis, the user reverts to checking everything carefully. The agent needs to maintain accuracy consistently, not just on average.

The broader design lesson

The human-in-the-loop question is fundamentally a question about design values.

Products that interrupt constantly value the appearance of safety over the reality of productivity. Products that never interrupt value speed over the user's peace of mind. Products that interrupt thoughtfully value the user's time and judgment equally.

The right answer is not a technical specification. It is a design philosophy. What kind of relationship do you want between the human and the agent?

If the agent is a tool -- something you operate step by step -- then approval dialogs make sense. You are in control. The tool does nothing without your explicit direction.

If the agent is a collaborator -- something that works alongside you, handling tasks within its competence and escalating decisions outside it -- then the ask-in-chat pattern makes sense. You delegate. The agent delivers. You intervene when needed.

If the agent is a crew member -- something that takes ownership of tasks, manages its own workflow, and comes to you only for genuine decision points -- then high autonomy with smart boundaries makes sense. You set the direction. The agent handles the execution.

docrew is designed around the crew member model. The agent takes ownership. It does the work. It asks when it genuinely needs your judgment. The rest of the time, it stays out of your way and delivers results.

This is not the only valid design choice. But it is the one that respects the fundamental promise of AI agents: that they do the work, so you do not have to.

The trust ramp makes this work in practice. New users get a more communicative agent that shows its reasoning. Experienced users get a more autonomous one that delivers results with less narration. The underlying capability is the same. The interface adapts to the relationship.

That is the design lesson. Human-in-the-loop is not a feature you add or remove. It is a relationship you design. And the best relationships are the ones where both sides know when to speak and when to act.