How an AI Agent Can Stop and Ask: Four Interaction Paths and Their Conditions

CuriousRose, a Hacker News user running a SaaS business, asked how to stop an AI from continuing when clarification is needed. The post describes a large automation backlog and uncertainty about where a human belongs in the workflow. That points to a concrete implementation question: where should the application obtain a person's decision or additional input?

Anthropic's building-effective-agents guide describes agents pausing for human feedback at checkpoints or when encountering blockers, without specifying the API that implements that interaction. LangGraph and Claude Agent SDK documentation provides the implementation details examined in this feature.

The guide also recommends starting with a simple design and using environment feedback to assess progress. Those recommendations do not establish whether a particular action can safely proceed without a person's decision, and they do not measure a reduction in clarification frequency. Here the selection criterion is the interaction your application requires, with the documented prerequisites and failure behaviors considered alongside it.

LangGraph's interrupt() function pauses graph execution at any point within a node and waits for external input. Unlike static breakpoints, interrupts are dynamic: they can be placed anywhere in code and can be conditional based on application logic. When called, LangGraph saves the current graph state and waits indefinitely until execution is resumed with Command(resume=...).

Using interrupt() has two hard prerequisites: a checkpointer to persist graph state (use a durable checkpointer in production), and a thread_id in the config so the runtime knows which state to resume from. The thread_id is effectively a persistent cursor—reusing it resumes the same checkpoint; using a new value starts a brand-new thread with empty state. You must use the same thread ID when resuming that was used when the interrupt occurred.

Resumption replays the containing node from its beginning rather than continuing at the paused line. Code before interrupt() runs again, so side effects there should be idempotent or isolated in separate nodes—for example, an upsert with the same key and resulting value instead of creating a new record on every attempt. Otherwise resumption can repeat writes or other work.

Multiple sequential interrupts within one node are matched by index position: on resume the runtime replays from the node beginning, and for each interrupt encountered it checks whether a matching value exists at that index in the task's resume list. The order of interrupt calls within the node must therefore remain consistent—conditional skipping or reordering causes index mismatch. Parallel branch interrupts use ID mapping instead: each interrupt has a unique ID, and resume maps each ID to its value.

interrupt() pauses execution by raising a special exception. A broad or bare handler that catches and swallows it prevents the interrupt from reaching the graph. The documentation gives two valid alternatives: separate the interrupt() call from error-prone code so no handler wraps it; or catch only a specific exception type that excludes the interrupt exception, with NetworkException given as the example. Re-raising a caught interrupt exception would also let the pause propagate, which is consistent with the mechanism, but the documentation does not explicitly list this option; it is stated here as an inference from the described behavior.

For repeated human-input validation, the documentation recommends one interrupt() per node invocation: store a new question in state after failed validation and route back with a conditional edge. A while True loop containing repeated interrupts makes later resumptions replay earlier iterations and repeat work. Keep that replay behavior in view when deciding where to place validation and side effects.

The Claude Agent SDK's permission evaluation is not a linear pipeline but a conditional routing graph. When Claude requests a tool, the SDK checks six steps in order, but a decision at any step does not necessarily terminate the evaluation flow—some steps' allow results continue through subsequent checks, while some steps' denials terminate immediately. Understanding this conditional routing is essential for correct pause configuration.

Hooks run first. PreToolUse checks requests before the other permission steps and can deny, allow or modify them. A hook that returns allow does not skip the deny and ask rules below; those are evaluated regardless of the hook result. A PreToolUse hook allow also cannot approve an rm or rmdir removal targeting a critical path. Checks required before every tool call belong in the documented PreToolUse entry point, with the required decision logic actually implemented.

Step 2 is deny rules. If a deny rule matches, the tool is blocked, even in bypassPermissions mode. Bare-name deny rules like Bash remove the tool from Claude's context before this evaluation begins, so only scoped rules like Bash(rm *) are checked at this step.

Step 3 checks ask rules and tools requiring user interaction after earlier rejection checks. An ask rule can route a request toward confirmation even in bypassPermissions mode. AskUserQuestion, MCP tools marked requiresUserInteraction and organization-configured ask connectors are not ordinarily pre-approved by allow rules. The actual route still depends on mode and SDK interaction settings: dontAsk denies these requests, while the TypeScript permissionPrompts:'none' setting skips canUseTool at the final callback step and leaves a PermissionRequest hook a chance to decide.

Step 4 applies the permission mode. bypassPermissions approves everything that reaches this step except rm and rmdir removals targeting a critical path, which fall through instead. acceptEdits auto-approves file operations and filesystem commands only within its working-directory or additional-directory scope and protection conditions; it does not approve edits to arbitrary paths, protected paths or critical-path removals. In plan mode, file edits and shell commands that modify files still require the callback confirmation path. Auto mode uses a classifier model to review actions such as shell commands and network requests, allowing or blocking each one it reviews; this is automated action review rather than a request for human confirmation. If a session in auto mode switches to a model that auto mode does not support, the session changes to default mode.

