Loops and agentic runs: multi-step work

You asked for a “small fix.” Forty minutes later Claude has touched nine files, started a refactor of the logging library, opened a draft PR description for a different ticket, and is waiting on a permission prompt for a network command you do not recognize. You are not mad at the model for being ambitious. You are mad at yourself for treating a multi-step agent like a single autocomplete box.

This is Part 8 of Claude Code tutorial. Part 7 mapped tools, MCP, and plugins. Here we stay on the run itself: the agentic loop (goal, plan, act, observe), multi-step work, subagents and teams for parallel effort, how usage burns faster when the agent keeps going, and how much autonomy to grant (watch, steer, or walk away only with rails). At map level we also note routines, /loop-style patterns, and scheduled tasks so you know they exist without turning this into a feature changelog.

What you’ll learn

The simplified agentic loop: goal → plan → act (tools) → observe → repeat or stop
Why multi-step runs feel different from one-shot chat answers
When subagents or team-style parallel work help, and why beginners should start single-threaded
How usage and attention costs climb with long tool chains
Three autonomy levels: watch, steer, walk away (only with rails)
Checkpoint phrases, stop conditions, and a practice loop you can run this week

Command names, UI labels, and scheduled-task features change. Treat the loop and autonomy levels as durable. Confirm live flags and slash commands in Claude Code docs before you write team runbooks.

What “agentic” means here

In a normal chat reply, you send a message and get text back. In an agentic run, the system can take intermediate actions toward a goal: read files, run tests, edit code, call MCP tools, then look at the results and decide what to do next. The unit of work is not one paragraph. It is a loop that continues until the goal is met, you stop it, or it hits a limit.

Claude Code is built for that style of work in a project context. You still own the goal and the review. The agent owns draft execution under permissions. If you skip the “own the goal” part, the loop will invent one: usually “improve everything it can see.”

Plain definition: An agentic run is multi-step work where the model plans, uses tools, observes outcomes, and continues until a stop condition. You are the operator, not the passenger with no brakes.

The agentic loop (simplified)

You do not need a research paper. You need a whiteboard loop you can interrupt.

Agentic loop: Goal, Plan, Act with tools, Observe, then Repeat or stop, with note that multi-step work burns usage

1. Goal

State what done looks like. Include constraints: no new dependencies, match existing patterns, only touch package X, stop after tests pass. Vague goals produce scenic tours. Concrete goals produce diffs you can review.

2. Plan

Good runs sketch steps before rewriting half the tree. You can force a plan: “List the files you will touch and the test command. Do not edit yet.” Plans are cheap compared to undoing confident messes. If the plan is wrong, you course-correct before the blast radius grows.

3. Act (tools)

Actions use tools: file reads and writes, search, shell, git, and any MCP connectors you enabled in Part 7. Each action should serve the plan. Drive-by cleanups are not free; they are unrequested scope.

4. Observe

Tool output matters: test failures, type errors, file contents, ticket fields. The model’s next step should react to reality, not to a fantasy of green CI. When observation is wrong (stale MCP data, misread log), the loop drifts. Your job is to notice drift early.

5. Repeat or stop

Continue while progress is real and the goal is unmet. Stop when done, when blocked on a human decision, when tests pass under the stated definition, or when you hit a checkpoint you set (“stop after plan,” “stop after first failing test is fixed”). Infinite loops are rare in the sci-fi sense and common in the “one more cleanup” sense.

Multi-step work is a different sport

One-shot chat: “Explain this function.” You read the answer. Cost is mostly one reply.

Multi-step Code: “Add pagination to the admin users table, reuse the existing table component, add a test, update the storybook entry if one exists.” The agent may search, read six files, edit four, run tests, fail, edit again, run again. That is normal. It is also why the session feels “alive” and why usage meters move faster.

Shape	What success looks like	What usually fails
One-shot Q&A	Clear explanation or snippet	Wrong file assumed; no repo proof
Short agent run	Small diff + tests green	Skipped explore; wrong package
Long agent run	Feature slice with proof	Scope creep; usage burn; weak stop criteria
Parallel helpers	Independent subtasks merge cleanly	Merge conflicts; duplicated edits; nobody owns integration

Train yourself to open multi-step work with structure: goal, constraints, stop condition, proof. Paste those four every time until it is muscle memory. The agent will still wander sometimes. You will catch it sooner.

Checkpoints beat “go do the whole epic”

Long goals are fine if you slice them. Prefer checkpoints the agent must honor.

