The Four Loop Patterns in Claude Code

A loop is an agent repeating cycles of work until a stop condition is met. On July 24, 2026, Anthropic ran a live session on loop engineering led by Mark Nowicki, Member of Technical Staff on the Applied AI team. The framing was narrow and useful: Claude Code offers four loop patterns, and the skill worth having is knowing which one fits the job in front of you. At Shahriar Labs, that model now governs how every long-running agent task gets set up.

Definition: loop engineering

Loop engineering (Noun): the practice of deciding what starts an agent's next cycle of work, what judges whether it should stop, and what budget bounds the run, rather than driving every turn by hand.

Every prompt you send already starts a manual loop in which you are the trigger, the evaluator, and the stop condition at once. Loop engineering is mostly about choosing which of those three jobs to hand over.

The four loop patterns

• Turn-based. Triggered by your prompt, stops when Claude judges the task complete or needs more context. Best for short, one-off work where your judgment is part of each cycle.
• Goal-based (/goal). Triggered by the previous turn finishing, stops when an evaluator model confirms your condition or a turn cap is hit. Best when the work has a verifiable end state.
• Time-based (/loop, /schedule). Triggered by a time interval, stops when you cancel it or the work completes. Best for polling something outside the session: CI, a deployment, a reviewer.
• Proactive (routines). Triggered by an event or schedule with no human present. Individual tasks exit on their goals while the routine runs until disabled. Best for well-defined recurring work streams such as bug triage or mechanical migrations.

The list is really a scale of how much of the loop you are still holding yourself. All of it at the top, none of it at the bottom. Most engineering work belongs in the middle two.

Goal-based loops: the evaluator is the mechanism

/goal sets a completion condition and Claude keeps working toward it without a prompt at each step. It is a wrapper around a session-scoped prompt-based Stop hook. After every turn, the condition plus the conversation so far are sent to the configured small fast model, Haiku by default, which returns a yes-or-no decision and a short reason. A no sends Claude back to work with that reason as guidance. A yes clears the goal.

Two things follow from that design. Completion is judged by a fresh model rather than the one carrying six turns of sunk cost in the work. And the evaluator does not call tools, so it can only judge what Claude has already surfaced in the conversation. The second point dictates how conditions must be written: around command output that lands in the transcript, never around a subjective quality the model cannot print.

A durable condition has one measurable end state, a stated check for how Claude should prove it, and the constraints that must not change on the way there. Conditions can run to 4,000 characters, and the budget belongs inside them: or stop after 20 turns. Note that a goal does not change permissions. Pair it with auto mode for unattended runs, since auto mode removes per-tool prompts while /goal removes per-turn prompts.

Time-based loops: poll what you do not own

Goals are for work you control end to end. Time-based loops are for work that depends on an external system, where you cannot write a condition against state you do not own. /loop 5m check my PR, address review comments, and fix failing CI runs on a fixed cron cadence. Omitting the interval switches on self-paced mode, where Claude picks a delay between one minute and one hour based on what it just observed: short waits while a build is active, longer ones once things go quiet.

Two rails are worth knowing before relying on this in production. The scheduler adds deterministic jitter, so an hourly job set for :00 may fire anywhere up to :30. And session-scoped recurring tasks expire after seven days, which makes /loop a session tool rather than an automation platform. Durable scheduling belongs in cloud Routines, Desktop scheduled tasks, or GitHub Actions.

Building a loop that finishes

Every loop that terminates cleanly has three ingredients. Every runaway loop is missing at least one.

• Done. A stop condition provable from the transcript alone. The test: could a stranger reading only Claude's terminal output answer yes or no, with no further investigation?
• Budget. A turn cap in the condition, an interval matched to how fast the underlying thing actually changes, and a token ceiling piloted on a small slice first. A loop without a budget is not autonomous. It is unsupervised.
• Checkpoint. A durable artifact each cycle: a commit, a branch, a worktree, a status file. Checkpoints make a run auditable, let you roll back one iteration instead of all of them, and let work resume without replaying.

Loop-ready codebases

A loop amplifies whatever a repository already is. Four things decide whether that helps: a clean codebase with consistent patterns Claude can imitate, verification encoded as skills so the agent proves its own work rather than asserting it, documentation the loop can read instead of guessing at, and a second agent reviewing the output. The verification skill is the highest-leverage item, because it turns "Claude said it is done" into evidence the evaluator can actually read.

The same discipline drives the orchestrator and worker split used across Shahriar Labs products including LetX and QuantumSketch. Deterministic, high-volume work goes to scripts and cheaper agents. Judgment and final review stay with the expensive model.

Frequently Asked Questions (FAQ)

Q: What is a loop in Claude Code?
A: A loop is an agent repeating cycles of work until a stop condition is met. Claude Code exposes four patterns: turn-based (you prompt each cycle), goal-based via /goal (an evaluator model checks a condition after every turn), time-based via /loop and /schedule (an interval triggers each cycle), and proactive routines (an event or schedule triggers cycles with no human present).

Q: What is the difference between /goal and /loop?
A: /goal starts the next turn as soon as the previous one finishes and stops when an evaluator model confirms your condition is met. /loop starts the next turn when a time interval elapses and stops when you cancel it or the work completes. Use /goal for a verifiable end state, /loop for polling something outside the session such as CI or a deployment.

Q: How do I stop a Claude Code loop that will not stop?
A: Run /goal clear to drop an active goal, or press Esc while a /loop is waiting for its next iteration. The lasting fix is to rewrite the stop condition so it is provable from Claude's own transcript, such as 'npm test exits 0' rather than 'tests look fine', and to add a budget clause like 'or stop after 15 turns'.

Q: How does the /goal evaluator decide a goal is complete?
A: After every turn, the condition and the conversation so far go to your configured small fast model, which defaults to Haiku. It returns a yes-or-no decision and a short reason. A no sends Claude back to work with that reason as guidance. The evaluator does not call tools, so it can only judge what Claude has already surfaced in the transcript.

Q: Why do session-scoped scheduled tasks expire?
A: Recurring /loop tasks expire seven days after creation, firing one final time before deleting themselves, which bounds how long a forgotten loop can run. A session also caps at 50 scheduled tasks. For automation that must outlive a session, use Routines on Anthropic-managed infrastructure, Desktop scheduled tasks, or GitHub Actions.

Q: Where can I read the full engineering write-up?
A: The founder's detailed breakdown, including runnable recipes and a debugging table for runaway loops, is on the hub at shihub.online/blog/claude-code-loop-engineering-four-loop-patterns.

Summary

Four patterns, one question: what should start the next cycle, and what decides when to stop. Turn-based keeps you in the loop, /goal hands the stop decision to a fresh evaluator, /loop hands the trigger to a clock, and proactive routines hand over both. Whichever you pick, define done, set a budget, and add a checkpoint. A loop missing any of the three does not finish. It just runs.