A model has no pull toward a goal on its own. A loop adds one: check the result, go again. That works only when a machine can tell done from not done, and a person still owns whether the goal is right. This skill decides if a task deserves a loop, designs it, and reviews it for the five ways loops fail. Once it passes, put-it-on-a-loop schedules it.
When to use
- Handing a repeating task to an agent that runs again and again (write, test, fix, verify)
- A loop spins, cheats, or finishes with a confident wrong answer
- Before putting any agent task on a schedule
Not for a one-off task (just do it) or a plain timer or poll.
Steps
- Gate it. Build a loop only if all four hold: the task repeats weekly or more; the check runs without a person; the token budget covers it; the agent has tools that run the work and see the result. Any miss: do it another way.
- Write the done-check: one command or comparison that answers yes or no, such as "all 96 tests pass and a change list exists". Prefer reconciling against an outside fact (a golden sample, an upstream total) over the loop's own assertions.
- Write the boundaries next to it: what the loop must not do. "Tests pass" alone invites deleting tests, so add "no test deleted or weakened, coverage not lower".
- Pick the loop type and roles. Plan writes the spec and checks, build does the work, judge runs the checks. The judge is a separate agent or CI, not the builder.
- Add damping: a retry cap (3 is a good default), a hard stop, and escalation to a person with the failure reason.
- Settle every question before launch. A running loop won't stop to ask. It guesses.
- Land in three stages: run it once by hand, then as a saved skill or agent setup, then on the agent's scheduler.
- Review it against the five failure modes below. Any hit sends it back.
Rules
- A person decides if the goal is right and marks the final "done". The loop is the worker, not the acceptance officer.
- Never let a loop merge, publish, send or move money on its own. It opens the PR; a person merges.
- Build may never edit the checks it is judged by.
- An exit code beats the agent's opinion. "Looks right" is never a check.
- The more a loop rewrites its own rules, the stricter the human review before it acts.
Two levels of feedback
| Level | Owner | Job |
|---|---|---|
| Execution | the loop | Measure the distance to the stated goal and close it |
| Judgment | a person | Decide whether the goal is right, should change, or should stop |
A thermostat closes the gap to 21°C very well. It can't tell that today you want 23°C. Hand the judgment level to the machine and it races, fast and confident, toward a goal nobody questioned.
Self-check for the done-check
Read the done-check to someone outside the domain. Can they run one command and say whether it's done? If not, it isn't decidable yet.
A good goal has five parts: a machine-checkable done-check; boundaries written next to it; a fallback (retry cap, then a person); layers (the overall goal broken into checkable steps); and reconciliation over assertion where possible. "All tests pass" can be gamed by loosening asserts, faking mocks or swallowing errors. "Matches the reference total within 0.01" can't.
Loop types
| The task | Type | How it stops |
|---|---|---|
| Has a clear done test (finish a feature, process a batch) | Goal-seeking | Stops when the check passes |
| No end, keeps a state healthy (stock alert, health check) | Regulator | Never stops; acts only on change, ignores small noise |
| Watches until a condition holds (PR until CI is green) | Regulator with exit | Stops when the exit condition holds |
| Must happen at a set time | Any of the above on the agent's scheduler | The schedule fires it |
Two skeletons
Build something new: plan, build, judge.
| Role | Does | Key |
|---|---|---|
| Plan | Turns the goal into a spec plus acceptance checks | Every check is script-judgeable |
| Build | Works to the spec | Must not change the checks |
| Judge | Runs the checks on its own; pass stops, fail returns the reason to build | Separate from build, deterministic (tests, type check, reconciliation diff) |
Three failed rounds: escalate to a person.
Maintain something that exists: document-driven dispatch. The loop reads a tracking document on a timer and acts only when it changed. The document is the queue, the state and the human interface. People write the problem column; the loop writes the result column. State moves one way and never rolls back. A script's exit code is final. The loop moves an item only as far as "awaiting check"; a person marks it done.
Five failure modes
| # | How it breaks | Review question (yes is a hit, except where noted) | Fix |
|---|---|---|---|
| 1 | The goal is a correct platitude, so the loop spins and burns money | Is the exit condition vague, like "make it good"? | A yes-or-no done-check |
| 2 | "Verify" means "see if it looks fine", so the agent says fine and stops | Does the builder judge itself, or rely on "looks right"? | Independent judge, deterministic checks, exit codes |
| 3 | The gate is only "all tests pass", so the agent deletes the tests (the worst one) | Is there a done-check with no boundaries? | Boundaries next to the done-check |
| 4 | It counts on the agent asking mid-run; it won't, and runs the wrong answer to the end | Is any question left to settle at run time? | Settle every question before launch |
| 5 | The agent's instructions file and memory are bloated or stale, so the faster it loops, the more it errs | Is anyone keeping them short and current? (no is a hit) | Short, dated instructions, pruned on a schedule |
Worked example: a nightly test fixer
The ask: a loop that runs every night and fixes failing tests.
- Naive done-check: "make all tests pass". That is failure mode 3 waiting to happen.
- Fixed done-check: all tests pass, and no test file deleted or weakened, and coverage not lower, and a change list produced.
- Type: goal-seeking, retry cap 3.
- Skeleton: plan, build, judge, with CI as the independent judge.
The review then catches:
- Mode 3: without the boundary, deleting a failing test wins. The boundary closes it.
- Mode 2: if the fixer judged its own fix, it would pass itself. CI judges instead.
- Mode 4: an ambiguous fix at 2 a.m. gets a guess. Ambiguous cases are left for a person, not guessed.
- Red line: the loop opens a PR and never merges it.
Four lines of constraint separate waking up to a deleted test suite from waking up to a clean PR.
Source
Rewritten from loop-design-check in ECC by Affaan Mustafa (MIT licence, notice in LICENSE.txt), upstream commit d2ef268. The two-level feedback idea comes from Norbert Wiener's The Human Use of Human Beings (1950); plan, build, judge from Anatoli's Loops explained and Addy's Loop Engineering, as credited upstream.