Human-in-the-Loop (HITL) Design#

Conceptual Explanation#

HITL Trigger Categories#

Confidence-based triggers: The agent's uncertainty exceeds a defined threshold. Relevant when agents produce confidence scores (via log-probabilities, self-assessment, or explicit uncertainty prompts) and low-confidence outputs warrant human review.

Risk-based triggers: The action being taken has side effects above a defined risk level. Sending a prior authorization determination is higher risk than reading patient data. All Write/Delete/External tool calls are candidates for risk-based HITL.

Policy-based triggers: Business rules require human authorization regardless of agent confidence. Certain drug combinations requiring pharmacist review, procedures above a cost threshold requiring utilization management review, or any determination affecting patient safety.

Anomaly-based triggers: The agent detects something unexpected in its reasoning path — conflicting guidelines, missing data, a patient profile that falls outside the training distribution of the evaluation criteria — and escalates proactively.

The Interrupt-Resume Pattern#

HITL requires the system to:

1. Interrupt — suspend execution at a defined node in the workflow
2. Persist — save the complete workflow state durably (database, not memory)
3. Notify — alert the appropriate reviewer(s) with the context they need
4. Await — accept asynchronous human input (approval, modification, rejection, escalation)
5. Resume — inject the human decision into the workflow state and continue execution from the interrupt point

The critical property is that state is persisted durably between steps 2 and 5. The reviewer may act seconds or days later. The system must be resumable regardless.

Core Architecture#

Common Mistakes#

Designing HITL as an afterthought. HITL requires durable state persistence, interrupt-capable execution, and asynchronous review flows. These are architectural requirements that must be designed from the start. Adding them to an already-built autonomous system typically requires significant refactoring.

In-memory state at interrupt points. If workflow state is held in memory at the interrupt point, a container restart between the interrupt and the reviewer's decision loses all state. Always persist to durable storage (PostgreSQL, not Redis unless Redis is configured for durability) before notifying the reviewer.

Undefined reviewer authority. A HITL system without explicit reviewer-role authorization mapping will route clinical approvals to whoever happens to be available. Define who is authorized to approve what, and enforce it in the routing and authentication layer.

No timeout policy. A HITL workflow without timeout handling will accumulate stale pending reviews. Define and implement SLA enforcement before go-live.

Best Practices#

• Design HITL into the state machine from day one — interrupt points are architectural, not operational
• Persist state durably before notifying reviewers — never hold interrupt state in memory
• Define explicit reviewer-role-to-trigger-type mappings and enforce them with authorization
• Implement SLA monitoring with escalation paths for overdue reviews
• Build immutable audit logs for all HITL decisions
• HITL UI should present evidence, not just the agent's conclusion — reviewers should exercise judgment, not rubber-stamp
• Test the resume path explicitly in integration tests — the interrupt is only half the pattern

Alternatives#

Interview Questions#

Q1: What are the four HITL trigger categories, and how would you decide which applies to a clinical prior authorization workflow?#

Category: Architecture Difficulty: Senior Role: AI Architect

Answer Framework:

The four trigger categories are: confidence-based (agent uncertainty exceeds threshold), risk-based (action side-effect level), policy-based (business rule requires human authorization regardless of confidence), and anomaly-based (agent detects unexpected state and proactively escalates).

For clinical prior authorization: policy-based triggers are non-negotiable — any determination that affects patient care requires documented physician authorization under CMS and Joint Commission standards. Risk-based triggers apply to the submission tool (External, consequential). Anomaly-based triggers apply when the agent encounters conflicting guidelines or missing data it cannot resolve. Confidence-based triggers are supplemental — if the evaluation model reports LOW confidence, escalate even if the other triggers do not fire.

In practice, for clinical workflows, policy-based triggers dominate: certain decision types always require human review, regardless of agent confidence. The other three categories add additional coverage.

Key Points to Hit:

• Policy-based is often non-negotiable in regulated industries
• Risk-based maps naturally to the tool side-effect classification (Read/Write/Delete/External)
• Anomaly-based requires the agent to reason about its own uncertainty — harder to implement reliably
• Multiple trigger types can co-apply; use OR logic (any trigger fires = escalate)

Q2: Why must HITL interrupt state be persisted to durable storage before the reviewer is notified, and what happens if it is not?#

Category: System Design Difficulty: Mid-level Role: ML Engineer / AI Architect

Answer Framework:

The reviewer may act seconds after notification or hours later. Container restarts, application deployments, and infrastructure failures can occur in that window. If interrupt state is held only in memory (in the agent process), any restart loses the state entirely — the workflow is lost, the reviewer's decision has nowhere to land, and the original request must be resubmitted from scratch.

With durable persistence (PostgreSQL with a checkpointer like LangGraph's PostgresSaver): the agent serializes complete workflow state before notifying the reviewer; the notification goes out after persistence succeeds; when the reviewer acts, their decision is written to the same store; when the agent resumes, it loads state from the store regardless of whether the original process is still running. The entire HITL pause is process-independent.

The architectural rule is: notification must come after persistence succeeds. If persistence fails, the notification must not be sent — there is no state to resume into.

Red Flags (What NOT to say):

• "We can use Redis for this" without qualifying that Redis needs AOF or RDB persistence configured
• "The reviewer will act quickly so in-memory should be fine"

Key Takeaways#

• HITL is an architectural requirement, not an operational feature — design it into the state machine from day one
• The four trigger categories are: confidence-based, risk-based, policy-based, and anomaly-based; regulated industries often mandate policy-based triggers
• The interrupt-resume pattern requires: interrupt → persist durably → notify → await → resume
• State must be persisted to durable storage before the reviewer is notified — never hold interrupt state in memory
• Define SLAs, reviewer authority, and timeout escalation paths before deployment
• HITL audit logs must be immutable and include: agent proposal, reviewer identity, decision, rationale, and timestamp