There Are Four Levels of Delegating to AI: Reading Claude Code's Official Loop Guide Through a Familiar Example¶

For / Key Points

For: Readers who use Claude Code through one-off prompts and want a clearer mental model for /goal, /loop, and /schedule.

Key Points:

A loop means repeating a work cycle until a stop condition is met
The four loop types map to what you hand off: review, stop judgment, timing, and the instruction itself
The starting point is not picking a feature, but writing down how you verify your own work

The hard part of delegating work to AI is not just writing a better prompt. The harder question is how far to delegate, where the work should stop, and how completion should be verified.

This article asks how to read Claude Code's official four loop types as a practical delegation model.

The Four Types Are Four Levels of Delegation¶

Imagine assigning work to a junior teammate. At first, you review every deliverable yourself. Once the person has learned the task, you give a clear acceptance bar: keep revising until this standard is met. Later, you turn it into a routine: check this every morning. Eventually, you delegate the whole operation.

Claude Code loops follow the same shape. In its June 30, 2026 official blog post, the Claude Code team defines loops as agents repeating cycles of work until a stop condition is met¹. That matters because the phrase "design loops, not prompts" had spread faster than a shared definition. The blog gives the term a concrete operating frame.

The post divides loops into four types and describes them by trigger, stop criteria, Claude Code primitive, and best-fit task. Read through delegation, the axis becomes simpler: what does the human stop doing?

Type	What You Hand Off	Familiar Example	Main Primitive
Turn-based	Reviewing each output	Giving work to a new teammate and reviewing every pass	Ordinary prompts + verification skills
Goal-based	Deciding when to stop	Giving an acceptance bar and letting the process retry	`/goal`
Time-based	Deciding when to start	Routine checks and inbox monitoring	`/loop` and `/schedule`
Proactive	The instruction itself	Delegating an entire operation	The above + dynamic workflows

Complex loops are not the default answer. The official post explicitly says to start with the simplest solution and use these patterns selectively¹. That makes the table a progression, not a menu to jump through at random.

Turn-Based Loops: Check Every Result¶

Ask Claude Code to build a like button. Claude receives the request, reads the code, edits files, runs tests, and reports back. You inspect the result and write the next instruction.

That single exchange is already the smallest loop. Claude Code's documentation describes the agentic loop as Claude gathering context, taking action, verifying results, and repeating until the task is done². For short tasks, this is often enough.

The bottleneck is the number of back-and-forth turns. The way to reduce it is to give Claude the checklist you would otherwise apply manually before accepting the work. In Claude Code, that checklist can become a SKILL.md file³.

A minimal verification skill

---
name: verify-ui-change
description: Verification steps before reporting a UI change as done
---

1. Start the dev server and open the changed page
2. Interact with the changed component directly
3. Confirm the browser console has no new errors
4. If any step fails, fix it and restart from step 1

Quantitative checks such as passing tests and score thresholds are easiest for Claude to verify. The verification skill you write here becomes the raw material for the next level: a goal-based loop.

Goal-Based Loops: Hand Over the Acceptance Bar¶

Goal-based loops reduce the human's need to say "keep going." When you ask someone to proofread without a clear acceptance bar, the work can come back when that person merely feels finished. The missing piece is not effort; it is a stop condition.

If you say "no typos, but stop after five passes," the stop judgment moves from intuition into a rule. Claude Code's /goal implements this pattern.

/goal Raise the homepage Lighthouse score above 90. Stop after 5 turns.

According to the official documentation, /goal is implemented as a session-scoped prompt-based Stop hook⁴. After each Claude turn, the condition and conversation so far are sent to a small fast model. If the evaluator returns "no," Claude keeps working and receives the reason as guidance. If it returns "yes," the goal is cleared and recorded as achieved.

The useful conditions are machine-verifiable: test results, build exit codes, score thresholds, empty queues. "Make it feel polished" is hard for the evaluator to judge. Turn or time limits act as a safety boundary.

