Loop Engineering: From Prompt to Loop
Stop prompting the agent a hundred times. Design the system that prompts it, checks its work, and runs until the goal is met.
The next level of abstraction
A single prompt asks the model to be right on the first try. A loop lets it be wrong cheaply and converge. The work changes from "write the answer" to "design the system that gathers context, acts, verifies, and repeats until done."
Boris Cherny, the creator of Claude Code: "I don't prompt Claude anymore. I have loops that are running — they're the ones prompting Claude. My job is to write loops." The field moved in steps: prompt engineering → context engineering → harness engineering → loop engineering. Each step is a level up in abstraction.
Why it works: models are statistical and degrade as their context fills (quality measurably drops past roughly 100k–150k tokens). A loop with fresh context each pass forces self-review — the first iteration is good-but-flawed, and a later pass catches what it missed.
A loop is a queue with a stop condition
The most useful mental model isn't a process spinning forever. It's a backlog of tasks, pulled one at a time by an away-from-keyboard worker, until the queue is empty. An "infinite loop" that grabs the top open ticket, does it, and exits is just a worker draining a queue.
A folder of numbered tasks — 001, 002 — each one feature or fix the worker can pick up.
Pull one task, implement, verify, commit, exit. The loop stops when the backlog is empty — that's the stop condition.
Each task gets a fresh context window in the model's "smart zone," instead of one bloated session that degrades.
Framing it as a queue makes the right questions obvious: what's the priority, what happens to a poisoned task, and where do humans gate the flow.
When should you build a loop?
Not for everything. Run a candidate task through four gates — build a loop only if all four pass.
A unit of work done over and over (tickets, slices, files). A one-time task is just a prompt.
A crisp, objective completion signal — tests pass, coverage hits X, queue empty, build green. If you can't define done, you can't safely loop.
Cost per iteration × expected iterations is within a budget — and there's a hard cap. A loop prompts itself, so it can burn tokens.
The agent can both act (edit, run, commit) and verify (run the tests/linter/judge) inside its sandbox.
You're closer than you think
Loop engineering isn't exotic. A scheduled job that scans a source each day and reports only what's actionable is a loop. A pipeline that turns a code issue into a reviewed pull request is a loop. The skill is naming the parts so you can build them on purpose instead of by accident — which is exactly what the rest of this track does.
A big agent count is a vanity metric. The real number is merged, verified work per day — with you gating only the few decisions that actually matter. A loop you can't verify isn't leverage; it's a faster way to ship slop.
Check yourself
Recall beats re-reading. Three quick ones.
You're deciding between one big careful prompt and a loop for a repeating task.
What's the core advantage of the loop?
Someone says "an agentic loop is a process that just runs forever."
The better mental model is…
A task repeats, is cheap, and the agent has all its tools — but you can't define what "done" looks like.
Which condition fails?
You know what a loop is and when to build one. The next lesson takes one apart — the four building blocks every working loop needs.