Ask Claude Code why signups dropped this week and one conversation will pull the numbers, find a reason, and then, if you ask, confirm that its own reason holds up. That last step is the weak one. The same mind that made the guess is grading it. Even the colleagues I'd call good Claude Code users work this way, one Claude at a time, because nobody told them there's another option. You can run a small team instead: several agents, each with one job and a clean slate, and one of them there only to catch the others' mistakes. You can ask for it in a single sentence.
Two situations call for it. The job is too big for one conversation to hold at once, like fifty documents, a long queue, or a report with many parts. Or the answer matters enough that the agent who produced it shouldn't be the one who checks it, like a number going into a board deck or a decision about money. A longer prompt fixes neither. Splitting the work can: more material covered, and an answer tested from several angles, as long as each agent gets the evidence it needs. I call drawing that split graph engineering: boxes for the agents, arrows for what they hand each other.
By the end of this post you can:
- have three agents check a number before it goes in front of anyone,
- work through a queue where only the risky items get a second look,
- assemble a report from several writers who all follow one brief,
- point each of these at your analytics, error tracking, ad accounts and tracker,
- and tell when a team is overkill.
This is the second of six posts on getting more out of Claude Code. If you're new to this, the first one, on loops, is the easier starting point; the others cover setting up work that repeats every week, teaching Claude your job once, putting it on a schedule, and sharing one tracker with your agents.
What a team of agents looks like
Each agent gets exactly one job. Ask for fresh agents and each one starts with only the task and the material you hand it, not your whole conversation, so it hasn't absorbed your assumptions or your earlier drafts. That makes it harder to inherit a mistake, though agents can still share blind spots. For a real check, keep the checkers from seeing each other's conclusions until the final review.
When the next step depends on a result, ask agents to return named fields, like finding, evidence, and severity, rather than a page of prose. Then the next step can act on "severity: major" without rereading five hundred words. And in every team worth running, one agent's only job is to try to prove the others wrong.
How to ask for one
In Claude Code, you ask in plain words. Put the word ultracode in your request, or just say "use a workflow", and Claude writes a small plan of agents, shows you the phases, and runs them in the background after you approve. You can keep working while it runs, and /workflows shows each phase and what every agent found. On the Pro plan, turn on Dynamic workflows in /config first.
The fastest way to see one is the workflow that ships with Claude Code:
/deep-research What are the main arguments for and against a four-day
work week, based on studies published since 2022?
It sends agents out to search from several angles, checks the sources against each other, and gives you one cited report, with claims that didn't survive the cross-check filtered out. When a run of your own does what you wanted, open /workflows, select it, and press s to save it as a command you can run again by name.
A team costs more than a single conversation, in tokens and in time. Try it on a small slice first, like one folder instead of the whole drive, and watch the cost in /workflows before you run it on everything.
Check a number before it goes in the deck
This is the one I reach for most. When a number is about to change a decision, one agent recomputes it from scratch, one attacks the method, and one accepts the number but argues for a different explanation. A fourth reads all three and writes the verdict.
I've used this before acting on business metrics, with separate agents testing the calculation, the method, and other explanations, and once with a whole run built only to try to break one number that would have changed a program's direction. It's the cheapest insurance I know against presenting something wrong.
The prompt needs the evidence, not only the claim. An agent can't recompute a number it doesn't have the data for:
use a workflow to check this claim before I present it: <the claim>.
The data is in <file path> and the original calculation is in <file
path>. Use this metric definition and period: <definition, dates>.
Have three separate agents check the calculation, the method, and
other explanations. Then have one final reviewer weigh their findings.
Mark each point as supported, refuted, or unverified. Only mark it
refuted with contradicting evidence, and mark it unverified if data is
missing. Return the verdict, the sources, and any corrected number.
With connected tools, the agents can pull the evidence themselves instead of waiting for you to export it. Say your onboarding completion rate fell 8 points this week. The three explanations that usually compete are a real problem in the app, a tracking change that only looks like one, and a different mix of people arriving, often from a new ad campaign. Give each of them an agent:
use a workflow to explain why onboarding completion dropped from <old
rate> to <new rate> between <dates>. Read only, change nothing. One
agent recomputes the rate from raw events in PostHog. One checks
whether any event, screen or tracking code changed in releases during
that period. One compares where new users came from, using our ad
accounts and PostHog's source data. One checks error tracking for new
errors on onboarding screens. Then one reviewer weighs all four and
says which explanation the evidence supports, marking anything
unproven as unverified.
The agent that looks at tracking changes earns its place more often than you'd think. A renamed event makes a funnel step look empty, and a team can spend a week fixing an onboarding screen that was never broken.
The trap is asking one agent to check its own work. It tends to find its typos and miss its blind spots, because the blind spot is exactly what it didn't think to check the first time.
Give every item one check, and a second only when it's needed
This one fits any queue: support tickets, requests, applications, reviews. Most items are fine, a few aren't, and you can't tell which up front.
For a batch of support tickets, one agent read each full thread and drafted a reply, and a second, independent agent rechecked every fact in the draft against the source and rated each problem as blocker, major, or minor. Only a blocker or a major sent the draft back for revision and a fresh check. At the end, one more agent read across the whole batch for things a single ticket can't show, like the same customer on two tickets with different facts. And no agent could send, tag, or update anything. Everything came out as a draft for a person to read.
use a workflow on the tickets in <folder or file>. Use <reference docs
or past replies> as the source of truth. Draft replies only: never
send, tag, or update anything. For each ticket, one agent drafts a
reply and a separate agent checks every factual claim against the
sources. Rate problems as blocker (unsafe or not allowed), major (a
wrong fact that changes the advice), or minor (wording). Revise and
recheck only blockers and majors, once. Leave anything still unclear
for me. Finish by checking the whole batch for contradictions.
An app's error tracking is the same kind of queue. Most new errors are noise, a few are real crashes, and a handful of those are easy fixes. One agent per error can read the stack trace and find the cause in the code, and a separate agent checks that the proposed fix actually addresses that trace and that the tests pass:
use a workflow on the PostHog error-tracking issues from the last 7
days that affect more than <N> users, with the <repository>. For each
issue, one agent finds the cause in the code and proposes a fix on its
own branch. A separate agent checks the fix against the stack trace
and runs the tests, and rates it: ready, needs work, or can't tell.
Open a draft pull request only for "ready", and a Linear issue with
the evidence for everything else, after checking that one isn't
already open. Never merge. End with one list for me: pull requests,
issues, and anything skipped.
Skip the rating and every item pays for the expensive second pass because you're nervous about the risky ones. The rating is what keeps the queue cheap.
Split the writing, but agree on one brief first
Anything built in parts that must fit together at the end wants this: a report with several sections, a deck, a proposal, a web page. If five agents start writing at once, each one invents its own idea of the audience, the terms, and the format, and you find out at assembly that nothing matches.
So one agent goes first and writes the brief: the audience, the outline, the terms everyone uses, the format, and what "done" means for each part. Only then do the writers start, one section each, all working from that brief. One agent puts the pieces together, and one checks the result against the brief and the sources. I first used this to rebuild a landing page: one agent set up the shared names and styles, five built sections in parallel, one assembled, one checked the build.
use a workflow to write a report that answers <the question or
decision> for <who will read it>, about <length>, from the sources in
<folder>. First, one agent writes a shared brief: outline, key terms,
citation style, and a checklist for each section. Then separate agents
write one section each, in separate files, following the brief. One
agent combines the sections. Finally, a reviewer checks the full report
against the brief and the sources and flags unsupported claims.
A weekly growth report is where this shape pays off most, because each part lives in a different tool. The brief fixes the week, the definitions and the format; then one agent reads the ad accounts for spend and cost per install, one reads the onboarding funnel in PostHog, one reads error tracking, and one reads what shipped in Linear. The assembler writes one page, the reviewer checks every number against its source, and the result goes to Slack as a draft for you to post. Without the brief, the ads agent reports the week Monday to Sunday and the funnel agent reports the last seven days, and the page quietly compares two different weeks.
The same shape works for a plan you want pressure-tested before anyone acts on it: a few agents gather facts, one drafts the plan, three critics each attack it from a named angle, and one finalizes it. Nothing gets changed along the way. The only output is a plan for you to approve.
When a team is overkill
A team is easy to reach for out of habit. I once watched a small interface change, six files, the kind of thing one person reviews in an afternoon, go through a full team anyway: twelve agents building and twelve reviewing, and it took hours instead of minutes. My rule since then: count the pieces first. If you could check the result yourself in an afternoon, one conversation and one review at the end is enough. Save the team for the number that is going in front of your board, and the queue or report too big to check by hand.
Your setup, ready this week
You're done when you can reproduce the team's answer yourself and see clearly what it's still unsure about. Honestly, I expected teams of agents to be about speed. They mostly aren't. The ones worth their cost were the ones where I didn't trust a single pass to catch its own mistake, and the speed was a side effect of running the disagreement in parallel.
The rest of this series: loop engineering, loops and graphs, skills that learn, routines, and headless project management.