A team reports that their orchestrator's human-in-the-loop (HITL) approval gate consistently triggers after irreversible actions have already been taken — for example, cloud resources are deleted before the human approver is notified. Which design principle was violated, and what is the correct fix?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A parachute is useless if you pack it after jumping. The same logic applies to HITL gates — if the human is asked to approve an action that has already happened, the gate is purely ceremonial. HITL must be a pre-action gate that halts execution until approval is received, not a post-action notification that confirms what was done.
Full explanation below image
Full Explanation
Human-in-the-loop is a critical safety control in agentic systems that perform high-consequence or irreversible actions. Its entire value depends on being positioned before the action — if the human is notified after the action executes, the HITL mechanism provides auditability but no prevention.
Why B is correct: The HITL gate must be architecturally positioned as a synchronous checkpoint that the orchestrator reaches before dispatching any irreversible action to an agent. The orchestrator's execution flow should be: (1) identify that the next action is high-consequence or irreversible; (2) pause execution and dispatch a human approval request (with full context: what action, why, what resources are affected, what the risk is); (3) wait for explicit approval before proceeding; (4) only after approval is received, dispatch the action to the agent. If a timeout occurs without approval, the default behavior should be to cancel the action, not to proceed.
Why A is wrong: Notification latency is a factor in how quickly the human receives the request, but it does not fix the fundamental problem: the action already executed before the human was notified. Even zero-latency notification is useless if it arrives after the irreversible step completes.
Why C is wrong: Post-action undo is a recovery pattern — and a valuable one for certain types of actions. But not all actions are undoable (deleted cloud resources, sent emails, financial transactions), and relying on undo as the primary safety mechanism for irreversible actions is an unsafe design. The HITL gate exists specifically to prevent irreversible actions from occurring without approval.
Why D is wrong: The timeout window controls how long the orchestrator waits for a response. Extending it does not fix the sequence problem: if the action has already executed, giving the approver more time to respond is meaningless. If the timeout was causing the action to proceed before the approver responded, the fix is to make the default timeout behavior 'cancel', not 'approve', and to position the gate correctly before the action.
The exam takeaway: HITL gates for irreversible actions must be pre-action synchronous checkpoints with default-deny on timeout. Post-action notification is not a HITL gate — it is an audit notification.