source · ingested Jul 12, 2026 · updated Jul 12, 2026

Loop engineering: Getting started with loops

Delba de Oliveira, Michael Segner published Jun 30, 2026 #claude-code#loop-engineering#agent-loop#verification#token-usage
Original article: claude.com/blog/getting-started-with-loops · Ingested copy: raw/2026-07-12-loop-engineering-getting-started.md

An anthropic Claude Code team post that pins down the buzzword “loop engineering” with a working definition — loops are agents repeating cycles of work until a stop condition is met — and a four-type taxonomy classified by how a loop is triggered, how it is stopped, which claude-code primitive drives it, and what task each fits. The post is the vendor’s own articulation of the progression from prompting single turns to designing systems that run without a human in real time, plus the operating discipline (code quality, token budgets) that keeps such systems safe to leave running. Distilled to a concept page at loop-engineering.

Source file: raw/2026-07-12-loop-engineering-getting-started.md. Three diagrams rehosted; each carries detail absent from the prose: the turn-based diagram states the loop “exits when Claude judges the task complete — or the effort budget runs out” (linking loop termination to the effort setting); the /goal diagram shows the evaluator-model cycle (Claude tries to stop → evaluator checks the condition → sent back to work or loop ends); the proactive-loop diagram shows the full cloud composition (/schedule watches Slack/GitHub → main agent loops until the verification skill passes → opens a PR → second agent reviews and notifies → you decide what to merge).

Summary

The taxonomy

LoopTriggered byStops whenYou hand offReach for
Turn-basedA user promptClaude judges the task complete or needs contextThe checkCustom verification skills
Goal-basedA manual promptGoal achieved OR max turns reachedThe stop condition/goal
Time-basedA time intervalYou cancel, or the work completes (PR merges, queue empty)The trigger/loop (local), /schedule (cloud)
ProactiveAn event or schedule, no human in real timeEach task exits at its goal; the routine runs until turned offThe promptAll of the above + dynamic workflows
  • Turn-based is the base agentic loop every prompt starts: gather context → take action → check work → repeat → respond. Improve it by encoding your manual checks as a SKILL.md (claude-skills) with tools that let Claude see, measure, or interact with the result — the more quantitative the check, the easier the self-verification. The post’s example skill (verify-frontend-change) mandates dev-server + browser interaction, before/after screenshots, zero console errors, and a Chrome DevTools MCP performance trace before any UI change may be declared done.
  • Goal-based (/goal) externalizes the stop condition: an evaluator model checks the user-defined success criterion each time Claude tries to stop, and sends it back until the goal is met or the turn cap is hit. Deterministic criteria (tests passed, score threshold) are most effective — Claude no longer decides what “good enough” means. Example: /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
  • Time-based (/loop, /schedule) re-runs a prompt on an interval — for recurring work or polling external systems (a PR receiving reviews, failing CI). /loop runs on your machine and dies with it; /schedule (research preview) moves the routine to the cloud.
  • Proactive composes the primitives — /schedule + /goal + skills + dynamic workflows (research preview, orchestrating agents at scale) + auto mode (no permission stops) — into event-driven work with no human in real time: bug-report triage, migrations, dependency upgrades.

Maintaining quality

The quality of a loop’s output depends on the system around it: keep the codebase clean (Claude follows existing patterns), give Claude self-verification (claude-skills, verifier-loop), make docs reachable, and use a second agent with fresh context for code review — less biased, not influenced by the main agent’s reasoning. When an individual result misses the bar, encode the fix into the system rather than just patching the instance.

Managing token usage

Loops need boundaries: right primitive and model for the job; specific success/stop criteria; pilot before large runs (dynamic workflows can spawn hundreds of agents); scripts for deterministic work (a form-filling script beats re-deriving the code every run); intervals matched to how often the watched thing changes; and inspection via /usage, bare /goal (turns + tokens so far), and /workflows (per-agent usage, stoppable). Model and effort choices (2026-07-12-claude-model-effort-level) are called “among the biggest levers on what a loop costs.”

Key claims

  • Definition: loops are agents repeating cycles of work until a stop condition is met; types differ by trigger, stop criteria, primitive, and task fit. (loop-engineering)
  • Every prompt already starts a manual turn-based loop — “the agentic loop” — with the human directing each turn. (agent-loop)
  • With /goal, an evaluator model checks the user’s condition each time Claude tries to stop; deterministic criteria are the most effective. (verifier-loop)
  • Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.
  • A second reviewing agent with fresh context is less biased than the main agent reviewing itself. (ralph-wiggum-loop, multi-agent-orchestration)
  • Running a script is cheaper than reasoning through the steps each time. (claude-skills)
  • The advice loop for adopting loops: pick a task where you are the bottleneck, ask which piece you can hand off (the check? the stop condition? the trigger?), run it, observe where it stalls or over-reaches, iterate.

Notable quotes

We define loops as agents repeating cycles of work until a stop condition is met.

When an individual result doesn’t meet the standard, don’t stop at fixing the individual issue, try to encode it to improve the system for all future iterations.

Open questions

  • /goal’s evaluator model is unspecified. Which model evaluates the stop condition, what it costs per check, and whether it can be steered or fooled (a graded channel invites reward-hacking) is not covered.
  • Dynamic workflows and /schedule are research previews — surface area, orchestration semantics, and pricing may shift; the post’s composition example is aspirational rather than documented behavior.
  • The taxonomy’s provenance. The post positions this as the Claude Code team’s answer to a contested X-discourse term; whether the four-type frame stabilizes as the community taxonomy or stays vendor-specific is worth tracking.

Pointers

  • loop-engineering — the concept page distilled from this source: the taxonomy, the hand-off framing, and how it maps onto the wiki’s existing loop pages.
  • agent-loop — the base cycle the turn-based loop names; this source is the vendor’s productization of the patterns that page catalogs.
  • verifier-loop/goal’s evaluator model is a productized verifier; verification skills are acceptance criteria bound up front.
  • ralph-wiggum-loop — the second-agent-review advice is the same fresh-context insight that pattern runs to completion.
  • claude-code — the loop primitives (/goal, /loop, /schedule, dynamic workflows, auto mode) are new product surface recorded on the entity page.
  • 2026-07-12-claude-model-effort-level — companion post, cross-linked from the token-usage section.

Referenced by 10

2026-07-12-claude-model-effort-level harness-why-it-matters-now agent-loop claude-skills loop-engineering model-and-effort-selection ralph-wiggum-loop verifier-loop anthropic claude-code
esc