Parallel Research with Subagents: One Orchestrator, Four Threads, a Brief in 20 Minutes

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 system — which ships Claude Opus 4 as orchestrator with Claude Sonnet 4 subagents — reports 90.2% better performance over single-agent Claude Opus 4 on complex research tasks.^[1] That number comes with a precise caveat Anthropic documents explicitly: token volume alone accounts for 80% of success variance on the BrowseComp evaluation.^[1] The wall-clock advantage is real. What drives it is compute surface area, not magic decomposition.

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 don't communicate during execution. That isolation cuts the coordination tax to zero and keeps every context window clean.^[2] Attention is quadratic in sequence length — a single 20K-token pass costs 25x more than a 4K pass. Keeping each subagent's context narrow isn't architectural tidiness, it's an economic necessity.

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 — and the phase most often written as "summarize these reports," which produces nothing actionable.

Microsoft's multi-agent orchestration documentation and Anthropic's engineering post both describe the same topology from different implementation angles.^[1][2] The architectural consensus as of 2026 has converged on one pattern: orchestrator plus isolated subagents that return summaries, not full context.

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. The table below maps them — notice that each thread specifies not just what to investigate, but explicitly what falls outside its scope.

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 follows a predictable shape. Here's what the orchestrator generates internally for each thread.

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. This isn't just architectural cleanliness — concatenating five agents into one prompt costs 5x more in attention compute and exposes answers to position bias, where agents in the middle of a long prompt receive less attention weight than those at the edges.^[7] Separate contexts solve both problems at once.

Bounded resources. No subagent gets 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 sets the budget at decomposition time, not in flight. One slow subagent drags the entire synthesis window if you skip this.

Progress tracking. Promise.allSettled() in JavaScript (or its equivalent elsewhere) is the right primitive — it waits for every promise to resolve regardless of individual outcome. Promise.all() aborts on the first rejection. In a four-thread research run, that means one flaky API destroys the pipeline. Fire-and-forget is not progress tracking; it's 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's 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 can't 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.

Production data on multi-agent deployments is sobering: 40% of agentic AI projects fail to deliver expected returns.^[8] Context window overflow is among the most common architectural failure modes — the orchestrator accumulates context from every worker, and at four or more workers with rich outputs, the orchestrator's own window frequently exceeds limits.^[4] The fix is structured reports: subagents return summaries, not raw tool outputs.

Every subagent report carries a structured status field. That structure is what lets synthesis weight 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.

One thing we got wrong early: synthesis prompts that naively averaged confidence scores across threads. A 70% finding from the incident log and a 70% finding from the experiment tracker don't 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" isn't a rule. It's an abdication.

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 simultaneously. Eighteen minutes of parallel execution later, here's 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. Notice how the partial failure on thread 2 (70% completeness) reduces confidence on the SEPA hypothesis rather than silently disappearing.

The 90.2% performance lift Anthropic reports is real — for the right question type. On the wrong one, confident decomposition actively damages the output.

Parallel research machines work best on well-structured recurring questions where the causal categories are known in advance: "What changed?" "What broke?" "What did competitors do?" The decomposition almost writes itself.

They work badly on truly novel questions where the relevant dimensions are themselves uncertain. When you don't know what you're looking for, an orchestrator that confidently spawns four threads in four directions can miss the fifth direction that actually matters. A single thoughtful agent exploring iteratively — following the thread, noticing the unexpected signal, changing tack — will often produce better output. You also spend three cycles refining a decomposition that was wrong from the start, and the wall-clock advantage evaporates.

A contrarian threshold worth using: if you can't write the decomposition table before you see any findings, the question probably isn't ready for parallel execution.

Massive infrastructure isn't 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. What matters most is what you build it around.

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. Log every decomposition. Review the ones that produced weak briefs. The failure mode is almost always one of three things: boundaries too narrow (subagents finish instantly with nothing), boundaries too broad (subagents time out), or synthesis averaging (no hypothesis breaks 30% confidence).

Token volume is the primary lever. Anthropic's research makes this explicit: token usage explains 80% of success variance on BrowseComp, with model choice and tool call count as the other two factors.^[1] That means your primary cost optimization is controlling subagent token budgets — not prompt brevity.

Use a capable but efficient model for subagents and reserve the most capable model for orchestration and synthesis, where reasoning depth carries the weight. Anthropic's own system uses Claude Opus 4 for the orchestrator and synthesis pass, Claude Sonnet 4 for the research subagents.^[1] One operational caution: mixing model families makes debugging harder when outputs look stylistically inconsistent. Standardize on one family per tier and document the routing logic.

Caching is the other high-impact optimization. Many research questions share subqueries. If the competitive monitor scanned the DACH market yesterday, today's run starts from cached results and only checks the delta. A competitive intelligence subagent that runs daily can cache its baseline and compute incremental updates in a fraction of the token budget.

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 improves quickly with iteration on the templates — but only if you're logging the decompositions and reviewing the weak briefs.

The wall-clock won't 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, serial research starts feeling like coordination tax you no longer have to pay — and you start recognizing every recurring question that deserves its own machine.