Skip to main content
When a workflow pauses for HITL, it exposes the pause through three nested objects. You read them to find out what is being asked, then resolve the innermost ones and call continue_run.

1. WorkflowRunOutput

The top-level run object tells you that a pause happened and where. Convenience filters return subsets of step_requirements:
step_requirements accumulates resolved requirements as run history. To determine the current pause, read only the last entry: (run_output.step_requirements or [])[-1:]. This matters during nested HITL, where a single run pauses more than once. The filter properties above already exclude resolved requirements, so prefer them when you can.

2. StepRequirement

Each entry in step_requirements describes one paused step. The fields that are set depend on what kind of pause it is. Resolution methods (step-level): Status properties: needs_confirmation, needs_user_input, needs_output_review, needs_route_selection, needs_executor_resolution, is_resolved, is_timed_out.

3. Executor Requirements

When requires_executor_input is True, the step paused because the agent or team called a HITL tool. Each entry in executor_requirements is one pending tool call. These are the same RunRequirement objects an agent exposes on a standalone run. Status properties: needs_confirmation, needs_user_input, needs_external_execution, is_resolved. Resolution methods (executor-level): See Executor HITL for full resolution examples.

Resolution Flow

Developer Resources