Skip to Content
HarnessHuman-in-the-loop

Human-in-the-loop (HITL)

HITL is the platform’s answer to “when must a person decide?” Approval gates are uniform across channels: whether an action originates in the console, an Automation Studio workflow, a production agent behind the gateway, or a coding agent in the IDE, the same policy decides whether it runs, waits for a human, or is blocked—and every verdict is audited.

Why it matters

Autonomy without gates means unattended mistakes; gates without uniformity mean agents do in one channel what another would block. Scattered, per-tool approval logic also leaves no single audit story for compliance. HITL makes the human gate a platform primitive—declared once as policy, enforced everywhere, recorded always.

How it works

Every action route ends in one of three verdicts: allow, ask a human, or deny. What differs per channel is only where the pause surfaces.

The HITL surfaces

ChannelGateWhere the human decides
Automation StudioHuman approval step with assignee, deadline, and on_timeout (approve / reject)Approve inbox—context trail, yes/no path preview, inline approve / reject / comment
Production agentsGuardrails policy gates on tool calls, budgets, and rate capsStructured deny/ask reasons returned to the agent; escalations routed to operators
IDE coding agentsRelay bash, path, MCP, and prompt controlsThe ask verdict pauses the editor for engineer confirmation before side effects
DevX AssistInteractive confirmation surfaces before governed actionsCards and forms in chat/console—approve before the action executes
Harness changesEvals review queues on prompt / skill promotionHuman review of edge cases before traffic shifts

Designing good gates

  • Gate by risk, not by default — allowlist reversible, low-blast-radius actions; require approval for irreversible production side effects (deletes, secrets, payments, auth).
  • Give the approver context — Studio approvals carry the run’s context trail; Relay asks show the exact command or tool call. An approval without context is a rubber stamp.
  • Set timeout behavior explicitly — every approval step declares what happens when the deadline passes (reject is the safe default).
  • Record overrides — human decisions that override an agent are part of the audit trail and, for loops, written back to memory so the agent stops re-proposing them.
  • Tighten as autonomy grows — moving a workflow from report-only to unattended (see Loop Engineering) means narrowing the ask surface deliberately, not removing it.

Capability checklist

  • Human approval steps in workflows with assignee, deadline, and timeout policy
  • Policy gates and structured ask/deny verdicts at the gateway
  • Editor-level confirmation for IDE agent actions via Relay
  • Review queues for prompt and skill promotion
  • Tamper-evident audit of every verdict—allowed, asked, and denied

Console walkthroughs for authoring approval policies will be added when product how-to assets are available. Related: Approve (Automation Studio), Guardrails, Relay.

Last updated on
GuardrailsOverview