Track map
Detailed content
🪜 The decision ladder
Before building any loop, run the task up a two-question ladder. Most don’t make it up—and that’s fine.
Before building, run the task through two questions; only build a loop if the answer is YES on both steps.
Saves hours of engineering on tasks a simple prompt could already handle.
Decision ladder; YES/YES; one-shot.
If the task is a predictable step, just prompt; one-shot is faster and cheaper.
A loop exists to outsource repetition, not to dress up a one-off task.
Repeated × one-off; many unknown steps.
Can the AI verify that it's finished (run tests, count words)? If not, do it yourself.
Without this check, the loop won't converge — it stops too soon or never stops.
Automated check; fix the objective first.
Nate Herk: “most tasks don’t need a loop”; when they do, it’s for verification.
Saves you from building a huge architecture when a terminal + a good prompt would have been enough.
Loops cost money; start small.
Firecrawl: loops deliver more on repetitive, reviewable, high-value tasks—not everything.
Gives you the ✓/✗ grid to distinguish good from bad loop candidates.
Reviewable; all three criteria together.
Fixing tests → loop; rewriting 1 email → prompt only; broad research → depends on checking.
Trains the reflex to apply the ladder before you start building.
Objective × subjective criteria.
🧩 The 3 types of loop
Decided it’s worthwhile? There are only three forms — they differ in the number of agents involved and who checks whose work.
An agent goes through reason→act→observe and repeats; the "model + tools" from Trail 1.
It's the easiest to build and debug, and it covers most of the work. Start here.
Think→Act→See; fewer parts, fewer bugs.
One agent does the work, a second (fresh AI) scores it; the creator doesn’t sign off on their own work.
It's the “observe/check” beat with a dedicated agent; step up to this when quality matters.
Maker; checker; fix until it passes.
A lead splits up the goal and assigns pieces to subagents that run in parallel.
It works when the job is too big for a sequential workflow.
Sub-agent; fan-out; parallelism.
It's any of the three forms left unsupervised — not a new form.
It's the setup that most needs a strong STOP (turn limit, human gate).
Autonomy; stop condition; supervision.
Start with Solo; move up to Maker→Checker for quality, or Manager→Helpers for scale.
Extra complexity is a cost—only scale up when an agent really can’t handle it.
Gradual escalation; cost by form.
Solo: fix a test; Maker→Checker: thumbnail + scorer; Manager→Helpers: audit 45 sources.
Anchor each form in a real case + a copyable maker→checker prompt.
Dedicated scorer; copy-run.
🏁 Define and check “done”
A loop is only as good as its finish line. Lock down "done" and choose from the 4 types of checks.
Before running, define what “done” means (something a machine can read) + how you’ll check.
These two answers ARE the loop’s “done?” check—the stopping mechanism.
Finish line; the 4 types of checks.
A machine answers yes/no: tests pass, app runs, build compiles.
It's the easiest and most reliable check — start with it whenever you can.
Green/red; binary check.
When the result needs to be SEEN to be judged: UI, thumbnail, layout.
Most agents can view images / take screenshots and judge the pixels.
Screenshot; look at the pixels, not the code.
It takes taste, but you can write a rubric; a second agent scores against it.
The "until you're satisfied" trap is too subjective — make it objective ("until the metric = Y").
Rubric; make taste objective.
Irreversible or purely a matter of taste that no rubric can capture: the loop pauses, you approve, and it continues.
It's the right check for risky steps — one-way doors.
Human gate; one-way door.
The more objective "done" is, the better the loop: it gets a number to pursue.
Real example (Nate): Abbey Road in CSS, stopping at score ≥ 9 OR after 8 passes (hard cap).
Metric; iteration cap; screenshot + reassess.