“Stop after the plan. Wait for my OK.”
“Implement the data layer only. Do not touch UI yet.”
“Stop when npm test -- users passes or after two fix attempts.”
“If you need a new dependency, stop and ask.”
“If the ticket acceptance criteria conflict with the code, stop and show both.”

Checkpoints are not micromanagement for its own sake. They are how you keep multi-step power without accepting a surprise rewrite of your auth module because it was “nearby.”

Subagents and teams: parallel, with a catch

Some Claude Code setups support subagents or team-style parallel helpers: specialized roles that work on slices while a parent run coordinates. Plugins can even ship subagent definitions (Part 7). Parallelism is real. So are coordination costs.

When parallel helps

Independent tasks: “update docs” while “add unit tests for a pure function” if files do not collide
Research vs edit: one helper maps call sites while another drafts a fix under your review
Large migrations with clear package boundaries

When parallel hurts

Two agents editing the same file with incompatible assumptions
You cannot review two streams of diffs at once (honest capacity limit)
The “integration” step is the whole job (most product features)
You are still learning the tool: parallel multiplies confusion

Start simple. Single-threaded runs teach you the loop, permissions, and review habits. Add subagents when you have a clean split and a merge plan. Fancy orchestration does not fix a fuzzy goal.

Usage burns faster on multi-step work

Every tool call and observation cycle costs capacity (plan limits, tokens, or both, depending on how you access Claude Code). A long explore-edit-test loop can cost far more than a short Q&A. That is expected. It is not a bug for you to ignore.

Practical habits:

Do not start a long agent run for a question that needs a three-line answer.
Explore with a budget: “Map the auth flow in five bullets, cite paths, stop.”
Keep MCP tool sets lean so the model is not drowning in unused tool definitions.
Prefer focused working directories and clear file hints over “search the whole monorepo for vibes.”
If you are iterating on prompt wording, use small dry runs before the epic.

Teams that share seats should treat long unsupervised runs as a budget decision, not only a productivity flex. The same is true for personal Max-style plans: the meter is part of the craft.

Autonomy levels: watch, steer, walk away

Autonomy is not a personality trait of the model. It is a policy you choose for a task, based on risk and trust in the rails.

Three autonomy levels: Watch approve each step, Steer accept edits with review, Walk away only with rails tests and n…

Watch (default for learning and risky work)

You approve sensitive steps, read permission prompts, and stay present. Best for: production-adjacent repos, first time with a new MCP server, anything involving secrets, destructive git, or data mutation. Slow feels fast when you avoid a bad push.

Steer (common steady state)

You let more edits land without hand-holding every keystroke, but you still review diffs, run or watch tests, and stay available for forks in the road. Best for: familiar codebases, clear tickets, good project instructions, tests that actually catch breakage. Steer is not “ignore the PR.”

Walk away (only with rails)

You leave a run progressing without constant attention. This is the mode people brag about and the mode that creates incident stories. Walk away only when rails are real:

Non-production or clearly sandboxed environment
Strong automated tests and typechecks the agent must pass
No secrets in play, no production credentials in the session
Narrow file scope and no surprise network/deploy tools enabled
You will still review the final diff before merge

If any of those are missing, you are not “walking away with rails.” You are hoping. Hope is not a release process.

Routines, /loop, and scheduled tasks (map level)

Beyond one interactive session, Claude product surfaces increasingly offer ways to repeat or schedule work: routine-style jobs, loop-oriented commands (often discussed as /loop or similar patterns depending on surface and version), and scheduled tasks that kick work without you sitting in the chair. Exact names and availability depend on product and plan. The mental model matters more than memorizing today’s label.

Interactive loop: you are present; classic Code session.
Guided loop / routine: a repeated playbook (lint-fix, status summary, checklist) with clearer boundaries.
Scheduled task: work starts on a clock or trigger; review still lands on a human.

Anything that runs without your eyes inherits the walk-away rules. A scheduled agent with production MCP write access is an automation system, not a toy. Treat it like a cron job that can open PRs and call APIs: ownership, logging, least privilege, kill switch.

Worked example: one feature, three autonomy choices

Goal: “Add a CSV export button on the admin orders page. Reuse existing CSV helpers if present. Cover with a unit test. Do not change pricing logic.”

Watch mode session

You force a plan first. Claude finds csv.ts and the orders table component. You approve the edit set. Tests fail once on a date format. You approve the fix. You deny a suggested “cleanup” of pricing formatters that were not in scope. You commit with a human message. Slow, safe, teachable.

Steer mode session

