Source: ai-research/claude-blog-getting-started-with-loops.md — Anthropic first-party blog post, claude.com/blog/getting-started-with-loops (published ~2026-06-30), written by Delba de Oliveira and Michael Segner. Surfaced via the 2026-07-16 claude.com/blog watchlist sweep, which flagged it as the highest-priority backlog item: a first-party Anthropic primary source for a topic the wiki previously covered only through third-party sources (Osmani, Greyling, Berman, Herk).
This is the Claude Code team’s own definition of loop engineering — arriving about three weeks after Addy Osmani’s essay named and popularized the practice publicly (2026-06-08). Where the third-party sources in this topic describe loop engineering from the outside (building blocks, primitives, economics), this post is the team that ships the primitives describing their own mental model: loops are agents repeating cycles of work until a stop condition is met, categorized by how they trigger and how they know when to stop.
Key Takeaways
- Four loop types, one spectrum of what you hand off. Turn-based (you hand off the check), goal-based (you hand off the stop condition), time-based (you hand off the trigger), and proactive (you hand off the prompt itself). Each maps onto a specific Claude Code primitive.
- Turn-based is the default, not a lesser option. Every normal prompt-response cycle is already a loop — you direct each turn, Claude gathers context, acts, checks its own work, and hands back something it believes works. The upgrade path is encoding your manual verification into a
SKILL.mdso Claude can check more of its own work end-to-end, with tools/connectors so it can see, measure, or interact with the result — the more quantitative the check, the easier the self-verification. /goalmoves the “good enough” decision out of Claude’s hands. An evaluator model — not the agent that did the work — checks the stated condition each time Claude tries to stop, and sends it back until the goal is met or a turn limit is hit. Deterministic criteria (test counts, score thresholds) work best precisely because they remove judgment calls from the loop./loopis local and ephemeral;/scheduleis durable./loopre-runs a prompt on an interval but only while your machine is on — turn it off and the loop stops. Moving a/loopinto a routine via/scheduleis what makes it survive past your session.- Proactive loops compose everything else. The example given — an hourly
/schedulethat runs a/goal-bounded triage-and-fix cycle, using dynamic workflows to explore parallel worktree solutions and adversarially judge them — is presented as the ceiling case: trigger + stop-condition + parallel exploration + review, all composed, for genuinely long-running unattended work. - The system around the loop matters more than any single run. Two operating disciplines close the post: when an individual result falls short, fix the system so future iterations don’t repeat the miss (not just the one instance); and manage token cost primarily through model/effort-level choice and clear loop boundaries, since those are “the biggest levers on what a loop costs.”
The Four Loop Types
| Loop | You hand off | Use it when | Reach for |
|---|---|---|---|
| Turn-based | The check | You’re exploring or deciding | Custom verification skills |
| Goal-based | The stop condition | You know what done looks like | /goal |
| Time-based | The trigger | The work happens outside your project on a schedule | /loop, /schedule |
| Proactive | The prompt | The work is recurring and well-defined | All of the above, and [[claude-ai/dynamic-workflows-claude-code |
Turn-based — the manual default
Ask Claude to build a like button: it reads the code, makes the edit, runs the tests, and hands back what it believes works, and you check it and write the next prompt. The post’s concrete upgrade is a worked SKILL.md example — a verify-frontend-change skill that forces a 4-step check (start the dev server and interact with the change directly, screenshot before/after, check the browser console for zero new errors, run a Chrome DevTools MCP performance trace against Core Web Vitals) with an explicit instruction not to hand back partially verified work if any step fails.
Goal-based — /goal
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. The evaluator-checks-the-condition mechanic is the load-bearing detail: it’s a maker/checker split applied to the stop condition itself, not just the work.
Time-based — /loop and /schedule
/loop 5m check my PR, address review comments, and fix failing CI — for recurring work (same task, changing inputs) or work gated on an external system (a PR awaiting review or CI). /loop runs locally and dies with your machine; /schedule is the cloud-durable form.
Proactive — composing the primitives
/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. This composes a time-based trigger, a goal-based stop condition, and dynamic workflows’ parallel-worktree-plus-judge pattern into one proactive loop.
Try It
- Diagnose which primitive you’re missing, not which loop is “best.” The post’s own closing framework: pick one task where you’re the bottleneck, then ask — can you write the verification check (turn-based gap)? Is the goal clear enough to state as a stop condition (
/goalgap)? Does the work arrive on a schedule (/loop//schedulegap)? - Start with a
SKILL.mdverification check before reaching for/goal. The post’s own progression is turn-based-with-better-verification first;/goalonly once you can state a deterministic success criterion. - Run, observe, iterate. “Observe the results like where it stalls or over-reaches, and don’t be afraid to iterate on it” — the post explicitly frames the first version of any loop as provisional.
- Cross-reference Model vs. Effort before scaling a loop up. This post names model and effort-level choice as “the biggest levers on what a loop costs” and links to Anthropic’s companion post on the same topic — likely the same underlying content the wiki already has via an X-thread source.
Open Questions
- Resolved 2026-07-16: direct-diffed the companion post (“Choosing a Claude model and effort level in Claude Code”) against the wiki’s existing Model vs. Effort article. Same underlying piece — identical structure, examples, and framing throughout — republished with sentence-level editorial rewording (not verbatim) plus 7 embedded diagrams and two doc links (
max_tokens, task budgets) absent from the original X thread. No new claims, no contradiction. Folded into the existing article as a corroborating second source. - Resolved 2026-07-16: ingested the companion post as Steering Claude Code: When to Use CLAUDE.md, Rules, Skills, Subagents, and Hooks — the seven-method decision framework this post’s turn-based-loop section pointed to for “choosing between skills, hooks, and subagents.”
- Resolved 2026-07-16: the full 17-post
claude.com/blogbacklog (the original list plus the 2 surfaced by this session’s ingests, “CLAUDE.md files: Customizing Claude Code for your codebase” and “How Anthropic runs large-scale code migrations with Claude Code”) has now been cleared — 15 posts processed via 5 parallel agents in one batch. A smaller second-order backlog (companion posts those 15 articles cited but didn’t fetch) is tracked inclaude-ai/_research-agenda.md.
Related
- Loop Engineering — Addy Osmani’s Essay — the third-party essay that named the practice three weeks before this first-party post; Osmani’s five building blocks (automations, worktrees, skills, connectors, sub-agents) map onto this post’s four loop types from the outside-in.
- Loop Engineering — Cobus Greyling’s Reference + CLIs — the deeper tool-agnostic catalog (six primitives, L0→L3 ladder) built on Osmani’s essay; this post is the narrower, first-party, Claude-Code-specific counterpart.
- Write Loops, Not Prompts — the topic’s beginner entry point; this post’s turn-based/goal-based split maps directly onto that explainer’s cost-control framing.
- Verifier-First Loops — the verification discipline this post’s
SKILL.mdexample and “don’t hand back partially verified work” instruction both operationalize. - Should You Build a Loop? — the economics layer; this post’s “biggest levers on cost” claim (model/effort, loop boundaries) is a first-party corroboration of that article’s cost-math.
- goal` Walkthrough — the hands-on mechanics behind this post’s goal-based loop type.
- loop` & Scheduled Tasks and Claude Code Routines — the mechanics behind the time-based loop type (
/looplocally,/schedule/routines in the cloud). - Dynamic Workflows — the parallel-worktree-plus-judge mechanism this post’s proactive-loop example composes in.
- Model vs. Effort — the cost lever this post points to directly for managing token usage.
- Steering Claude Code — the companion post (same co-author, Michael Segner) this post links to for choosing between skills, hooks, and subagents in the turn-based-loop verification step.
- Reflecting on a Year of Claude Code — Boris Cherny & Cat Wu’s “my job is to write loops,” the other first-party source in this topic.