Chapter 01 · Section I · 8 min read
1.1 From prompting to looping
The shift most people miss — from writing one clever prompt at a time to designing a loop that runs your prompts for you, sometimes while you sleep.
Prompting is a conversation. You write, the model answers, you write again. Looping is a system. You write once, and the same shape of work runs by itself — sometimes for hours, sometimes on a schedule, sometimes forever. The gap between the two is not just size. It’s a different job.
The two modes side by side
Prompting. You are the loop. You type, the model responds, you decide what to type next. Your judgement is in every step. If you go make tea, everything stops.
Looping. You define the shape once — what to do, when to do it, what counts as done, what to hand off to a human — and the system runs that shape without you. Your judgement is in the design, not in every cycle.
Almost every prompt-engineering skill you know still matters inside a loop. What changes is where the leverage sits. Before, it sat in the prompt you wrote. Now, it sits in the loop you built.
What “the loop” actually means here
We’re not talking about a for loop in code, though the shape is similar. We’re talking about a running system with:
- A trigger that fires the next cycle (a keypress, a timer, an event).
- A cycle that does the work (reads context, calls tools, produces output, checks itself).
- Memory that carries state from one cycle to the next.
Every agent you’ve ever used — from a shell assistant that keeps trying until the tests pass, to a scheduled job that files your morning inbox — is some version of this shape.
Why the shift matters now
Three things converged to make loops practical:
- Models got reliable enough to trust. A model that fails 40% of the time is a bad loop; every cycle amplifies error. Models that fail 4% of the time make loops useful — you can catch the 4% with a review step and ship the rest.
- Tools got standard enough to compose. File I/O, shell access, web requests, database calls, API integrations — these are increasingly “one config away” rather than “one custom integration away.”
- Cost dropped enough to iterate. Running a hundred cycles used to be a serious expense; now, for most tasks, it’s the price of a coffee. That changes what’s worth building.
What stays the same
Two things do not move up the stack when you switch from prompting to looping:
- Intent. What the loop should do — and, just as importantly, what it should not do — is your call. A loop with no clear intent produces impressive-looking output at speed. That’s the worst of both worlds.
- Accountability. When the loop ships a wrong summary, updates the wrong record, or emails the wrong customer, the answer to “who’s responsible?” is you. The loop is a machine you designed; it does not carry blame.
We come back to these two in Chapter 6. For now, remember: the loop can carry a lot of work, but it cannot carry these two.
Where this course is going
You’ll spend the rest of Chapter 1 on the six parts every real loop has, and the two flavours of tools you can build one with. Chapter 2 covers when the loop fires. Chapter 3 covers what happens in each cycle. Chapter 4 is memory. Chapter 5 is a complete worked example, twice. Chapter 6 is the discipline that keeps a loop useful instead of dangerous.
By the end you should be able to look at a task in your work and know, in about thirty seconds, whether it wants a prompt, a loop, or neither.
Check your understanding
Quick check
—