Claude Code Workflows

Why Delegate Anything

Delegation looks like a speed trick and is mostly an economy one. What you spend is the context window of the conversation you are steering, and reading forty files into it to answer one question wastes it fastest. So delegate when the task produces verbose output you don't need in your main context — delegate the exploration so only the findings come back. The bill does not disappear, though: running several sessions or subagents at once multiplies token usage.

What a Subagent Is, and What It Never Sees

A subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions, and returns a summary.

The isolation is the feature and the price. Each starts fresh, and it doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. "Fix the bug we just discussed" reaches an agent that was not there: whatever the worker needs must be in its prompt.

A fork is the exception that proves the rule — a subagent that inherits the entire conversation so far instead of starting fresh. Use one when re-explaining would cost more than the work; a fork can't spawn further forks.

Claude picks the worker automatically based on the task description in your request. Foreground subagents block the main conversation until complete; background ones run while you keep working, their results arriving as a completion notification in a later turn.

Four Surfaces, and the Question That Chooses Between Them

Claude Code delegates four ways, and in every approach the workers are Claude sessions. What separates them is one question: who holds the plan?

• Subagents — Claude holds it, turn by turn: workers that do a side task in their own context and return a summary.
• Background sessions — you hold it: they run unattended and report only to you.
• Agent teams — a lead session holds it, coordinating work, assigning tasks, and synthesizing results.
• Dynamic workflows — a script holds it. A workflow moves the plan into code.

Anthropic draws that line directly: use subagents when you need quick, focused workers that report back; use agent teams when teammates need to share findings, challenge each other, and coordinate on their own. And one near-miss: a background bash command doesn't spawn an agent.

Agent Teams Coordinate Peers

Teammates work independently, each in its own context window, and communicate directly with each other — the difference from subagents.

• Teams don't isolate teammates in worktrees, so two teammates editing the same file leads to overwrites — break the work so each owns a different set of files.
• Consent does not delegate: a teammate denied an action can't relay it to another teammate to bypass the check.
• Teammates cannot spawn their own teammates, and the main session is the lead for its lifetime.

Coordination is explicit: a teammate shares results by messaging the lead or updating the shared task list. And they cost more: teams use significantly more tokens than a single session, and for sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective.

When the Plan Belongs in a Script

A dynamic workflow is a JavaScript script that orchestrates subagents at scale, written for the task you describe. What it buys is context, not concurrency: the script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer. A script can even have independent agents adversarially review each other's findings before they're reported.

The price is your absence: there is no mid-run user input, so every decision is encoded before the run starts. So run the workflow on a small slice first to gauge the spend.

Isolation Is Not Coordination

The common failure in parallel work is two agents editing one file — a different problem with a different answer: worktrees isolate file edits, while subagents and agent teams coordinate the work itself.

A git worktree is a separate working directory with its own files and branch, sharing the same repository history and remote as your main checkout, so edits in one session never touch files in another. They require a git repository; outside one, sessions aren't isolated from each other. Claude Code blocks commands that reach back into the main checkout, and you can't turn this check off. Removing a worktree deletes the worktree directory and its branch, along with all the work in them.

Handing Off, and What Crosses Between Agents

A background session is a full Claude Code conversation that keeps running without a terminal attached, so you can open it, reply, and leave whenever you want. A subagent it spawns lands its file edits in the session's worktree rather than your working copy. And because it runs autonomously, it can't ask clarifying questions — the brief is the whole job.

Between sessions, a message is a piece of text one Claude writes to another, never conversation history or files; to move a whole conversation or its context, resume the session instead. No message from any agent counts as your approval for a pending permission prompt.

Splitting the Work Before You Delegate It

Decomposition is about ownership, not size: one agent, one set of files, one deliverable.

Fan out when the pieces are independent — each subagent explores its area independently, then Claude synthesizes the findings — which works best when the research paths don't depend on each other. Chain them when they do, so each passes relevant context to the next subagent.

Decide before editing, because letting Claude jump straight to coding can produce code that solves the wrong problem. And pilot anything repetitive: refine your prompt based on what goes wrong with the first 2-3 files, then run on the full set.

The Grader Must Not Be the Worker

Claude stops when the work looks done, and without a check the only thing deciding the agent is finished is the agent itself. So the longer Claude works unattended, the more an independent check matters — move the grading off the worker.

• Give Claude something that produces a pass or fail, and the loop closes on its own — then ask for the test output, the command it ran and what it returned, not an assertion.
• Review in a fresh context. A reviewer in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it won't be biased toward code it just wrote — which is how the agent doing the work isn't the one grading it.

A goal adds a separate evaluator that checks your condition after every turn, so completion is decided by a fresh model rather than the one doing the work. Code Review is the same shape at scale: each agent looking for a different class of issue, then a verification step checks candidates against actual code behavior.

The trap sits inside the solution: a reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. So put the constraint in the brief — flag only gaps that affect correctness or the stated requirements — because chasing every finding leads to over-engineering. An unfiltered reviewer is not a stricter one.

Where a Repeatable Workflow Lives

Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat. For a guarantee rather than guidance, hooks are deterministic: they fire at fixed lifecycle points rather than at the model's discretion. Guidance belongs in a skill, enforcement in a hook, orchestration in a script.

Where to Go Next

Claude Code collects the subject. Claude Code Basics is the page underneath this one, and where compaction and /rewind live. MCP Integration in Claude Code adds the tools these agents reach for. AI Agents Basics generalises what changes once any assistant is given tools, and Prompt Engineering for Code covers the brief a delegated worker has to succeed from.

Sources

Official Anthropic documentation for Claude Code. Agents · Subagents · Agent teams · Workflows · Worktrees · Agent view · Cross-session messaging · Common workflows · Best practices · Glossary · Goal · Code Review · Skills