2.1 Live loops: repeat while you watch

What it looks like

A common pattern in agent tools:

> /loop "check if the tests pass; if they do, stop; if not, fix and re-run"

…and then five to twenty cycles later you get a clean test run, or you decide the loop is stuck and stop it yourself. Same shape works for:

• “Keep drafting variants of this email until I say one is good.”
• “Rewrite this section, review it, rewrite again until the reviewer says it’s fine.”
• “Try candidate designs; show me each; stop when I approve one.”

The characteristic is that the cycle rate is human-visible — a cycle every few seconds to a few minutes, and you’re right there watching.

Why start here

Live loops are the fastest way to develop the reflex of thinking in loops. Three reasons:

• Cheapest failure mode. If it goes off the rails, you close the window. Nothing was scheduled, nothing was persistent, no email got sent. The blast radius is your terminal.
• Fastest feedback. You see every cycle. When one goes wrong, you know exactly what changed. When the loop finally converges, you know exactly why.
• No infrastructure. No cron entry, no webhook, no deployment. Just a running session.

Practitioners who never build live loops first tend to over-engineer scheduled ones. Practitioners who build ten live loops before their first scheduled one usually pick better designs.

Where live loops end

Two things force you to graduate from live to something else:

1. You want to walk away. If the job takes forty minutes and you have other work, you don’t want to babysit. You either commit to sitting there or promote the loop to something that can run without you.

2. You want it to happen on a schedule. A live loop runs when you type the command. A scheduled loop runs at 6am whether or not you thought about it. The moment “when should this run?” is not “right now, because I said so,” you’ve outgrown live.

Both of these are Chapter 2’s other three sections. Live loops are the first step, not the destination.

The right stopping condition

Every live loop needs a stopping condition, even if the answer is “I stop it when I’m happy.” Better ones you can state explicitly:

• Pass condition: “Stop when pytest exits 0.”
• Count condition: “Stop after 10 cycles regardless.”
• User-confirm condition: “Stop when I type ‘done’.”
• Diff condition: “Stop when two consecutive cycles produce the same output.”

A loop with no explicit stop is a loop that will run forever if the model gets confused, because the model has no reason to conclude “we’re done.” Give it one.

What lives in the sandbox

Even live loops benefit from a sandbox — a scratch branch, a temporary directory, a container. Not because unattended safety matters (you’re right there), but because the ability to throw away a failed cycle is what makes live loops useful. If every cycle writes directly to your main branch, you can’t safely try five drafts; you have to commit to whichever one you started.

More on sandboxes in Chapter 3.1. For now: even in a live loop, cycle in a place you can discard.

Check your understanding

Quick check

—

You start a live loop that says "keep rewriting this section until the reviewer approves." Ten minutes and eight cycles later, cycles 6, 7, and 8 have produced nearly identical output and the reviewer keeps rejecting for the same reason. What is the correct move?

1. AWait patiently for cycle 9 — the model may still find the answer.
2. BStop the loop. Three cycles with no new information means the loop is stuck; the fix is a change to the prompt, the reviewer criteria, or the input — not more cycles.
3. CKill your terminal and start again from cycle 1.
4. DTrust the loop and let it run overnight.

Check answer→