Human-in-the-Loop
"Human-in-the-Loop" (HITL) is an industry term for AI systems that include human oversight, approval, or input during execution. ORQO supports four distinct HITL patterns -- each suited to different levels of control, compliance needs, and workflow complexity.
| Pattern | Trigger | Best for |
|---|---|---|
| Agent-driven | The agent decides when to involve the human | Flexible, context-aware collaboration |
| Approval gates | A deterministic checkpoint blocks until a human (or system) responds | Regulatory compliance, quality assurance, budget authorization |
| User interrupt | The user proactively sends input to a running workflow | Corrections, steering, adding context mid-run |
| Escalation | The agent encounters uncertainty and asks for help | Edge cases, ambiguous inputs, low-confidence decisions |
Pattern 1: Agent-Driven
The agent decides when and whether to involve a human, based on its task directive and what it has found so far. This is the most flexible pattern -- the agent might ask for clarification on ambiguous input but proceed autonomously when the task is straightforward.
How it works
Enable Communicates with User on the agent's stage assignment. This gives the agent access to a messaging tool that lets it ask questions, request approvals, present options, or gather input before proceeding.
There is no separate "human review step" abstraction. The agent's task directive guides when it reaches out. This produces natural interactions where the human is consulted when genuinely needed rather than at predetermined checkpoints.
Common use cases
Input gathering -- An agent asks the user what they need before proceeding. Used when the task requires user-specific context that cannot be predetermined.
Mid-workflow review -- An agent in a middle stage presents intermediate findings and asks for direction. The user can steer the research, reject a path, or confirm the approach.
Final approval -- The last-stage agent presents results and asks whether the user wants to approve, revise, or discard the output before it is delivered.
Workflows can also accept a user message before execution starts via the Awaits User Input setting. This is a start parameter, not a HITL pattern -- the workflow has not begun yet. See Run a Workflow for details.
Pattern 2: Approval Gates
An approval gate is a deterministic checkpoint where the workflow pauses and waits for external approval before continuing. Unlike agent-driven HITL, the gate fires at a fixed point in the workflow regardless of what the agent thinks -- there is no AI discretion involved.
This is the standard pattern for regulated environments, quality assurance pipelines, and any workflow where a specific checkpoint must have human sign-off before proceeding.
How it works
An approval gate is built from three composable features:
- Blocking exit hook with Request Confirmation -- Sends a message (to Slack, WhatsApp, Telegram, the run UI, or any configured channel) and blocks until a response arrives.
- Sets outcome enabled on the hook -- The response value (
"approve","revise", etc.) becomes the stage's outcome. - Outcome routing on the stage -- Maps each response to a target stage, driving what happens next.
Draft → agents produce content
│
└─ Exit hook: Request Confirmation
Message: "Draft ready for review. Approve or revise?"
Options: approve, revise
Contact: editor (via Slack)
Blocking: yes
Sets outcome: yes
│
├─ "approve" → Publish stage
└─ "revise" → Revise stage → loops back to Draft
The workflow is fully paused at the hook. No tokens are consumed, no agents are running. The response can come from a human tapping a button in Slack, a reviewer replying on WhatsApp, a QA system calling an API endpoint, or an operator clicking in the run UI. The source does not matter -- any valid response unblocks the gate.
Concrete example: Editorial review loop
A content workflow with a mandatory editorial checkpoint:
Stage 1: Draft
Agents: writer, researcher
Exit hook: Request Confirmation
Message: "Approve for publishing or send back for revision?"
Options: approve, revise
Contact: editor
Blocking: yes, Sets outcome: yes
Outcome routing:
"approve" → Stage 2 (Publish)
"revise" → Stage 3 (Revise)
Stage 2: Publish
Agents: publisher
Routing: ends workflow
Stage 3: Revise
Agents: writer
Routing: returns to Draft ← loops back
The editor receives the draft on their configured channel, reviews it, and responds with "approve" or "revise." The workflow routes accordingly. If the editor sends "revise," the writer gets another pass, and the draft returns to the gate -- creating a review loop that continues until the editor approves.
Entry hook gates: launch control
Approval gates are not limited to exit hooks. A blocking entry hook on the first stage turns the gate into a launch control — the workflow starts but immediately pauses before any agent runs, waiting for a go/no-go decision.
This is particularly useful for scheduled workflows. A cron trigger fires the workflow at a set time, but instead of running automatically, the entry hook sends a message to the responsible person with options:
Stage 1: Weekly Report
Entry hook: Request Confirmation
Message: "Weekly report workflow triggered. How should we proceed?"
Options: now, delay, skip
Contact: ops-lead (via Slack)
Blocking: yes, Sets outcome: yes
Outcome routing:
"now" → Stage 1 (continues normally)
"delay" → Reschedule (a stage that re-triggers the workflow later)
"skip" → ends workflow (terminates without running)
The ops lead receives a Slack message every Monday at 9 AM and chooses whether to run the report now, delay it, or skip this week entirely. No agents execute until the human decides.
When to use approval gates
| Use case | Why a gate, not agent-driven |
|---|---|
| Regulatory compliance | Auditors need proof that a human approved before publishing. A gate creates a deterministic, auditable checkpoint. |
| Quality assurance | An editor must review every piece of content. The gate guarantees review happens -- agents cannot skip it. |
| Budget/resource authorization | A manager must approve before an expensive operation runs. The gate blocks until they respond. |
| Legal review | Contracts, public statements, or sensitive communications must be reviewed by legal before delivery. |
| External system handoff | A third-party API or scheduler provides the go/no-go signal. The gate waits for the external response. |
| Scheduled workflow control | A cron-triggered workflow checks with a human before running. An entry hook gate lets the user choose to proceed, delay, or skip. |
The confirmation endpoint accepts responses from any source -- another workflow, a cron job, a CI/CD pipeline, or an API integration. "Approval gate" is the human-centric framing, but the mechanism is a general-purpose blocking checkpoint.
Pattern 3: User Interrupt
The user proactively sends a message to a running workflow. This is the reverse of agent-driven HITL -- the human initiates contact, not the agent. A chat input field appears in the workflow run UI, and the user's message is injected into the active stage's conversation.
How it works
While a workflow is running, the user types a message in the run interface. The message is delivered to the agents in the current stage. Agents see it as an incoming message and can respond, adjust their approach, or incorporate the new information.
Common use cases
Course correction -- The user sees agents heading in the wrong direction and interjects: "Focus on the European market, not North America."
Adding context -- The user provides information the agents did not have: "The deadline moved to Friday -- prioritize the summary over the detailed analysis."
Clarification without being asked -- The user notices ambiguity in the agents' work and proactively resolves it before it compounds.
User interrupts are delivered to the current stage only. If the workflow has moved past the stage where the interrupt would be relevant, the agents in the current stage receive it instead.
Pattern 4: Escalation
An agent encounters uncertainty, conflicting information, or a situation outside its competence and asks the user to resolve it rather than guessing. This is implicit in the agent's autonomy -- it chooses to escalate when its confidence is low.
Escalation differs from agent-driven input gathering in intent: the agent did not plan to involve the human. It hit an unexpected situation and made a judgment call to ask rather than proceed with a potentially wrong answer.
How it works
Same mechanism as agent-driven HITL: the agent has Communicates with User enabled and uses its messaging tool to ask. The difference is behavioral -- the task directive does not instruct the agent to ask at a specific point. Instead, the agent's role description and perspective guide it to escalate when appropriate.
Example scenario
A research agent is tasked with finding competitor pricing. It finds conflicting numbers across sources and cannot determine which is current. Rather than picking one and risking an incorrect analysis downstream, it messages the user: "I found two different pricing figures for Competitor X -- $49/mo on their website and $39/mo on a review site from last month. Which should I use?"
The user resolves the ambiguity, and the agent continues with confidence.
Choosing the Right Pattern
| Question | Answer | Pattern |
|---|---|---|
| Must a human approve at a specific point, every time? | Yes | Approval gate |
| Should the agent decide whether human input is needed? | Yes | Agent-driven |
| Does the user need to steer or correct agents mid-run? | Yes | User interrupt |
| Is human involvement only needed for unexpected situations? | Yes | Escalation |
| Do you need an audit trail proving human approval? | Yes | Approval gate |
| Should the workflow pause with zero token consumption while waiting? | Yes | Approval gate |
| Is the interaction conversational (back-and-forth)? | Yes | Agent-driven |
These patterns are complementary, not mutually exclusive. A single workflow can use agent-driven HITL in a research stage, an approval gate before publishing, user interrupts for course correction, and escalation as a safety net throughout.
Comparison to Other Platforms
Most platforms implement HITL in one of two ways:
- Fixed approval node -- A "human review" step that pauses execution at a predetermined point. Rigid: the review happens regardless of whether it is actually needed.
- No structured HITL -- The agent can print messages, but there is no built-in mechanism for blocking on human input or routing based on responses.
ORQO supports both ends of the spectrum and everything in between:
| Approach | Who initiates | Predictability | ORQO mechanism |
|---|---|---|---|
| Agent-driven | Agent | Low -- depends on agent judgment | Communicates with User on assignment |
| Approval gate | System (hook) | High -- deterministic checkpoint | Blocking hook + sets outcome + routing |
| User interrupt | User | Unpredictable -- user decides when | Chat input in run UI |
| Escalation | Agent | Medium -- triggered by uncertainty | Communicates with User + agent perspective |
Agent-driven is more flexible. Approval gates are more predictable. Choose based on whether the use case demands guaranteed human checkpoints or benefits from adaptive agent judgment.
Related
- Stage Assignments -- Where you enable Communicates with User
- Hooks -- Entry and exit hooks, including blocking hooks and Request Confirmation
- Outcomes & Routing -- How outcomes drive stage transitions, including the approval gate example
- Workflow Triggering -- Approval gates can route outcomes to trigger entire workflows
- Run a Workflow -- How user input works during execution