Orchestrator and workers
By the end: Describe the orchestrator–workers pattern and identify the problems it fits.
Sectioning assumes you know the parts in advance. Often you do not: how many files a change touches depends on the change. The orchestrator pattern handles that. One model call decides what the sub-tasks are, workers do them, and the orchestrator assembles the results.
The difference from plain sectioning is that the split is decided at runtime by a model rather than in advance by your code. That is what makes it agentic, and it is also where the cost comes from: an orchestrator that decomposes badly produces workers doing the wrong work in parallel, quickly.
- Orchestrator: reads a bug report and decides which four subsystems need investigating.
- Workers: one per subsystem, each with a clean context and read-only tools.
- Orchestrator: reads the four findings and writes one explanation, naming which subsystem is at fault.
Give workers narrow briefs and narrow tools. A worker that can wander is a second agent with all the costs of the first. And have the orchestrator state its plan before dispatching, because a plan you can read is a plan you can debug — and, when it is wrong, the error is visible before the expensive part runs.