Learn · ~7 min

Pick the right kind of loop

Match your job to a loop shape — and know each shape's built-in failure before you sign up.

Most people pick a loop by reaching for the technology they already run (a cron, a framework, a coding agent). The more useful order is to start from the trigger and the blast radius: what starts the loop, what can it touch, what does "done" look like, who checks it. This guide is the selection layer on top of the pattern cheat sheet, which lives in the glossary pattern cheat sheet. This guide does not reproduce that table — it tells you how to read it.

For agents: - To select a template, fetch /registry/index.json and match your goal against each entry's purpose and triggers fields. - Consult /learn/glossary#pattern-reference for the pattern → risk → verification mapping. - Do not select a pattern whose human_gates you cannot honor; a gate you cannot staff is a defect, not a feature. - Every pattern has a characteristic failure — read the "Key risk" column before the "What it does" column. - When in doubt, prefer the deterministic outer loop with adaptive inner steps over a fully open agent.

How to choose

Start from the trigger and the blast radius, not the technology. Ask four questions, in order:

  1. What starts it? A schedule, an event (CI failure, new issue), or an open-ended user goal. The trigger tells you whether you need a watchdog, a CI-repair loop, or a plan-execute-verify loop.
  2. What can it touch? Read-only web, your repo, a production system, someone's inbox. The blast radius decides your permissions and your gates.
  3. What does "done" look like? A green test, a cited findings report, a merged PR, a human's approval. "Done" is your verification contract.
  4. Who checks it? You, a reviewer, a deterministic check, nobody. If the answer is "nobody," you do not yet have a loop — you have a schedule.

The mapping below covers the common cases. "X" is drawn from Loopmaster's first template set.

If you want to automate…Start with patternTemplate to look at
Monitor sources and turn changes into cited findings or tasksWatchdog / monitorresearch-watch
Detect failing CI, patch, rerun, PR when greenCI repairci-repair
Find stale docs, dead links, outdated claims; propose updatesContent freshnesscontent-freshness
Have an agent follow your docs in a clean env and report frictionAgent usability testagent-usability-test
Reason, call a tool, observe, repeat toward a user goalReAct / tool loop—
Decompose work, execute steps, verify against criteriaPlan → execute → verify—
Generate, critique, revise until an evaluator passesEvaluator–optimizer—

If your goal is not in this table, that is a signal — not a failure. Your first loop in 15 minutes covers the case where the right answer is "don't automate this yet."

The patterns at a glance

Each common pattern is defined in the glossary pattern cheat sheet; this section is the one-paragraph judgment layer on top of it. Reach for a pattern because its trigger and verification fit your goal, not because it is fashionable.

  • ReAct / tool loop — reason, call a tool, observe, repeat. The default for an open-ended user goal or an agent subtask. Reach for it when the next action genuinely depends on the last observation. Reach *not* for it when the steps are knowable in advance — a workflow is cheaper and more honest. Grounded in react-paper.
  • Plan → execute → verify — decompose, execute, verify against criteria. Reach for implementation, research, and ops tasks where you can state acceptance up front. The risk is a bad plan becoming expensive; mitigate with a per-step checklist.
  • Evaluator–optimizer — generator proposes, evaluator critiques, loop improves. Reach for writing, code, data extraction, plans. Reach *not* for it if the same agent would grade its own output — that is the self-evaluation trap; see How you know it worked. Grounded in anthropic-claude-cookbooks-agent-patterns.
  • Reflection / Reflexion — convert failure feedback into verbal memory for the next attempt. Reach for repeated attempts on coding or reasoning benchmarks. Reach *not* for it when there is no external reward signal — reflection without an external check can preserve bad lessons. Grounded in reflexion-paper.
  • Orchestrator–workers — planner splits work across specialists, then synthesizes. Reach for research synthesis, codebase audits, multi-file changes. The cost is coordination overhead and duplicated work; pay it only when scope isolation buys you safety. Grounded in anthropic-building-effective-agents.
  • Watchdog / monitor — poll a source and report or act on changes. Reach for schedules, feeds, logs. The characteristic failure is alert spam or stale polling; mitigate with rate limits and duplicate suppression.
  • CI repair — detect failing checks, inspect logs, patch, rerun. Reach for CI failures. Reach *not* for it when the fix would mask a root cause — green CI that hides a real issue is worse than red CI.
  • Content freshness — find outdated docs, dead links, new sources. Reach for daily/weekly content hygiene. The risk is churn and low-value edits; mitigate with source-backed diffs and a human publish gate.
  • Agent usability test — have an agent follow docs/templates in a clean environment. Reach for releases and template updates. The risk is a false pass if the environment is not actually clean.
  • Self-maintenance governor — audit the loop system itself and create improvement tasks. Reach for schedule, incident, or recurring-failure triggers. Reach *not* for it without a human-governed backlog — a loop that optimizes itself without a product signal drifts.

Key risks travel with the pattern

Every pattern has a characteristic failure, and the mitigation column is part of the choice, not an afterthought:

  • ReAct runs long or takes an unsafe action → mitigate with a tool allowlist and a step limit.
  • Evaluator–optimizer self-grades leniently → mitigate with a separate evaluator or a deterministic check.
  • CI repair masks root causes → mitigate by requiring the diff to address the failing assertion, not just silence it.
  • Watchdogs spam or go stale → mitigate with rate limits, duplicate suppression, and a "no action on empty" rule.
  • Reflection preserves bad lessons → mitigate with external reward signals and stale-memory pruning.

Choosing a pattern means signing up for its risk. If you cannot staff the mitigation, do not pick the pattern.

Blended systems are the norm

Real deployments wrap adaptive inner steps in a deterministic outer workflow. A coding agent might run as a ReAct loop inside an outer plan-execute-verify workflow, inside an outer CI trigger. Purity is not a goal; the outer deterministic loop is what makes the inner adaptive steps safe to run unattended — it is where stop conditions, budgets, and gates live. When you read a pattern in the glossary, ask which layer of the stack it describes.

When not to automate

Some tasks should stay human until a verification story exists:

  • Judgment-heavy tasks where "good" is a matter of taste or product direction.
  • Irreversible actions — deleting user data, spending money, changing credentials — that should be proposed, not done.
  • Credential-broad tasks that need scopes beyond what the loop's job requires.

"Don't automate this yet" is a valid recommendation this site will give. A loop that opens a PR *proposes* a fix; it does not *fix* until a human merges. That propose/publish distinction is the subject of When a loop must stop and ask you, and it applies to our own copy as much as to the loops we ship.

Where to go next

Sources