Human-in-the-Loop vs AFK
When to sit beside the agent and when to send it away — and the four things that must be true before you can walk away
Two ways to work with an agent
Every task you hand an agent is done in one of two postures. Most people only ever use one of them, and pick it by habit instead of by the task. Naming both is the first move.
You watch each step, approve, correct, and steer in real time. The agent is fast hands; you are the judge on every turn. Tight feedback, full control, and you are present for all of it.
You hand over a scoped job with a clear finish line and a way for the agent to check its own work, then you leave. You read the result, not every step. Less control mid-flight, far more reach.
Neither posture is the "advanced" one. The skill this module teaches is reading a given task and knowing which posture it actually wants — and what you would have to build to move it from one to the other.
Why AFK is where the leverage hides
Human-in-the-loop has a hard ceiling: your own attention. One agent, one you, watching it work. However fast the agent types, your throughput is capped at the one thread you can supervise.
AFK removes you from the inner loop. The moment you are no longer needed on every step, you can run several jobs at once — each in its own git worktree, each its own agent instance. Output stops being limited by how fast you can watch and starts being limited by how many well-scoped jobs you can define and verify.
Leverage is merged, verified work per day, with you gating only the few decisions that matter — not the largest agent count. AFK is what lets you scale the work without scaling the hours. But leverage you cannot trust is a liability: AFK only pays if the work comes back right. That is the catch — and it has a price of entry.
What AFK requires first: four gates
The rule under all of it: you cannot send away what you cannot verify. Before a task earns AFK, run it through four gates. Fail one, and it is not an AFK task yet.
An objective completion signal — tests pass, the site returns 200 and contains X, the queue is empty. If you cannot define done, you cannot walk away: a loop without a real finish line quietly declares success on half-finished work.
A deterministic gate — tests, linter, type-check — that the agent cannot reason its way past, ideally plus a separate judge. The maker must not be the only grader; self-review is biased toward declaring victory.
AFK carries overhead — scoping, wiring, a gate. It pays back on larger jobs (roughly five-plus story points), not a one-line fix. Send away a trivial task and you spend more time wiring the loop than the task would have taken by hand.
The agent can both do the work (edit, run, commit) and check it (run the tests and linter) inside a sandbox — without touching production, money, or live data while unattended.
When a task fails gate 1 or 2, you usually do not abandon AFK — you build the missing piece. "Improve the code" becomes "raise coverage from 16% to 95%." "Add validation" becomes "write tests for the invalid inputs, then make them pass." Translating a fuzzy goal into a measurable one is the single highest-value move you can make.
The rule: human at the edges, AFK in the middle
The choice is rarely whole-task. It is per-phase. The durable shape is to gate the edges with a human and let the agent run unattended in between.
Is the spec right? Get the plan correct before you send anything away. A wrong spec run AFK comes back as wrong work, just faster.
Implement, fix, refactor against the gate. This is the part with a clear done and a deterministic check — exactly what AFK is for.
Read the diff before it merges or ships. You sign off, not the agent. The gate caught the mechanical errors; you catch the judgment ones.
Production deploys, database writes, anything involving money. No gate is good enough to make these unattended. Approval is mandatory.
For the first few runs of a new AFK task, make it pause at every step for your approval — "quick check before I burn the tokens." Confirm it does what you want, then turn the training wheels off and let it run. You earn the right to walk away by watching it work a few times first.
Sitting-with is how a task graduates to send-away
The two postures are not rivals — they are stages. You prove a task by hand, in the loop. In doing so it earns a clear "done" and a real gate. Then you can send it away, and review the result. Human-in-the-loop is the apprenticeship that qualifies a task for AFK.
So "I have to babysit this one" usually means the gate is not built yet — not that the task can never be sent away. Build the gate, and the same task you had to watch becomes one you can run three of in parallel.
Sending an agent away does not move accountability off you. What ships is still yours — you have only moved your attention from every keystroke to the decisions that actually matter: the spec, the gate, and the review. That is the Gold Hat line. Empower yourself to do more; never use "the agent did it" to dodge what you signed off on.
Your move: take one task you currently babysit. Run it through the four gates. Whichever gate it fails — no clear done, no real check, too small to bother, no sandbox — that failed gate is the next thing you build.
Posture check
Three tasks land on your desk. Pick the right posture — and the reason.
A task you have never done before. No tests exist, and the goal is "make this part better." You want it off your plate fast.
Best posture?
You want to get more done in the same hours. You are already supervising one agent closely, all day.
What actually unlocks running several at once?
A scoped migration with a passing test suite as the gate. The final step pushes the change straight to production.
How do you run it?
Name one task you babysit today. Walk it through the four gates — clear done, an unfakeable check, worth the setup, a sandbox. The first gate it fails is your next build. Build that, and a task you had to watch becomes one you can send away.