Decompose and orchestrate, chaining, map-reduce and well-delegated subagents

A pension fund sends, in a single request, the template of a 200-page regulatory filing, last year’s filing and all the source spreadsheets, and asks for the complete document. It comes back with missing sections, figures in the summary that don’t match the tables, and some parts much weaker than others. Raising the output limit produced longer drafts with the same problems. When a task fails in parts, what it calls for is decomposition, not a model with more context.

In the domain’s first lesson you saw when multi-agent is justified (parallelism, context that doesn’t fit, many tools). Here the focus is how to cut the work and how to delegate it.

Three ways to cut

Shape of the work	Decomposition	Example
One large deliverable with parts that depend on a common plan	Prompt chaining: outline, parts, check	Filing with 14 mandatory sections
Many independent items and an aggregated result	Map-reduce: one step per item, then aggregation	300 contracts against a 12-clause policy
Open-ended research split into independent fronts	Orchestrator-workers	Market landscape of 40 companies

Chaining. First an outline; then each section with only its own data (if it’s already split by spreadsheet, even better); finally a check step that verifies the summary figures match the tables. Between steps there are checks in code: if a section is missing, the chain doesn’t move on.

Map-reduce. Each item is processed separately and returns a fixed schema (the 12 findings for each contract, with their evidence). Aggregation works on structured data, not free text, so the portfolio counts are done in code and don’t contradict each other. If there’s no rush, the “map” step fits batch processing: the Message Batches API processes asynchronously and at a lower cost.

Where to cut

Cut along the unit that is independent. In the contracts case, splitting by clause (12 agents, each reading all 300 contracts) repeats the context problem twelve times; splitting by contract means each step reads a document only once. The question is: which part can be processed without seeing the others?

A single agent that reads in order while taking notes doesn’t work either: notes help in long tasks, but a sequential agent keeps accumulating context and doesn’t take advantage of the independence.

Delegating well to subagents

In a typical orchestrator-workers trial three things happen: two subagents research the same thing, one returns 30 pages of raw notes and the orchestrator runs out of context while merging. Each has its fix:

• Duplicated work → each subagent gets a clear objective and explicit boundaries: which companies are its and which aren’t.
• Unmanageable results → a fixed output format and a condensed summary with sources, not the transcript.
• Tools → just the ones its part needs, not all of the system’s.

What doesn’t help: letting subagents message each other freely to coordinate (it adds complexity and tokens that the orchestrator’s boundaries avoid), or running them one after another to review each result (it loses the parallelism that justified the design).

The usual traps

• One giant request with the instruction “cover everything well and evenly”.
• A model with the largest window and even more reference material.
• Writing the executive summary first, before the sections it summarizes.
• Splitting by criterion when the independent units are the items.
• Aggregating free text instead of structured outputs.
• Subagents without boundaries or format, negotiating among themselves.

In the exam

Identify the shape of the work: a deliverable with parts, many independent items or research that can be split. Then look for the option that cuts along the independent unit and aggregates over structured data, with a check step at the end. If the scenario says it isn’t needed in real time, add batches. And if it describes a multi-agent trial with duplication or an overloaded orchestrator, the answer is objectives with boundaries, a fixed format and condensed summaries.