Serial Research Is the Bottleneck. Subagents Run in Parallel.

Slack pings at 9:14 AM: Conversion in Germany dropped 8% last week. What happened?

You know the topology. Open the experiment tracker. Cross-reference the incident log. Scan three weeks of release notes. Check what a competitor shipped. Each source lives behind a different surface, demands its own context, and burns 30 to 90 minutes of focused attention. By the time a working hypothesis exists, the day is half spent.

Now change the topology. One question hits a system that decomposes it into four independent threads, dispatches a specialized subagent to each, waits for all four to report, and synthesizes a weighted hypothesis brief with confidence levels. Wall-clock cost: about twenty minutes when the decomposition matches the problem.

This is the orchestrator-subagent pattern for knowledge work. Anthropic's multi-agent research reports up to a 90% performance lift over single-agent runs on specific complex research tasks^[1] — with the obvious caveat that the gain depends entirely on whether the decomposition matches the problem structure. The number stops being abstract the first time you watch four subagents work the same question simultaneously while you read the brief that comes out the other side.

The pattern has three phases. Most teams that fail at this collapse two of them into one and never figure out why their briefs come out incoherent.

Phase 1: Decomposition. The orchestrator takes a question and splits it into independent threads. Independent is the load-bearing word. If thread B needs the output of thread A, they cannot run in parallel. Good decomposition produces threads that execute simultaneously without coordination.

Phase 2: Parallel execution. Each subagent runs its assigned thread inside its own context window with its own tools. Subagents do not communicate during execution. That isolation is a feature — it cuts the coordination tax to zero and keeps every context window clean.^[2]

Phase 3: Synthesis. The orchestrator collects every report and produces the unified brief. Confidence levels, weighted hypotheses, cross-thread correlations all emerge here. Synthesis is the phase that turns raw findings into a decision.

Microsoft's multi-agent orchestration guidance and Anthropic's multi-agent research are worth reading alongside this — they document the same topology from different angles.

Decomposition is where the orchestrator earns its keep. Split the question badly and your subagents either duplicate each other's work or miss the angle that matters. Split it well and the brief lands in a window no single analyst could match.

Take the live example: Why did conversion drop 8% in Germany? A capable orchestrator splits this into four independent threads, each owning a different causal category.

Every subagent gets four things: an objective, an output format, tool guidance, and a scope boundary. The boundary is the part teams skip. Without it, subagents drift outside their lane and burn tokens exploring territory another thread already owns. Vague task descriptions produce vague results. Vague results poison synthesis.

The decomposition prompt itself follows a predictable shape. Here is what the orchestrator generates internally.

Once the task list exists, execution is mechanically simple but operationally strict. Three concerns dominate.

Isolation. Each subagent runs in its own context window with its own tool sessions. No shared state during execution. If subagent A discovers something subagent B should know, that connection is made during synthesis — never mid-flight. Shared state during execution introduces race conditions and debugging nightmares.^[4]

Bounded resources. No subagent gets to consume disproportionate compute. Token budget per thread. Wall-clock timeout per thread. Simple fact-finding gets 3-10 tool calls. Deep analysis might need 30+. The orchestrator picks the budget at decomposition time, not in flight.

Progress tracking. The orchestrator needs to know which subagents have finished, which are still running, which have failed. Promise.allSettled() in JavaScript or its equivalent elsewhere is the right primitive — it waits for every promise to resolve regardless of individual outcome. Fire-and-forget is not progress tracking. It is hope.

Subagents fail. APIs go dark. Rate limits trigger. Context windows overflow on a dataset nobody sized for. The question is never will something fail — it is what does the system do when it does.^[4]

The worst design treats failure as binary: every subagent succeeds or the run aborts. Real analysis tolerates partial information all the time. A senior analyst who cannot reach the incident log still produces a useful brief from the other three sources — they just flag lower confidence on the infrastructure angle.

The parallel research machine has to behave the same way. Otherwise one flaky API takes the whole pipeline down on a recurring basis, and the team learns to distrust the system.

Every subagent report carries a structured status field. That structure is what lets synthesis weight the findings honestly instead of averaging away the gaps.

Synthesis is where the orchestrator-subagent pattern diverges from simple parallelization. The naive version concatenates reports and asks the model to summarize. The result is a worse version of what the subagents already produced separately.

The sharp version asks the model to reason across reports — find correlations between threads, weigh evidence by completeness, flag contradictions instead of averaging them away, and assign confidence levels to ranked hypotheses.

The synthesis prompt has to do five things: ingest every report with its completeness metadata, identify convergent evidence across threads, generate ranked hypotheses, assign confidence scores tied to evidence weight, and surface the gaps that cap confidence.

Trace the full pipeline against the running example. The product lead asks: Why did conversion drop 8% in Germany last week?

The orchestrator splits the question into four threads and dispatches subagents. Eighteen minutes of parallel execution later, here is what comes back.

The orchestrator feeds all four reports into the synthesis prompt. What comes out is structured enough for a product lead to act on immediately.

Massive infrastructure is not the prerequisite. The pattern works on any LLM with tool use, and the orchestration logic fits in a few hundred lines of TypeScript or Python. The thing that matters most is what you build around.

One thing we got wrong early: we wrote synthesis prompts that naively averaged confidence scores across threads. A 70% finding from the incident log and a 70% finding from the experiment tracker do not combine to 70%. Either they reinforce — pushing confidence higher — or they describe different causal factors and should stay separate. Synthesis prompts need explicit rules for combining versus stacking evidence. "Produce a summary" is not a rule. It is an abdication.

Multi-agent runs consume roughly 15x the tokens of a single chat — a rough estimate that swings significantly with subagent complexity. The cost is justified when the alternative is 4 to 8 hours of senior analyst time. It still demands attention.

A contrarian point worth holding: parallel research machines work best on well-structured recurring questions. They work badly on truly novel ones. When the question itself is ambiguous — when the dimensions that matter are themselves uncertain — an orchestrator that confidently decomposes and dispatches can do worse than a single thoughtful agent exploring iteratively. The wall-clock advantage evaporates when you spend three cycles refining a decomposition that was wrong from the start.

The primary tuning levers are token usage, tool call frequency, and model selection. Use a capable but efficient model for subagents — Claude Sonnet 4 handles most research threads — and reserve the most capable model (Claude Opus 4) for orchestration and synthesis where reasoning depth carries the weight.^[2]

Caching is the other high-impact optimization. Many research questions share subqueries. If the competitive monitor scanned the market yesterday, today's run starts from cached results and only checks the delta. Gartner reports a surge in multi-agent system inquiries between 2024 and 2025^[6] — the tooling is maturing, but enterprise adoption is early and the patterns are still settling.

Nobody adopts the orchestrator-subagent pattern wholesale. Pick one recurring question that costs the team more than two hours every time it surfaces. Map the data sources. Write the decomposition template. Build a minimal orchestrator that spawns subagents, collects reports, runs the synthesis prompt.

The first run will be rough. The decomposition will miss an angle. A subagent will fail in a way nobody anticipated. The synthesis confidence levels will feel arbitrary. All of that is expected, and all of it improves quickly with iteration on the templates.

The wall-clock will not feel rough. The first time a weighted brief lands in twenty minutes for a question that used to eat a morning, the pattern stops needing a sales pitch. After that, decomposing every complex question into parallel threads is no longer a choice — serial research starts feeling like coordination tax you no longer have to pay.