Human-in-the-Loop

The Protect layer. Autonomy is the default, but the consequential moments route to a person. When a policy escalates, the run pauses until a human decides — and an operator can halt a run outright at any time.

#Overview

Full autonomy is right for most of what an agent does and wrong for the few actions that are irreversible, sensitive, or high-blast-radius. Human-in-the-loop is how the platform draws that line: those actions pause for a person to approve or stop, and everything else runs unattended.

This is the Protect layer — the runtime counterpart to governance policy. Policy decides that an action needs a human; this layer is how the human is brought in, what happens while the run waits, and what happens if no one answers.

#Escalation

When a policy evaluates to ESCALATE — or an action is declared to require approval — the run does not proceed on its own. The pending action is held, the run pauses at exactly that point, and an approval request is sent to a human.

  • Approve resumes the run from where it paused, and the action proceeds as if it had been allowed.
  • Reject stops the action: the run sees a rejection and continues from there without performing it.

The pause is blocking. The action is not attempted and then rolled back — it simply does not happen until a human decides, so escalation is safe even for irreversible operations.

#Approval routes

An escalation route connects an escalation to the place a human will see it. Routes are scoped — to an agent, to a role, or platform-wide — and resolve from the most specific scope that applies, so the right people are asked for the right agents.

A route points at an approval channel. At the product level a channel can be Slack, email, a webhook, or a chat space — wherever your reviewers already work. Routes have priority levels: if the highest-priority level does not respond in time, the request escalates to the next level rather than stalling.

Note

Same-priority channels are notified in parallel, and the first responder wins. Whoever approves or rejects first decides the outcome; the request is then resolved everywhere else so no one acts on a stale prompt. Which channels exist and how routes are scoped is configured in the Governance area — see Governance & Policies.

#Just-in-time authorization

Just-in-time authorization is the grant issued when an escalation is cleared. It is not a standing permission and it does not edit policy. It is a time-bounded elevation for a capability that is normally denied — scoped to that run, that capability, and a window that expires. When the route requires approval, a reviewer must explicitly approve before the elevation is granted; when it is configured to auto-approve, the grant is issued automatically for the pre-authorized capability.

The point is least privilege without friction. An agent is denied a sensitive capability by default; when it genuinely needs it, the elevation grants exactly that capability for exactly as long as it is needed, and the grant lapses on its own. Every grant is recorded in the audit trail with who approved it and how long it was granted for.

#Timeouts & fail-closed

An escalation does not wait forever. Each approval request has a window. If a level of routes does not respond within it, the request escalates to the next priority level; if every level is exhausted with no decision, the escalation auto-denies.

Important

No decision means deny, never allow. Timeouts are fail-closed: the absence of an approval is treated as a refusal, so an unattended escalation can never silently let a sensitive action through.

This is why escalation is safe to wire onto consequential actions even when reviewers are offline.

#Kill switches

A kill switch is an operator action that halts a single in-flight run immediately. It does not wait for the agent to reach a safe point and it does not negotiate — it terminates that run's execution outright.

  • Halt a run — kill a single in-flight execution that is going wrong; the run's gateway stops accepting actions and the run ends.
  • Circuit breaker — to stop an agent from accepting future runs, the platform trips a separate, persistent circuit breaker (managed in the Governance area) that stays open until an operator clears it. This is distinct from the per-run kill switch.

Where escalation is a planned checkpoint, the kill switch is the unconditional stop for a run that is already going wrong, and the circuit breaker is the durable halt for an agent that should not run again until reviewed. All of these leave a record in the audit trail.

#Next steps

  • Governance & Policies — Deny-by-default policy evaluation, the ALLOW/DENY/ESCALATE model, precedence, and roles.
  • Audit & Compliance — The immutable record of every escalation, approval, grant, and kill-switch action.
  • Observability — Watch runs pause, resume, and stop in real time with step-level execution traces.