The Conversation Loop

Summary#

Every Claude Code session is the same six-step loop: you state intent, Claude reads, Claude plans, Claude acts, Claude reports, you redirect. Repeat. The loop has no exotic states — there is no “thinking mode” you toggle, no “agentic plan” you arm. There is one loop, and every advanced feature (plan mode, sub-agents, hooks, skills, MCP) is a hook into one of its six steps.

This page is the most important mental model in the workbook. Internalise the loop and the rest of Claude Code’s surface stops being a list of features and becomes obvious — each feature is a customisation of a specific step. Skip it and every new feature looks like a new concept.

Why it matters#

Engineers new to agentic CLIs often have one of two confused mental models. The first is the chat-box model: “I type, the model types back, eventually it produces code I paste somewhere.” That model misses that Claude Code is doing real work — opening files, running shell commands, making edits — between turns. The second is the autonomous-agent model: “I tell it what I want and it goes away for an hour and comes back.” That model misses that the loop is interactive by design and that the human is supposed to redirect every few turns.

Once you can name the six steps, three things get easier:

• Debugging a bad session. Which step went wrong? Did Claude not read enough (step 2)? Did it skip planning (step 3)? Did it act without confirming a risky step (step 4)? Did its report obscure what changed (step 5)? Did you not redirect when it went off (step 6)? Each step has its own fix.
• Choosing the right feature. Plan mode customises step 3. Hooks customise steps 4 and 5. Sub-agents customise step 2. Memory and CLAUDE.md customise step 1’s implicit context. If you know the loop you know which dial to turn.
• Estimating cost and time. Each loop turn costs tokens for input (your message + tool results) and output (Claude’s text + tool calls). Sessions that produce many short turns are cheap; sessions that produce few long turns are expensive. The loop is the unit of accounting.

How it works#

The six steps, in order#

The loop is deterministic in shape; the content of each step varies.

1. You state intent. A new prompt, a question, an acknowledgement, or a redirect. This is the only step the human is required to take — everything else is the model’s job.
2. Claude reads. Pulls files into context with the Read tool, runs Grep / Glob for orientation, may delegate to a sub-agent for broader research. This step is where context-window cost is incurred.
3. Claude plans. Internal-only by default — the model decides what tools to call and in what order. In plan mode the plan is written to a file for you to review before any acting happens.
4. Claude acts. Tool calls: Edit, Write, Bash, Task, WebFetch, MCP tools. Tool calls run in parallel when independent; serial when dependent. Risky tools route through the permission system.
5. Claude reports. A short text response summarising what it did and what it found. This is the only output a chat-box user would recognise; in Claude Code it is the smallest part of the turn.
6. You redirect or proceed. Approve, correct, ask follow-ups, change scope, or end the conversation. Loop returns to step 1.

A session is a sequence of loop turns until you close the CLI. Most useful sessions are 5 to 50 turns; sessions in the hundreds usually need a context reset.

What each step is bounded by#

The loop’s behaviour is constrained at each step by something specific:

• Step 1 is bounded by your prompt. Vague intent produces vague execution. The single most useful skill is writing intent that constrains step 3 to a manageable plan.
• Step 2 is bounded by the context window. Claude can read as much as fits; past that, older content falls out (see context-window page). A repo that does not fit must be read selectively.
• Step 3 is bounded by the model. Opus plans more carefully than Sonnet, Sonnet more carefully than Haiku. Plan quality is a model-tier function.
• Step 4 is bounded by tools and permissions. Claude can only do what tools let it do, and the permission system gates risky tools.
• Step 5 is bounded by tokens. Reports are usually short by design — every line of report is a line of context next turn.
• Step 6 is bounded by you. This is the human-in-the-loop. Skip it and you get an autonomous agent; engage it and you get a collaboration.

Tool calls inside a single turn#

A single step-4 can contain many tool calls. Independent tool calls — two Reads on different files, a Grep and a Glob on the same query — run in parallel. Dependent calls — Read then Edit, Bash that depends on a file written earlier — run in serial. The model decides which is which; you’ll see the parallel calls clustered together in the output.

This matters for the mental model: a “turn” is not “one tool call.” A turn can be ten parallel reads, three serial edits, and a final test run, all inside step 4 of one loop iteration. The status line shows progress mid-turn so the loop doesn’t feel frozen.

The loop and the context window#

Each turn appends to context: your message, the model’s planning text, every tool call, every tool result. Context grows monotonically within a session. When it approaches the model’s limit, Claude Code triggers compaction — summarising older turns to free space for the active conversation. This is invisible if it works well and very visible if it doesn’t.

For a full treatment see the context window page. The short version: the loop is cheap in concept but expensive in tokens, and conversation design is about keeping the loop running on a budget.

Variants and trade-offs#

Most engineers find a comfortable spot between the two. Tight loops are right for unfamiliar code, risky operations, and tasks where the spec is fuzzy. Loose loops are right for well-understood tasks (lint sweeps, type-fix passes, mechanical refactors) where the model is unlikely to surprise you.

The other axis is plan-or-act:

• Plan-first sessions enter plan mode for step 3, get a written plan, then exit to execute. Heavier ceremony, much better outcomes on complex changes.
• Act-first sessions skip plan mode entirely — the model plans internally and executes in the same turn. Faster for simple work, dangerous for anything that touches many files.

A reasonable default: act-first for changes under ~3 files or under ~50 lines; plan-first for anything bigger or anything you’d want a colleague to review before you start typing.

When this is asked in interviews#

The loop shows up often in agent-design and developer-tools loops, sometimes more deeply than expected.

• Agent-design interviews — the question is usually “draw the control flow of an agentic coding tool.” Sketching six steps with arrows back to step 1 — and being able to name what each step is bounded by — is the answer most candidates miss. The follow-up is typically about where you’d add a hook, a sub-agent, or a planning phase.
• Senior developer-tools loops — the depth gets higher: how does the loop interact with context-window pressure, how do you detect a stuck loop, how would you instrument it for cost and latency.
• AI-product interviews at coding-tool startups — the loop is table stakes. What they probe is whether you’ve thought about each step’s failure modes — premature acting, runaway tool calls, over-eager redirection.

Where it doesn’t come up: classic algorithms / DSA interviews, frontend product loops, infra roles that don’t touch agents. Worth knowing if you’re targeting AI-tooling roles; less critical otherwise.

Related concepts#

• What Is Claude Code?
• Context Window and Token Budget
• Permission Modes
• Plan Mode
• CLAUDE.md and Memory Files