Claude Code’s workflow orchestration can spawn independent agents, run them concurrently, and verify their output adversarially before it reaches you. Almost everyone who tries it reaches for the same default first — run a batch, wait for all of it, then start the next step — and that default is the one setting that throws away most of what makes orchestration worth the added complexity in the first place.
- 01A barrier between stages is a choice, not the default shape of the work. Every item waits for the slowest item in the batch before anyone can move on — even the ones that finished minutes ago.
- 02Pipelining removes that wait without changing the total work done. Each item advances through every stage the moment its own prior stage finishes, instead of on a synchronized clock shared with the slowest item in the batch.
- 03A barrier is still correct sometimes — when a later stage genuinely needs every earlier result at once (deduping findings, an early-exit check, a count-everything-then-decide step).
- 04Verification is a separate axis from speed.Independent skeptics trying to refute a finding catch plausible-but-wrong output that a single confident pass won’t.
The pitch for running several agents at once is easy to say and easy to get wrong in practice: “do five things in parallel instead of one thing five times.” That much is true, and it’s also the smaller half of the idea. The larger half is about what happens betweenthe five things and whatever comes next — and that’s the part most setups get backwards without anyone noticing, because the wrong version still works. It’s just slower than it looks like it should be.
01 The instinct that costs you
Here’s the shape almost everyone builds first, because it’s the shape that’s easiest to reason about: run a batch of agents at once, wait for every one of them to finish, collect the results, and only then start the next step — verifying, synthesizing, whatever comes after. Call this a barrier. It’s not wrong. It’s the correct shape for some jobs. It is also, by default, the shape that makes your fastest agents sit idle waiting for your slowest one, every single stage.
02 Same nine minutes, two shapes
Three agents, two stages: a find pass of uneven length (a fast lookup, a medium search, a slow deep-dive), followed by a fixed two-minute verify pass on whatever each one found. Same three agents, same total work, same nine-minute floor set by the slowest chain — arranged two different ways.
Nothing about the total floor moved — the slow agent still sets the nine-minute ceiling for the batch either way, because nothing can make its own chain shorter. What moved is everything abovethe floor. Under the barrier, the fast agent’s real work finishes at minute four and then sits doing nothing for five minutes, because verification for everyone starts on the slow agent’s clock. Under the pipeline, the fast agent’s result is fully verified and usable at minute four — five minutes sooner, for free, because nothing was stopping it except the barrier itself.
That’s the whole trick, and it costs nothing to adopt: a pipeline runs each item through every stage independently, with no synchronization between items. The default instinct — batch, wait, batch, wait — is a barrier at every single stage boundary, whether the job needs one there or not.
03Verification is not “did it finish”
Speed is one axis. Whether you trust the output is a separate one, and orchestration earns its keep here too — not by running faster, but by running the same finding past several independent minds before it’s allowed to count as real.
Don’t ask three agents to confirm a finding. Ask three agents to try to kill it. A claim that survives skeptics actively looking for the reason it’s wrong is worth more than a claim three agents nodded along to.
The pattern, paraphrased from how adversarial-verify stages are typically framedThe difference sounds small and isn’t. An agent asked “is this finding correct?” will very often agree with itself, because the finding is already phrased as plausible. An agent asked “try to prove this finding wrong, and default to refuted if you’re not sure” has to do actual work to let it stand. Run that refutation three times independently and only keep what survives a majority — and the false-positive rate on a review pass drops sharply, at the cost of running verification at all.
Eight of twelve looked real on first read and didn’t survive someone actively trying to break them — not because the first pass was careless, but because a single confident explanation and a correct one read identically from the inside. Adversarial verification is what tells them apart.
When it’s worth the overhead
Reach for a pipeline by default, not a barrier
Unless a later stage genuinely needs every earlier result at once — deduping across the whole set, an early-exit check, a compare-everything decision — a barrier between stages is a cost you’re paying without asking for it.
Fan out when the angles are genuinely different
Five agents reading the same file the same way is five times the cost for the same answer. Fan out earns its keep when each agent searches differently — by container, by content, by entity, by a different lens on the same claim.
Don't fragment a single coherent piece of judgment
A page of prose, one design decision, one architectural call — these need one continuous train of thought holding context, not five agents each seeing a slice. Orchestration is for breadth, not for splitting a single decision nobody should split.
Only verify adversarially when being wrong is expensive
Three skeptics per finding is real overhead. Spend it on claims that will drive an action — a fix, a merge, a published number — and skip it on throwaway exploration nobody will act on unverified.
05 My read
The interesting failure mode in agent orchestration isn’t using it when you shouldn’t — that’s usually obvious once the bill or the latency shows up. It’s using it correctly in every way except one invisible default, and never noticing the five minutes you left on the table because the output was still right, just later than it needed to be. The fix costs one design decision made up front, not a rewrite: ask whether the next stage actually needs the whole batch before you make everyone wait for it.
- The nine-minute example is illustrative, not measured. The numbers are chosen to make the barrier-vs-pipeline gap legible at a glance, not pulled from a benchmark run — real timings depend on the specific agents, prompts, and workload.
- “12 raw findings, 4 survived” illustrates the adversarial-verify pattern’s shape, not a single controlled experiment with a fixed methodology — the actual survival rate varies a great deal by task and reviewer prompt.
- A barrier is the right call often enough that it shouldn’t be treated as a bug. This piece argues for making it a deliberate choice, not for removing it — plenty of real pipelines need one.