Pattern 12

Loop selection: not everything should be a loop

Problem. Give an agent real capability and the tempting response is to automate everything: put a loop on every recurring task, "remove yourself as the bottleneck." But most real work is judgment-heavy, irreversible, or unverifiable. Loop the judgment work and you remove the value (the judgment was the point). Loop the irreversible work and you ship damage unattended. Autonomy gets treated as a pure good, and the question of which tasks earn it never gets asked.

Pattern. A four-box test. A task earns an autonomous loop only when it is all of: (1) recurring, a cadence or repeated event, not a one-off; (2) mechanically verifiable, where a script, exit code, schema, or diff confirms it worked, not human taste; (3) low-judgment-per-instance, the same decision every time, not a fork on context only you hold; (4) headless-executable, able to run unattended with no interactive credential, no GUI, no human mid-step. An irreversibility override caps any outward or destructive act (email sent, comment posted, money moved, history pruned) at surface even when all four boxes pass: verifiability gates correctness, it does not gate consequence. Three buckets fall out. Loop: all four boxes and reversible/inward, runs autonomously on a trigger, the verifier is the gate. Surface: recurring and verifiable but judgment-heavy or irreversible, so a read-only nudge or an approval-gated act, never silent autonomy. Keep manual: fails recurring or carries high judgment per instance — you drive, tooling assists. A worked surfacing case: a close-out routine that, the moment a task finishes, runs a read-only scan and shows what drifted across the workspace (stale context docs, fired strategic triggers, aging backups, open questions going cold) for the operator to action while still in context. It adds no new autonomy; it widens the operator's view at the moment state changed.

Why this beats the obvious. The obvious move is to automate everything and treat the human as the bottleneck to engineer out. But an autonomous loop only pays where the work is verifiable and low-judgment; pointed at judgment work it either strips the value or acts wrongly with nobody watching. This is the same route-by-consequence instinct as classify-then-act (Pattern 2), tier-by-impact (Pattern 4), the skill-as-weights gate (Pattern 10), and the scaffold-as-hypothesis gate (Pattern 11): gate by what an action costs if wrong, not by how automatable it feels. For a solo operator whose own judgment is the product, the restraint is the point — the loops exist to protect attention for the judgment-heavy work, not to hand that work to the machine.

Cost. A test you have to actually run, honestly, against the pull to automate. And a verification step before it: check the target against the code, not its description, on three axes. Does it exist on the relevant branch (git ls-tree, never a working-tree glob alone)? Does it do what its description claims (read the script: an "additive backup" turned out to be a destructive --prune)? Can it run headless? A task can pass every quality box and still fail box 4. Scoring from descriptions instead of code manufactured three wrong "loop this" calls in a single design pass.

Where it lives: samples/scripts/wrap_drift_scan.py (the read-only close-out surfacing scan — the worked surface case).

Seen in 2 of 8 teardowns · Practise: learn/06