1.2 Anatomy of a loop

The six parts

1. Trigger. What starts each cycle. A keypress, a timer, a webhook, a file appearing on disk. Different triggers give different degrees of independence from you.

2. Sandbox. Where the cycle runs — a scratch directory, a container, a git worktree, a virtual machine — such that one cycle can’t step on another and a mistake can’t destroy your real files. Isolation is a prerequisite for anything unattended.

3. Reusable knowledge. The stable context every cycle needs: your conventions, your directory map, your product’s specific rules, the current playbook. Without this, every run rediscovers the same facts from scratch and wastes tokens on things that should be pre-loaded.

4. Tools. The verbs the loop can use to affect the world — read a file, run a command, hit an API, post a message. Without tools the loop can suggest; with tools the loop can do.

5. Do-and-verify. The separation between the part that produces work and the part that checks it. Usually two model calls or two roles inside one system: an “actor” that acts, and a “reviewer” that grades. The reviewer catches most single-model failures.

6. Memory. What survives between cycles. Yesterday’s decisions, running tallies, half-finished work, notes for tomorrow. Without memory the loop is amnesiac — every run starts from zero and can never build on the last.

A pocket picture

A loop that fails to start is missing the trigger. A loop that corrupts files is missing the sandbox. A loop that keeps re-explaining your own project to itself is missing reusable knowledge. A loop that produces reports but can’t file them is missing tools. A loop that confidently ships wrong output is missing do-and-verify. A loop that forgets what it decided yesterday is missing memory.

Six failure modes, six fixes. Everything in this course is one of these six.

What each cycle looks like

Zoom into a single cycle and you see the same shape every time:

1. Trigger fires  →  new cycle begins
2. Load reusable knowledge into context
3. Load relevant memory (what happened last time)
4. Do the work — with tools available
5. Verify the work — a separate step, not the same actor
6. Update memory with what happened
7. Wait for the next trigger

Chapter 2 is step 1. Chapter 3 is steps 2–5 (sandbox, knowledge, tools, do-and-verify). Chapter 4 is steps 3 and 6 (memory). Chapter 5 walks a complete cycle end to end.

Why six, not four or eight

You could plausibly collapse reusable knowledge and memory into one “context” bucket — but they behave differently. Reusable knowledge is stable and shared across runs; memory is dynamic and updates each cycle. Treat them the same and you either can’t share knowledge across projects, or you can’t persist state at all.

You could also split tools into read-tools and write-tools, or split do-and-verify into two separate agents. Those refinements come later. Six parts is the smallest set that keeps every failure mode visible.

Skip the ones you don’t need — carefully

A shell alias that re-runs pytest until it passes is technically a loop. It has a trigger (your keypress), no sandbox (it just runs in your repo), no reusable knowledge, one tool (pytest), no verifier separate from the actor, and no memory. It works because the stakes are low and you’re watching.

The moment you take your eyes off it — schedule it, delegate it, run it in parallel — the missing parts become bugs. That’s the pattern for the rest of the course: when you promote a loop from “I’ll watch it” to “I’ll leave it running,” you have to add the parts you skipped.

Check your understanding

Quick check

—

Your loop runs a nightly job that summarises the day's new customer tickets. In the morning you notice the summary confidently invents ticket IDs that don't exist. Which of the six parts is most likely missing or broken?

1. AThe trigger — the schedule is misconfigured.
2. BThe sandbox — cycles are colliding with each other.
3. CDo-and-verify — there is no separate check step catching the hallucinated IDs before the summary ships.
4. DThe reusable knowledge — the loop does not know your company's conventions.

Check answer→