Same goal, familiar repo, solid tests. You let Claude edit and re-run tests. You skim the diff for scope and secrets. You fix one naming nit yourself. You open the PR. This is the steady state for many developers once project instructions are good.

Walk-away (with rails)

Throwaway branch, CI required, no deploy credentials, MCP limited to read-only ticket fetch. You start the run, switch tasks for twenty minutes, come back to green tests and a draft PR. You still read the diff line by line before requesting review. If CI is flaky or the branch includes surprise files, you drop to watch mode immediately.

Prompt patterns that keep loops honest

Copy and adapt. Adjust paths and commands to your stack.

Goal: Add CSV export on admin orders page.
Constraints:
- Reuse existing CSV helpers if present
- Do not change pricing logic
- No new dependencies
Stop conditions:
- Stop after plan for approval
- After implementation, stop when unit tests for export pass
Proof:
- Show the test command and result
- Summarize files changed in under 10 lines

Another pattern for exploration-only:

Explore only. Do not edit files.
Question: Where is order CSV logic today, if anywhere?
Return: bullet map with file paths and one recommended approach.
Stop when the map is done.

And a pattern when you fear scope creep:

If you notice an unrelated bug or cleanup, list it under "Out of scope notes."
Do not fix out-of-scope items in this run.

How this connects to tools and plugins

Part 7’s ladder still applies inside loops. A multi-step run with only built-in tools is already powerful. MCP adds external observe/act steps (read ticket, post comment). Plugins can inject skills and subagents that change how the loop branches. More tools mean more ways to succeed and more ways to burn usage or widen blast radius. Add them for the step that is blocked, not for the aesthetic of a full dashboard of connectors.

Instruction files shorten loops by removing rediscovery. Skills shorten loops by packaging known playbooks. Neither replaces stop conditions. A highly skilled agent with no stop condition will still redecorate your monorepo.

Common mistakes

Goal soup

“Make the admin better” is not a goal. The loop will invent metrics. Use ticket language: user-visible outcome, constraints, proof.

Skipping observe

If tests fail and the agent “fixes” something unrelated, interrupt. Paste the failure. Demand a hypothesis. Observation is the honesty layer of the loop.

Parallel too early

Subagents on day two of learning Claude Code is cosplay. Master single-thread review first.

Walking away without rails

Production credentials, broad shell, and “I’ll check the PR tomorrow” is how surprises ship. Autonomy is earned by environment design, not by optimism.

Ignoring the meter

Long loops are valuable and expensive. If you are thrashing prompts on a huge monorepo search, narrow the path. Budget is part of engineering judgment now.

Never stopping to integrate

Multi-step work still ends in a human-readable PR, a test plan, and a decision to merge. The loop is not complete when the agent stops typing. It is complete when you accept responsibility for the change.

Practice for this week

Run one explore-only loop with an explicit stop. Save the path map it produced. Verify two paths by hand.
Run one implement loop with “stop after plan.” Approve or rewrite the plan before edits.
On a familiar repo, try steer mode for a small ticket. Time-box review: read every changed hunk.
Write your personal rails checklist for walk-away (env, tests, secrets, scope, final review). Keep it next to your terminal.
Do not enable parallel subagents until you have three clean single-thread runs with good stop conditions.

Quick recap

Agentic runs loop: goal, plan, act with tools, observe, then repeat or stop.
Multi-step work needs checkpoints and proof, not only enthusiasm.
Subagents and teams can parallelize; start single-threaded.
Usage burns faster when tools keep cycling. Budget deliberately.
Autonomy levels: watch, steer, walk away only with rails (tests, sandbox, no secrets, final human review).
Routines, loop commands, and scheduled tasks exist at map level; treat unattended runs like automation systems.

Next in this series: Part 9, reviewing diffs, undoing, and not shipping blind. The loop is only half the job. The other half is reading what changed, smelling bad diffs, and knowing how to reverse course before the branch becomes folklore.

Sources

Research and further reading used for this article:

Claude Code documentation: Overview (agent workflow in project contexts)
Anthropic: Building effective agents (workflow patterns for multi-step tool-using agents)
Anthropic engineering: Advanced tool use (tool orchestration and large tool libraries)
Anthropic engineering: Code execution with MCP (token costs of tools and results in long runs)
Model Context Protocol (external tools as observe/act steps outside the repo)
Claude Code documentation: Plugins (skills, subagents, and bundled workflow pieces)
Claude Code product page (positioning; verify plans and limits live)
Analytics Made Simple: Claude product map (Code vs chat vs Cowork for job fit)