Resilience, Reliability & Failure Handling

44 — Human-in-the-Loop (HITL)

Place accountable human decisions at explicit workflow boundaries, presenting sufficient evidence and preserving approval scope through execution.

Concept overview

Human-in-the-loop architecture asks a person to provide judgment, approval, clarification, or correction at a defined point in an agent workflow. The value comes from matching human responsibility to the decision, not from adding an approve button to every output. Reviewers need the proposed action, relevant evidence, uncertainty, alternatives, and consequences.

Approval is a versioned authorization artifact. Bind it to the exact action and parameters, authenticate the reviewer, and recheck material changes before execution. A human's presence does not guarantee safety: overloaded reviewers can rubber-stamp requests, and poorly designed interfaces can hide the information needed for an informed decision.

Why it matters in production

Proof of concept

A prototype can pause and show a proposed action to a domain expert. Observe what evidence the reviewer actually needs to accept or reject it.

Production

Production creates durable review tasks, role-based assignment, expiry, escalation, and clear reject or edit semantics. Record the approved parameter version and resume through a validated boundary.

Enterprise scale

At scale, prioritize reviews by risk and uncertainty, monitor queue age, and evaluate reviewer disagreement and automation bias. Reserve human attention for decisions where it materially improves the outcome.

Architecture components

Review trigger

Determines which conditions require judgment or approval under explicit policy.

Decision package

Presents the proposal, source evidence, uncertainty, and expected consequences.

Review queue

Assigns work to authorized people and tracks age, escalation, and service expectations.

Approval record

Binds the authenticated decision to exact parameters, versions, and validity limits.

Execution gate

Rechecks approval scope and current preconditions before performing the action.

The architecture, mapped

Approval bound to a specific action — The execution gate verifies that the action still matches what the reviewer actually approved.

sequenceDiagram
 participant A as Agent
 participant Q as Review queue
 participant H as Authorized reviewer
 participant G as Execution gate
 participant T as Business tool
 A->>Q: Proposed action and evidence version
 Q->>H: Review package
 H->>Q: Approve exact parameters
 Q->>G: Signed-in decision and scope
 G->>G: Recheck state and approval validity
 G->>T: Execute approved operation
 T-->>G: Authoritative result
 G-->>Q: Record outcome

Runtime flow

1
Detect review condition
Apply risk, policy, or uncertainty rules to the proposed next action.
2
Prepare evidence
Assemble a concise decision package with inspectable sources and unresolved issues.
3
Suspend durably
Persist the waiting state and release active worker resources.
4
Capture decision
Authenticate the reviewer and record approve, reject, edit, or request-more-information explicitly.
5
Revalidate scope
Compare current parameters and business state with the approved version.
6
Execute or revise
Continue only within approval scope, then record the actual outcome for reviewer feedback.

Reviewing an equipment maintenance recommendation

Energy operations · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A utility assistant analyzes maintenance records and proposes taking a pump out of service for inspection.

The problem

A technically plausible recommendation can overlook operational dependencies or current site constraints known to experienced staff.

Agent requirement

The assistant must support the responsible engineer's decision without directly controlling plant equipment.

Architecture

A review package includes evidence, uncertainty, affected assets, and proposed work-order parameters, with execution restricted to authorized administrative actions.

Runtime

The assistant detects a recurring fault pattern and creates a review task instead of issuing an equipment command.
The engineer edits the inspection window; the system validates and records the revised work-order scope before creation.

Failure scenario

If asset status changes after approval, the execution gate pauses and requests renewed review rather than applying stale authorization.

Operational impact

Track review quality, queue age, parameter changes, stale-approval rejection, and outcomes after review. Human oversight must remain meaningful and adequately supported.

Architecture tradeoffs

Decision	Benefit	Cost
Targeted review	Domain judgment can address uncertainty and contextual gaps.	Human queues add latency and staffing cost.
Exact approval binding	Execution remains within reviewed scope.	Small material changes may require another review.
Risk-based routing	Attention focuses on consequential decisions.	Trigger quality must be evaluated to avoid missed cases.

Failure scenarios & recovery

A reviewer approves without required authority

Detect: Role validation fails at decision capture or execution.

Recover: Reject the approval and reassign the task.

The proposal changes after approval

Detect: Parameter hash or business version differs.

Recover: Invalidate approval and present the updated decision package.

Common architecture mistakes

Showing only the model's confident summary

Include evidence, uncertainty, and consequences.

Treating approval as unlimited future authority

Bind it to specific parameters and validity.

Ignoring review fatigue

Measure workload and reserve mandatory review for meaningful boundaries.

When to choose this pattern

Choose it when

Consequential decisions require accountable human judgment.
Domain context cannot be fully encoded in rules.
A reviewer can inspect evidence before action.

Avoid it when

The review is ceremonial and cannot affect execution.
No qualified reviewer can respond within the task deadline.
Simple deterministic validation already resolves the issue.

Architecture checklist

Define precise review triggers.
Provide inspectable evidence and alternatives.
Authenticate and authorize reviewers.
Bind approval to exact parameters.
Expire stale or changed approvals.
Monitor queue age and review quality.