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
Parachutes are useless if you pack them after jumping. HITL gates must stop the orchestrator before an irreversible action, not notify after it. If you ask for approval after deletion, the gate is ceremonial.
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 the pre-action confirmation checkpoint is correct: The design principle violated is placing the HITL gate after the action execution rather than before it. The fix is to implement a pre-action confirmation checkpoint: the orchestrator must pause and obtain human approval before any irreversible action is dispatched to an agent. 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 the lower-latency notification channel fix 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 the post-action undo step 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 the increased HITL timeout window 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.