The prompt is one line.
The loop is the product.
An AI agent is a model running in a loop: act, observe, check, repeat. Whether it finishes the job, gives up sensibly or burns your budget depends on how that loop is built. This course teaches you to engineer the loop: checkable goals, honest feedback, durable memory and hard stops.
What is loop engineering
- Describe an agent as a model in a loop
- Tell prompt engineering and loop engineering apart
- Decide when a loop beats a single call
A single model call answers once. An agent is a model called over and over in a loop. Each time round, it looks at its context, picks an action (usually a tool call), sees the result, and decides whether it's finished.
Almost everything that makes an agent reliable or unreliable lives in that loop, not in the wording of the prompt. What counts as finished? What does it see after each step? What is it allowed to do? When does it give up? Loop engineering is designing those answers on purpose.
Prompt engineering
- Shapes the wording of one request
- Judged by reading one output
- Fails by being vague
- Fix: rewrite the prompt
Loop engineering
- Shapes goal, tools, feedback and stopping
- Judged by success rate over many runs
- Fails by never finishing, finishing wrong, or doing damage
- Fix: change the part of the loop that failed
When a loop is worth it
Loops shine when the result can be checked automatically and first attempts are often wrong: making tests pass, fixing a broken build, migrating an API across hundreds of files, cleaning data against a validator. They're a poor fit for one-off answers, judgement calls with nothing to check, and anything where each attempt has side effects you can't undo.
Anatomy of a loop
- Name the five parts of every agent loop
- Trace a misbehaving loop to the part that caused it
Every agent loop, from a one-line shell script to a multi-agent system, is built from the same five parts. Leave one out and you get a predictable failure.
| Part | Question it answers | Failure when it's missing or weak |
|---|---|---|
| Goal & done check | What does "finished" look like, in a form a program can check? | Stops too early ("looks done") or never stops |
| Context | What does the agent know at the start of each iteration? | Repeats mistakes, forgets decisions, drowns in old output |
| Tools | What is it able to do? | Can't act (too few) or acts dangerously (too many) |
| Feedback signal | How does it learn whether the last action worked? | Confidently wrong; "fixes" that break something else |
| Stop conditions | When does it give up, or hand over to a human? | Runs forever, burns budget, repeats the same error |
When a loop misbehaves, name the part before changing anything. The instinct is to rewrite the prompt, but most failures are a weak done check, a noisy feedback signal, or a missing stop condition.
Unlock the full course
You've finished the free preview. The rest of the course is the engineering: done checks that can't be gamed, feedback that teaches, memory that survives, guardrails that hold, and how to measure whether any of it works.
- 7 more modules, including loop specs, the fresh-context ("Ralph") loop and multi-agent patterns
- 2 interactive labs: loop spec builder and a convergence simulator
- Loop review checklist and a 12-question final assessment
Secure payment through Stripe. After you pay you'll get a personal access link. Bookmark it to open the course on other devices. Sold separately from the Spec-Driven Development course.