Tweaking prompts over and over to get Claude Code to do a bit more is the norm for many agent users. Anthropic's official answer: rather than endlessly writing prompts, design a "loop" outright and let the agent run automatically under defined rules until it hits the goal or a stop condition. It's a paradigm upgrade from "writing instructions" to "designing systems." This article covers the 4 official loop types, the 5 elements every loop needs, and the engineering tricks for saving tokens — aimed at developers already using Claude Code who want to turn daily tasks into engineered processes.

The 4 Agentic Loop Types

A loop's essence is adding a trigger and a stop condition to the agent, turning "conversation" into "process." By trigger mechanism there are 4 types.

1. Turn-Based Loops

The most common form: the user sends an instruction, the agent replies, and the user decides whether to continue.

• Trigger: user input each round
• Stop condition: the user ends it
• Use cases: daily development, Q&A collaboration, code review

This is the default mode — nearly everyone is using Turn-based. Its strength is controllability; its weakness is that it can't do without the human, so true automation is out of reach.

2. Goal-Driven Loops

Started via commands like /goal. You provide a clear acceptance criterion, and the agent iterates and self-checks until the goal is met.

• Trigger: a one-shot command + acceptance criteria
• Stop condition: goal reached / budget exceeded
• Use cases: tasks with a clear Definition of Done, such as "make all tests pass" or "translate the docs into English and proofread them"

💡 Tip: A goal-driven loop's success hinges entirely on whether the acceptance criteria are verifiable. Don't give vague goals like "make the code a bit better"; give executable checks like "all pytest tests green, zero lint warnings."

3. Time-Driven Loops

Triggered on a schedule via commands like /loop and /schedule, or combined with cron / heartbeat. The agent wakes on a cycle and executes its task.

• Trigger: fixed intervals (hourly, daily, weekly)
• Stop condition: manual cancellation / run-count cap reached
• Use cases: periodic inspections (dependency vulnerability scans, log monitoring), scheduled reports (daily standup summaries), routine maintenance (dead code cleanup)

This loop type is the best fit for CI/CD and ops scenarios — the key form factor for agents going "always-on in the background."

4. Event/Hook-Driven Loops

Triggered by external events such as Git commits, pull requests, or file changes.

• Trigger: webhooks, file-system events, CI events
• Stop condition: event handling completes
• Use cases: auto-run tests on commit, automatic PR review, auto-reload after config file changes

Event-driven is the most fully engineered kind — effectively orchestrating the agent into your existing DevOps pipeline.

The 5 Elements Every Effective Loop Needs

Whichever loop you pick, officials stress explicitly designing the following 5 things — otherwise the loop either runs away from you or never terminates.

Of these 5, the spend limit and verification steps are the most commonly overlooked. The former protects your wallet, the latter protects correctness — the agent's output must be verifiable automatically by scripts or tests; "it looks right" is not done.

4 Engineering Tricks for Saving Tokens

Once a loop is running, context is the biggest cost. Official and community optimization advice almost all centers on "how to feed fewer tokens."

1. Orchestrate Parallel Agents with Dynamic Workflows

Don't have one agent do everything serially; split the work across parallel sub-agents — one triages, one fixes, one reviews. Each sub-agent works only inside its own small context, and the main loop just collects results.

2. Turn On Auto Mode

Let the process run without human intervention. With clear stop conditions, the agent can run many rounds in a row without bothering you.

3. Tighten Context, Load on Demand

Don't pour the whole codebase in. Use Claude Code's tools to read files and grep on demand, keeping only what's relevant to the current task in context.

4. Isolate Context with Sub-Agents

Keep only summaries in the main loop; hand details to sub-agents that process them in their own context and return results. This is the core technique for keeping the main agent's context from bloating.

Supporting Theory: Anthropic's 5 Agent Workflows

When designing loops, the underlying layer can borrow the 5 workflow patterns Anthropic summarized in "Building Effective Agents":

• Prompt chaining: break a large task into fixed sequential steps
• Routing: classify first, then dispatch to the matching handler
• Parallelization: run multiple subtasks at once
• Orchestrator-workers: a central LLM decomposes the task, dispatches to workers, and aggregates results
• Evaluator-optimizer: one evaluates, one improves, forming a feedback loop

These 5 patterns can be combined and nested to form the skeleton of complex loops.

Verifying the Outcome

A well-designed loop should meet three verification criteria:

1. Observable: inputs, outputs, and token consumption of every step are visible
2. Interruptible: it can be stopped at any time and won't retry endlessly because of one bad state
3. Verifiable: output correctness can be judged automatically by scripts or tests

If you still have to confirm manually whether the results are right after a run, the verification steps aren't designed well — go back and fix them.

FAQ

• The loop never stops: 90% of the time the acceptance criteria are too vague or there's no spend limit. Add a hard budget ceiling first, then write "done" as an executable test command.
• Context keeps growing and slowing down: bring in sub-agent isolation. The main agent holds only summaries; raw content is processed in the sub-agent and discarded.
• The event-driven loop won't fire in CI: check webhook auth and the event payload format — Claude Code's event hooks are strict about payload schema.

References

• Claude Code official docs: Agent Loop
• Anthropic: Building Effective Agents
• Claude Cookbook: Orchestrator-Workers pattern