This is not a timer that stops after a fixed duration. It is closer to an appliance that stops when the state is right. Once the stop condition is clear, the next question is who decides when the loop starts.

Time-Based Loops: Hand Over the Timing¶

PR review comments and CI failures do not arrive on your schedule. Checking them manually is like waiting for a delivery and walking to the door every few minutes. The task to delegate is the checking itself.

/loop 10m Address PR review comments and fix CI if it is failing

/loop reruns a prompt at a given interval⁵. It fits deployment monitoring, PR babysitting, and long-running build checks: tasks where the next useful action depends on whether the outside world has changed. Because it runs inside the current session, it can reuse the current working context.

The limit is scope. /loop is tied to the current CLI session. It stops when the session is gone or a new conversation replaces it. For work that should continue when your laptop is closed, move the task to Routines on Anthropic-managed cloud infrastructure. From the CLI, /schedule creates scheduled routines conversationally⁶.

The cost principle is simple: match the check interval to how often the watched thing changes. If a queue changes hourly, polling every five minutes mostly buys extra token spend. Once timing is delegated, the final piece is the instruction itself.

Proactive Loops: Delegate the Operation¶

A proactive loop is not a single new feature. It is a composition of the pieces above. The official post uses bug report handling as an example: schedule the checks, define the goal, provide verification skills, use dynamic workflows, and allow auto mode where appropriate¹.

One design might look like this:

/schedule: check the reporting channel every hour
/goal + skills: keep working until every newly found report is triaged, handled, and answered
Dynamic Workflows: split triage, implementation, and review across multiple agents
Auto mode: reduce permission stalls within the approved boundary

As a prompt, the shape is direct.

/schedule hourly: check #feedback for new bug reports.
/goal Do not stop until every report found in this run is triaged, handled, and answered.
When fixing, create three candidate solutions with a workflow and have a reviewer agent critique them adversarially.

The important part is separating generation from evaluation. The agent that proposes a fix should not be the only judge of the fix. That separation reduces the risk of self-confirming evaluation. The business analogy is automated replenishment: the system checks demand, orders when thresholds are crossed, and verifies delivery.

The premise is heavier than it looks. Dynamic workflows are JavaScript orchestration scripts that Claude writes to coordinate many subagents, and they fit codebase-wide audits, large migrations, and cross-checked research⁷. The official loop post warns that workflows can spawn hundreds of agents, so usage should be estimated on a smaller slice before a large run¹.

Quality and Cost Need System Boundaries¶

As the delegated surface grows, prompt effort is not enough to protect quality. The official post points to surrounding systems: a clean and consistent codebase, verification skills, access to relevant documentation, and review by a separate agent¹.

The response to failure changes too. Do not only fix the current failure. Add the cause to a skill, rule, or checklist so the next repetition improves by default. The shift is from "fix this instance" to "encode the lesson into the loop."

Cost control is also boundary design.

Use smaller, faster models for routine work and reserve stronger models for judgment-heavy steps
Write concrete success and stop criteria so Claude stops neither too early nor too late
Pilot large runs on a small slice before scaling up
Turn settled procedures into scripts instead of making the model reason through them every time
Watch usage with /usage, bare /goal, and /workflows

Loops increase autonomy, but their practical value comes from adding boundaries. The clearer the boundary, the more safely work can move away from real-time human supervision.

Summary: The Order Matters¶

The four types are not independent options. A verification skill written for turn-based work becomes evidence for a goal-based loop. A goal condition becomes the stop condition for time-based and proactive loops.

The inverse is just as important. If you cannot describe how to verify a task, the task is not ready for any loop. Start by choosing one task where you are the bottleneck. Ask whether its verification can be written down, whether completion can be judged mechanically, and whether it happens repeatedly.

Delegate only up to the level where those answers are yes. Run it small. Watch where it stalls or overreaches. Then tighten the system. Delegating to AI is not a question of trust as a feeling; it is a design problem about which piece of judgment moves into the loop first.