How Claude Code's agentic loop works

Claude Code doesn't follow a fixed list of steps: it repeats a cycle until the task is done. This page explains how that cycle works and when it's worth splitting work across multiple agents — and when that just creates more problems than it solves.

What happens on each turn of the loop?

A Claude Code agent moves through three phases on every turn: it gathers context (reads files, runs a command, queries a tool), takes an action (edits code, runs a test, calls a tool), and verifies the result before deciding the next step. There's no fixed fourth phase for "planning" or "deploying" — the loop is those three phases, repeated as many times as the task requires.

That's why two similar-looking tasks can burn very different numbers of iterations: renaming a variable used in three files can close in a single turn, while debugging a test that fails intermittently can take ten, because each fix attempt has to be verified before the next one is tried.

When it's worth opening a subagent

A subagent runs in a separate session and returns only a summary to the main context — the noisy exploration (files read, commands that failed, dead ends) stays out. That keeps the main session lean even on large tasks.

The rule that decides whether it's worth it: the delegated task has to be narrow and verifiable. "Review the security of these 40 independent files" splits well across subagents because each piece has a clear success criterion. "Improve the backend" doesn't delegate well to anyone — not to a subagent, not to a person — because there's no way to know when it's done.

Delegating also means deciding which model each subagent uses. A mechanical task — renaming a variable across the whole project — doesn't need the most expensive model available; a task that requires judgment about architectural trade-offs does. Routing to the cheapest model that still solves the task correctly is part of designing the delegation, not a separate cost tweak.

Why running agents in parallel doesn't always work

Fan-out — firing off several subagents at once — only works when the pieces are genuinely independent. Two tasks that touch the same file, or that depend on each other's output, break in parallel the same way they'd break if two people edited the same file at the same time without coordinating first.

Running multiple sessions against the same repository has a concrete problem: they compete for the same working tree. Git worktrees solve this by giving each session its own working copy, all pointing at the same repository — without the risk of one session stepping on what another was editing.

Why it's worth having a second agent check the first

Asking the same agent to review its own work has a structural bias: it tends to confirm the decisions it just made. A second agent, in a separate session and without seeing the first one's reasoning, has a better chance of catching a real error because it doesn't carry the same blind spot.

That only cuts false positives for real if the reviewing agent is independent — its own context, not the first agent's summary — and has an objective criterion to judge by. Without those two conditions, "verification" just becomes a second opinion biased by the first.