Human-in-the-Loop (HITL) Insertion Points: Where to Gate an Agent Loop

Deciding Where a Checkpoint Belongs

Hooks (the previous concept) give you a deterministic mechanism for gating a tool call. This concept answers a different question: where in the loop should that gate go? Run one test per step: if this step fires with nobody watching and it turns out to be wrong, how bad does that get, and can it be undone? Steps that score high on damage and low on recoverability earn a checkpoint; steps that don't, don't. Applying that test consistently is what surfaces the right insertion points.

Three Places That Test Points To

None of these three substitutes for the others, and relying on just one is a common gap. A pre-write gate stops a bad *action* from landing. A post-planning gate is different: it catches a *plan* that is wrong before the first action in it even runs, which a pre-write gate alone would miss since each individual step might execute cleanly. An unexpected-output gate covers yet another failure shape -- the tool didn't error out loudly, it came back with something quietly off (empty, out of range) that blindly retrying would never repair.

Why "It Passed Validation" Is Not the Same as "Safe to Commit"

A sharp version of this failure: an agent that reads, edits, and writes a configuration file re-validates after every write and only stops once validate_config returns a pass. In testing, that loop converges cleanly. In production, the agent correctly identifies an out-of-range parameter, corrects it, writes it, re-validates, and the write passes -- but the corrected value was a rate limit a downstream system depended on, and validate_config was never designed to check cross-system dependencies. The loop did exactly what it was told; the missing piece was a checkpoint between "proposed change ready" and "write committed to the live environment." That gap is precisely the *before a destructive tool call* insertion point, and it has to be designed in before the first incident, not patched in after.

Common exam traps

• Treating "the tool call succeeded" as equivalent to "the tool call was safe." A write can pass its own local validation and still be catastrophic to a system the validator never checked.
• Gating only the destructive-call point and skipping the post-planning gate. A wrong plan that executes flawlessly still produces the wrong outcome -- the destructive-call gate alone doesn't catch a bad *plan*, only a bad *action*.
• Assuming a HITL checkpoint is only relevant to the loop-wiring checklist and not a design decision. The insertion point should be decided when scoping the tool surface, not discovered after the first production incident.