Step 5 checks allow rules. Ordinary matches can approve calls, but four categories are never auto-approved: AskUserQuestion, MCP tools marked requiresUserInteraction, connector tools your organization set to ask, and rm/rmdir removals targeting a critical path. A general allow rule also does not approve a read from a network path. Whether an exception proceeds to confirmation or is denied depends on the applicable permission mode.

Step 6 is the canUseTool callback for requests left for a decision. dontAsk skips this step and denies the tool directly. In supported TypeScript SDK configurations, permissionPrompts:'none' skips the callback at this step, but a PermissionRequest hook still gets a chance to decide; if it does not, the call is denied. If you pass a canUseTool callback in a configuration where the TypeScript SDK expects auto-approval to shadow it (such as bypassPermissions mode or bare allowedTools entries), the SDK emits a CLAUDE_SDK_CAN_USE_TOOL_SHADOWED warning at query construction. Entries with a specifier such as Bash(ls *) and the acceptEdits mode do not trigger this warning, and allow rules coming from settings files are not visible to the check. In dontAsk mode, a PreToolUse hook allow does not clear a critical-path removal or a read from a network path either.

AskUserQuestion is the Claude SDK mechanism for model-initiated clarification. When Claude encounters multiple valid approaches during task execution and needs user direction, it calls this tool to generate structured questions. Each call supports 1 to 4 questions with 2 to 4 options each, and users may provide free-text responses in addition to selecting predefined options.

Check AskUserQuestion availability separately. If a tools array explicitly restricts the tool set, it must include AskUserQuestion; otherwise the model silently loses the ability to initiate clarification. The tool is also not currently available in subagents spawned via the Agent tool. Allow rules cannot pre-approve it, but earlier rejection checks, modes such as dontAsk and applicable SDK settings still affect the actual interaction path.

Model-initiated questioning is not the only path to user input. The user-input documentation explicitly records alternatives: developers can ask their own questions separately in application logic, outside the canUseTool flow; custom tools can build forms, wizards or multi-step workflows beyond AskUserQuestion's multiple-choice format; and streaming input allows humans to proactively send information mid-task without waiting for the model to ask.

For long-running processes where user response time may exceed process lifetime, the documentation recommends registering a PreToolUse hook that returns the defer decision instead of waiting in the callback. This allows the process to exit and resume later from the persisted session. The documentation does not specify the serialization format or storage mechanism for the persisted session that enables later resumption.

Claude Agent SDK's streaming input mode provides human-initiated mid-task intervention capability without waiting for the model to request input. The documentation lists three use cases: interrupting the agent mid-task by sending a cancel signal or changing direction while Claude is working; providing additional context without waiting for the model to ask; and building chat interfaces where users send follow-up messages during long-running operations. Streaming input operates as a persistent session handling incoming messages, permission requests and session state, with messages queued sequentially.

The user-input documentation explicitly names sending a cancel signal as a use case, but the signal format, delivery mechanism and effect on an in-flight tool call are not specified in any loaded document. Queueing a message is not the same operation as canceling an executing tool. Single-message input mode does not support dynamic message queueing or real-time interruption; it suits one-shot requests or environments that do not need mid-task intervention. It can still continue through session state and resumption, so it is not inherently stateless.

Streaming input has a documented debugging trap: in the TypeScript SDK, if your message generator throws—for example when a file it reads is missing—the stream ends with an error that reads 'Claude Code process aborted by user' instead of the original error. Check the code inside your generator first when you see that message. The error may be preceded by a long minified line of bundled SDK source, so read to the end of the output for the error text. In the Python SDK, a generator exception is logged at debug level and the session stalls without raising, so if a streaming session hangs with no output, enable debug logging and check your generator.

This comparison concerns documented behavior and integration conditions. The cited material does not supply comparable pause-frequency, ambiguity-detection or mechanism-effectiveness measurements, so it does not establish a framework reliability ranking. Selection is based on interaction-pattern fit, not performance ordering.

Programmed gates only stop at covered conditions. They cannot guarantee the model recognizes every ambiguity, that requirements are sound, or that completed work is correct. Anthropic's building-effective-agents post recommends finding the simplest solution possible and only increasing complexity when it demonstrably improves outcomes, and emphasizes that agents should gain ground truth from the environment at each step—such as tool call results or code execution—to assess progress.

Pauses, task structure and independent verification complement one another. Where results can be checked independently, tests or tool feedback can supplement gates; where verification is difficult, decisions about which actions need prior human judgment require more care. This is a control-design judgment, not a measured interrupt-effectiveness result, and a pause is not proof that the work is correct.