On July 7, 2026, Anthropic published an official Loop Engineering guide on the Claude blog (claude.com/blog)—"Getting Started with Loops," authored by Delba de Oliveira and Michael Segne. This is Anthropic's first formal taxonomy of loop types, engineering practices, and code quality guidelines since Boris Cherny (head of Claude Code) said six weeks earlier: "I don't prompt Claude anymore, I write loops." The core is a four-way classification—turn-based, goal-based, time-based, proactive—and one principle that runs through everything: the quality of a loop's output depends on the system around it, not the model itself.
This article complements our earlier "When Loop Becomes the Engineering Unit"—that piece covered architectural layers and cybernetic mapping; this one dissects the official guide's specific tools and engineering practices.
The Classification Logic: What You Hand Off
The guide's core is four loop types. The axis is not increasing complexity, but what control you surrender to the machine:
| Loop Type | Trigger | Stop Criteria | Best For | Claude Code Tool |
|---|---|---|---|---|
| Turn-based | User prompt | Claude judges completion | Short, non-recurring tasks | SKILL.md self-verification |
| Goal-based | Manual prompt | Goal achieved or max turns | Tasks with verifiable exit criteria | /goal |
| Time-based | Time interval | You cancel or work completes | Recurring work, external systems | /loop, /schedule |
| Proactive | Event/schedule, no human | Each subtask exits on goal | Continuous streams of well-defined work | All above + dynamic workflows |
Turn-based: Encoding Verification as a Skill
Every prompt is a loop. Claude reads code, edits files, runs tests, hands back something it believes works—you then manually check and write the next prompt. This is turn-based loop, the default mode everyone uses.
The guide's key upgrade: encode your manual checks as SKILL.md. Not "ask Claude to check"—but write a structured verification procedure with tools and connectors that let Claude see, measure, and interact with results.
The guide provides a complete SKILL.md example:
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input,
toggle): click it, confirm the expected state change, and screenshot
before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 — do not hand
back partially verified work.
Note the last line—"do not hand back partially verified work." This is not a suggestion; it's a hard constraint. SKILL.md defines not just a checklist, but Claude's behavioral boundary.
The more quantitative the checks, the more reliable Claude's self-verification. "Check performance" is ambiguous. "Run Chrome DevTools performance trace, audit Core Web Vitals" is quantitative. Quantitative checks can be reliably executed; ambiguous ones cannot.
Goal-based: Deterministic Stop Conditions
When you know exactly what "done" looks like, define a goal and let Claude iterate:
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
Architecture: each time Claude tries to stop, an independent evaluator model checks the goal condition—if unmet, it sends Claude back. Claude cannot decide on its own that "it's good enough."
The guide explicitly states why deterministic criteria outperform fuzzy ones:
"This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective."
Test pass counts, score thresholds—these can be checked without ambiguity. "Make the code better" cannot.
stop after 5 tries is not a suggestion; it's a fuse. A goal-based loop without max turns is a potential token incinerator that never stops.
Time-based: Match Interval to Change Frequency
/loop 5m check my PR, address review comments, and fix failing CI
/loop runs locally—turn off your computer and it stops. /schedule runs in the cloud—independent of your machine.
The guide offers a key principle in its token management section: "Don't run routines more often than you need to: Match the interval to how often the thing you're watching changes."
Average PR review response time ranges from minutes to hours. Checking every 5 minutes may be too frequent. But if your CI runs every 2 minutes, a 5-minute check makes sense.
Proactive: Composed Systems
The most aggressive form. The guide's full example:
/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions
in parallel worktrees and have a judge adversarially review them.
Four primitives composed:
/schedule(research preview) provides time-based triggering/goalprovides stop conditions- dynamic workflows orchestrate multiple agents (triage, fix, review)
- auto mode lets the routine run without stopping to ask
The guide's token management advice for proactive loops: "Pilot before a large run: Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice of the work first."
Code Quality: Four Principles
The guide's "Maintaining code quality" section deserves line-by-line analysis. Its core thesis: loop output quality depends on the system around it. Four specific principles:
1. Keep the codebase itself clean. Claude follows patterns and conventions already in the codebase. If the codebase is messy, loop output will be messy—the loop amplifies existing patterns, for better or worse.
2. Give Claude a way to verify its own work. Encode what "good" looks like using skills. This directly echoes the SKILL.md from turn-based—not letting Claude guess what you want, but stating it explicitly.
3. Make docs easily reachable. Framework and library docs contain up-to-date best practices. Claude can follow what it can read; for what it can't, it relies on training data (potentially stale). In practice: place key dependency docs where MCP servers or CLAUDE.md can reference them.
4. Use a second agent for code reviews. A reviewer with fresh context is less biased than the main agent checking itself—it's not influenced by the main agent's reasoning chain. The guide mentions the built-in /code-review skill or Code Review for Github.
A fifth principle is implicit: "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." Don't just fix the bug—encode the fix into the system to improve all future iterations.
Token Management: Seven Levers
The guide's "Managing token usage" section is the most actionable passage. Seven specific levers:
| Lever | Description |
|---|---|
| Choose the right primitive and model | Small tasks don't need multiple agents or loops. Some tasks can use cheaper, faster models |
| Define clear success and stop criteria | The more specific "done" is, the faster Claude arrives—but not too fast |
| Pilot before a large run | Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice first |
| Use scripts for deterministic work | Running a script is cheaper than reasoning. A PDF skill can ship a form-filling script instead of re-deriving the code each time |
| Don't run more often than needed | Match the interval to how often the watched thing changes |
| Review usage | /usage breaks down by skills, subagents, MCPs; /goal shows turns and tokens; /workflows shows per-agent token usage |
| Model and effort level | "Your model and effort level choices are among the biggest levers on what a loop costs." |
The last one—model and effort level—is the biggest cost lever. A proactive loop's routine parts (fixed-flow triage, formatting, routing) can use a small model; only judgment work (evaluation, decisions) needs a large model. The guide's advice: "Routing routines to smaller, faster models and using the most capable model for judgment calls."
Engineering Judgment
Start with turn-based, escalate selectively
The guide is explicit: "Not all tasks require complex loops; start with the simplest solution and use these patterns selectively."
Upgrade path: daily development stays turn-based with encoded verification skills → when a task makes you think "I'm repeating myself," upgrade to goal-based → when you find yourself doing the same thing at fixed times, upgrade to time-based → only when you have a clear continuous workflow should you go proactive.
Stop conditions determine loop quality
A loop's quality depends not on speed or model capability, but on whether the stop condition can be reliably checked.
Worst: ambiguous ("make the code better"). Medium: rule-based but fragile ("lint passes"—doesn't cover logical correctness). Best: deterministic and quantifiable ("all tests pass + Lighthouse ≥ 90 + bundle size ≤ 200KB").
If your stop condition is hard to write well, don't use goal-based—use turn-based and let humans do the final verification.
Evaluator and executor must be separated
Anthropic's goal-based loop uses an independent evaluator model—not Claude judging whether it's done itself. The same agent executing and evaluating produces confirmation bias. An independent evaluator checks against preset conditions without relying on the main agent's self-assessment.
Composed loop reliability is a product, not an average
A proactive loop looks like /schedule + /goal + workflow + judge stacked together. But composed system reliability is the product of component reliabilities. Using a simple series model estimate, four 90%-reliable components combine to ~65%. In practice, the schedule and goal layers have some redundancy, and fixed flows (triage) can run in degraded mode, so actual reliability is usually higher than the product estimate—but design should still assume series as the floor.
Encode fixes into the system
When a loop produces substandard output, don't just fix the individual issue—encode it into SKILL.md or the stop condition to improve all future iterations. The guide's words: "don't stop at fixing the individual issue, try to encode it to improve the system for all future iterations."
Sources & Disclaimer: This article is based on the complete public content of Anthropic's official blog post "Loop engineering: Getting started with loops" (claude.com/blog/getting-started-with-loops, July 7, 2026, authored by Delba de Oliveira and Michael Segne), with additional reference to Anthropic's "Build Agents That Run for Hours" workshop (Ash Prabaker & Andrew Wilson, May 2026), Addy Osmani's "Loop Engineering" blog post (June 2026), and Boris Cherny's public interviews. Not investment advice. Anthropic guide content referenced herein is current as of July 12, 2026.