Deep Dive · XiaoHu Explains

Claude Code's Official Breakdown of Loop Design: 4 Escalating Levels to Unattended Autonomy

From manual confirmation to fully unattended — the Claude Code team lays out a 4-level loop taxonomy with practical advice
60-Second Overview
  • Anthropic's Claude Code team published a blog post breaking "designing a loop" into 4 standard patterns: turn-based, goal-based (/goal), time-based (/loop and /schedule), and proactive — escalating from low to high autonomy.
  • The official definition of a loop: an agent repeatedly executes rounds of work until some stopping condition is met. The four types are distinguished along four dimensions: who triggers it, how it decides to stop, which feature implements it, and what kind of task it suits.
  • The core mechanism of /goal is bringing in a separate evaluator model to judge whether the bar has been cleared — Claude itself can't just decide "good enough" and call it done — and you can also cap the maximum number of attempts.
  • Proactive loops stack five features together — /schedule (time-based triggering), /goal (stopping condition), skills (validation criteria), dynamic workflows (multi-agent parallel orchestration), and auto mode (no manual confirmation) — to handle ongoing work like bug-report triage, issue classification, and dependency upgrades, unattended.
  • Two practical recommendations: use scripts for deterministic work — it's cheaper in tokens than making Claude re-derive it every time; and for large-scale dynamic workflows (which can spin up hundreds of agents), do a small-scale test run before going live.
⚑
Stance note: this piece is from Anthropic's official blog and covers Claude Code's own capabilities and feature combinations — it's vendor-published content. The classification framework, sample code, and figures like 90 and "hundreds of agents" cited in this piece are all drawn from the original — this is the official line.
1Background · What This Piece Covers

AI Does the Work — But Who Decides It's "Done"?

Claude Code team members Delba de Oliveira and Michael Segner published a post on Anthropic's official blog on June 30, 2026, laying out a systematic approach to designing "loops" for Claude Code: having an agent repeatedly execute work until it meets a stopping condition.

The authors open by pointing to a phenomenon: X is full of chatter about "stop prompting your coding agent one line at a time — design loops instead," but if you actually go look for what a loop even is, you'll find a pile of answers that contradict each other. This piece sets out to clear that up.

It isn't a new product launch — it's a framework: taking 5 standalone features that already existed in Claude Code and organizing them into 4 loop types ranked by degree of autonomy, complete with combination templates you can copy directly.
⚡
Why it's worth reading: /goal, /loop, /schedule, dynamic workflows, and auto mode — these 5 features are placed on a single coordinate system for the first time, laid out in 4 levels from "you watch every round" to "fully unattended." At the end, the piece also gives a copyable pipeline that combines these features into a system that automatically handles bug triage, issue classification, and dependency upgrades.

Below, we unpack the 4 levels of loops one by one, from simplest to most complex — each one should map onto some class of work you already deal with.

2Definition and Coordinate System

First, Get Clear: What Exactly Is a "Loop"

The official definition is a single sentence: a loop is an agent repeatedly executing rounds of work until some stopping condition is met. The key distinction is that "when it's considered done" is defined in advance and left to the system to judge — not something you personally chase round after round.

The authors classify loops along four dimensions, and these four dimensions form the shared reference frame for every loop type that follows: who triggers it, how it decides it should stop, which feature in Claude Code implements it, and what kind of task it suits best. Set up the coordinate system first, and then the four loop types slot right in.

Autonomy ↑ ① Turn-based ② Goal-based ③ Time-based ④ Proactive Inner ring: you watch every round Outer ring: fully unattended
The further out the ring, the higher the autonomy and the less oversight needed; the outermost ring — the one with the continuously flowing track — is a loop actually running unattended right now
① Who triggers it

A single prompt → manual, real-time → on a timer (interval) → an event or a schedule, with no one present at all

② How it decides to stop

Claude decides for itself → hits the bar or the retry cap → you cancel it or the work is done → each task exits on its own bar, you shut down the whole pipeline by hand

③ Which feature implements it

Default conversation → /goal → /loop, /schedule → all of the above + dynamic workflows + auto mode

④ What it suits

Short tasks → tasks with a verifiable exit criterion → periodic tasks or ones that touch external systems → recurring, clearly-defined workflows