Anatomy of a Loop
Every working loop has four building blocks. Get all four right and the loop runs itself; miss one and it burns tokens producing garbage.
The four building blocks
A loop isn't one thing — it's four parts working together. Name them and you can build deliberately instead of hoping.
What starts the loop — an interval, a schedule, an event, or a single command you invoke.
The battle-tested skills that do the actual work. The most important block.
What you want, and the rule that confirms you got it. Inseparable.
What it produces, and the notes that let it improve next time.
Block 1 — the trigger
What fires the loop. Three patterns, increasing in power:
Run every N minutes/hours (/loop). Simple, but it runs on your machine — close the laptop and it stops.
Fire on a clock in the cloud (/schedule, a crontab, a systemd timer) — for unattended overnight or recurring work.
A single command that bundles goal + verification + memory + budget. Invoke it by name; don't re-wire a loop each time. The highest-leverage trigger.
Events count too — an issue opened, a file landing, a webhook arriving can all fire a loop.
Block 2 — execution skills (the important one)
A skill is a saved set of instructions that lets the agent run the same thing the same way every time — like a prompt you've saved. The orchestration skill runs the whole loop; execution skills are the specialized jobs it calls to do the work.
Skills encode how you specifically want a task done. Without an "analyze workout" skill, the agent says "it's raining, cancel your run." With one that knows you love running in the rain, the answer flips. This is skill-driven loop development: only loop over work you've already proven by hand.
Practical consequence: before you automate a task into a loop, do it manually a few times and capture the steps as a skill. The loop is only as good as the skills under it.
Blocks 3 and 4 — done right or not at all
The last two blocks are where most loops quietly fail, so each gets its own lesson next. The preview:
You can't have a goal you can't verify. The goal says what to do; the verification is the rule that confirms it — and the agent must not be able to satisfy it by writing a confident summary.
The output is obvious (a doc, a PR, a live site). The part everyone misses is memory: a place the loop writes notes so the next pass is better instead of repeating the same mistake.
A good loop scaffolder bundles all four blocks for you — trigger, skills, goal + verification, and a budget cap with a dry run — so invoking one command stands up a correctly-shaped loop rather than wiring it from scratch.
Check yourself
Three on the building blocks.
You want a loop to make decisions the way you would, not generically.
Which building block carries that?
You want to invoke a fully-configured loop by name instead of rebuilding it every time.
Which trigger pattern is that?
You're tempted to set a goal and let the loop self-report when it's "done."
What must the goal be paired with?
Blocks 3 and 4 are where loops live or die. The next lesson goes deep on verification and memory — the heart of the whole thing.