The centerpiece

One task, three ways

A customer's team has a pull request touching fourteen files, due for review by Friday. Here's that one job run three ways — and, honestly, where each way breaks down.

We picked a PR review because the official docs demonstrate it in every mode. The prompts below are their documented examples; only the story around them is ours.

Way 1 — One session, one reviewer

What it looks like: you open Claude Code and ask.

Review the changes in this PR for quality, security, and test coverage.

Claude reads the changes, thinks, and reports — all in one conversation. For a small change this is the right call: no setup, no coordination, the cheapest option on the page.

Where it breaks down:

The channel fills up. Fourteen files of changes, plus the code around them, plus test output is exactly the verbose material the docs say to keep out of the main conversation.
One reviewer, one lens. In the docs' words: "a single reviewer tends to gravitate toward one type of issue at a time."

Way 2 — Subagents: side channels per concern

What it looks like: same session, but the noisy reading happens off to the side:

Have the code-reviewer subagent look at my recent changes

Each helper reads in its own memory and returns only its findings, so your conversation holds summaries instead of raw diffs. Separate concerns can run in parallel, with Claude pulling the results together — and a team can check the reviewer's definition into the repo so everyone's review runs the same way.

Where it breaks down:

Summaries still land in the main channel. Many helpers each returning detailed results add up — the side channels rejoin the same river.
The reviewers don't confer. Each reports back to the conversation that sent it; it's the main Claude that weighs security against performance. Workers that debate each other are the agent-team pattern, below.
Fresh eyes take a moment. A subagent starts without your conversation's context, so it gathers its own before it can review.

Subagents deep dive →

Way 3 — A dynamic workflow: the review as a canal

What it looks like: you describe the whole job and ask for a workflow:

use a workflow to review every file changed in this PR for correctness
issues, then merge the per-file findings into one ranked summary

Claude writes a short script — one reviewer per changed file, then a merge step that ranks the findings — shows you the plan to approve, and runs it in the background. One ranked summary arrives at the end; the intermediate findings never touch your conversation. A workflow can also have independent workers check each other's findings, and a good run saves as a command the team reruns on every branch.

Where it breaks down:

No mid-run steering. Once approved, the script runs. If a review needs your judgment halfway through, the docs' answer is one workflow per stage.
Meaningfully more tokens. Pilot a small slice first and watch usage in /workflows.
Not everywhere. Needs a recent Claude Code on a paid plan, the API, or the listed cloud providers; on Pro it's off until enabled in /config.

Workflows deep dive →

The comparison

Chart No. 2 — The same review, three routes

costs are relative; the docs publish no per-approach dollar figures

Route	Your conversation holds	Relative cost	Breaks down when
Single session	Everything — diffs, files, findings	Lowest — one worker	The material outgrows one conversation, or one lens isn't enough
Subagents	Only each reviewer's summary	Lower than a team — results come back summarized	Detailed summaries pile up, or reviewers need to discuss findings
Dynamic workflow	Only the final ranked report	Highest here — many workers; pilot a small slice	You're needed mid-run, or the scale doesn't justify it

The fourth way — marked on the chart, behind a lock

An agent team would run this as three teammates with different lenses — the docs' example, verbatim:

Spawn three teammates to review PR #142:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

What a team adds is discussion: teammates message each other, challenge each other's findings, and share a task list, with the lead pulling it together. What it costs: each teammate is a full separate Claude — the docs cite about 7× the tokens of a standard session when teammates run in plan mode. And it's experimental, off by default, with documented rough edges. Worth knowing; not the default recommendation.

So which one?

A two-file fix: review it in the session you're in. A real PR where the conversation should stay clean: subagents. A review you want exhaustive, verified, and repeatable: a workflow. Reviewers that should argue with each other: the agent-team experiment, eyes open.

If the customer's question is "which should we use" — start them at the routing questions.