Fan Out Big Jobs With Subagents

Some jobs are big because they are many small jobs wearing a coat: fifty documents to read, thirty files to review, a hundred rows to check. Subagents are how an idapt agent splits that coat: an orchestrator delegates pieces to parallel workers and merges what comes back.

The shape

You ask one agent for the outcome. It spawns subagents, each with a narrow brief and its own context window, waits for their results, and synthesizes. You see the fan-out in the run trace; you talk only to the top.

Why the split beats one heroic context: each worker reads its piece with full attention (no middle-of-a-huge-context blur), failures are contained and retryable per piece, and wall-clock time collapses toward the slowest single piece.

Three patterns that carry most jobs

Map: one subagent per document, same brief ("extract the claims and evidence"), merged into a matrix. The spine of deep research.

Divide: split by module or section, different pieces of one deliverable ("you take the API layer, you take the UI"), orchestrator owns coherence. The spine of code migrations.

Panel: same question to subagents on different models, answers compared. Triangulation as a workflow rather than a habit; see comparing models.

Writing a good fan-out brief

Tell the orchestrator the outcome, the shape of the pieces, and the merge you want:

Read every PDF in /Sources. For each: claims, evidence quality, contradictions with the others. Then one synthesis memo with a source map.

The orchestrator handles the splitting; your job is a merge instruction worth merging into.

Good to know

• Budgets apply to the whole run, fan-out included: the worst case stays a number you set.
• Subagents inherit the run's permissions; they never exceed the parent.
• The run trace shows every worker's brief and result: auditable, not magical.

Hand a folder of ten documents to an agent with the brief above; the subagent feature page covers depth limits and controls.