Decision guide

This is the working page. If you only read one part of this section, read this one. It takes the six jobs from the field guide, Which Loop Do You Need?, and turns them into a table you can hold against your own work, plus the three decisions that decide whether any loop is trustworthy, plus a routine you can run with your team this week.

---

Which loop for which job

Start with the shape of the task, not the tool. Find the row that matches what you are trying to delegate.

The job	Task shape	Pattern	Key knobs
Write the investor update	Iterative polish against criteria you can articulate	Evaluator-optimizer with a written rubric	A separate grader; a rubric written in advance; a bounded number of revision rounds
Fix this bug	Deterministic pass/fail exists	Goal-met loop on a deterministic check	The test (not an opinion) is the check; run to green; cap the rounds; check the real outcome, not a proxy
Build this feature	Non-trivial, must be right, no single test covers it	Plan → build → review with cross-model review	A different model reviews than the one that built; a clear “no showstoppers” stop bar; cap the rounds
Redesign the website	Judgment-shaped, no ground truth for “better”	Judge panel, human keeps the veto	An odd number of diverse jurors; the panel advises, your taste decides
Clean up the backlog	A stream of similar items	Loop-until-dry over an externalized queue	The queue lives outside the agent; dedup keys; stop on “empty, or N items done”
Keep it running without me	Should run on a schedule, unprompted	Time-recurring automation wrapping one of the above	A schedule; a hard cost budget; surface only what actually needs you

Two more worth knowing

Two rows sit underneath every job above. If the output crosses a trust boundary (a shared workspace, a client, production), wrap it in shadow-then-promote: do the work in a staged copy and gate the promotion on a human, default-deny. And if the task is simple enough that one good prompt would do it, do not build a loop at all. Loop machinery only earns its keep when it demonstrably pays.

---

The three decisions that dominate the rest

Underneath the specific pattern, three decisions determine whether a loop is something you can walk away from or something quietly making mistakes unattended. Answer these three for any loop before you run it.

1. What is the check, and can it be gamed? Push it toward deterministic ground truth: a test, a number, a fact that is true or false without an opinion. Where no such ground truth exists, do not let one model check itself. Diversify the checker: a different model, a small panel, your own eye at the end. The weakest check on the list is the agent grading its own work.

2. Where does state live? For anything long-running or scheduled, externalize it: files, git, a shared document, a board. The record has to be the real memory, because the agent forgets between turns and the record does not. A loop whose state lives only in a chat window dies when someone closes the laptop.

3. What stops it? Always put a budget behind the goal (never past N rounds or N dollars), and decide in advance what happens when the budget runs out before the goal is met. For low-stakes work, shipping partial is fine. For anything touching a customer, a client, or money, the rule is fixed: escalate to a human, never force-ship.

---

Running this with your team

You can run the routine below as a ninety-minute working session with a leadership or ops team. The goal is not to build anything yet. It is to get the whole team seeing their work as loops, and to leave with one loop chosen and owned.

1. List the recurring jobs you already hand to AI. Each person writes down the three to five tasks they most often delegate to a chat. Keep them concrete: “draft the weekly board update,” not “communications.”

2. Name the check for each. For every job, ask the killer question: how would you know the output is good without re-reading all of it yourself? If the answer is “I wouldn’t,” that job currently has no check, which means it is not a loop yet, it is hope. Mark those.

3. Classify each job by task shape. Use the table above. Match each job to a row by its shape (deterministic pass/fail, judgment-shaped, a stream of items, a schedule), and write down the pattern and the knobs beside it.

4. Answer the three decisions for the top one. Pick the single highest-leverage job in the room and work the three decisions for it out loud: what is the check and can it be gamed, where does its state live, what stops it and what happens when the budget runs out.

5. Assign an owner and a budget. One person owns making that loop real, with a spend cap and a review date. One loop, owned, is worth more than ten loops discussed.

6. Review at the boundary, not continuously. Agree as a team that these loops report at checkpoints and escalate on budget exhaustion, so nobody is stuck babysitting a progress bar. The point of the loop is to buy back attention, not to spend it watching.

The test of a good loop

A loop is working when the person who owns it can go into a half-day of deep, uninterrupted work and come back to a short list of decisions that genuinely needed them, not to a pile of output they now have to read in full. If they still have to read everything, the check is not doing its job yet.

---

Read the field guide Which Loop Do You Need? The six jobs above, told as a narrative, with the failure mode to watch on each.

Pattern taxonomy The full definition of each pattern in the table, with its axes and failure modes.