Agent Architecture and Orchestration
Task Decomposition — Stack
Task decomposition › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The mechanism determines how boundaries are drawn, whether they can be checked, and what happens to pieces that fail.
- Determinism of the split. Whether the same input always yields the same pieces, which decides whether results can be cached and whether a retry resumes or restarts.
- Boundary quality control. Whether anything verifies that a piece is self-sufficient before it is dispatched, or whether that is discovered from the answer.
- Dependency expression. Whether pieces can declare what they need from each other, and whether a scheduler can read those declarations.
- Fan-out control. Whether breadth and depth can be capped, and what happens at the cap — refusal, coarser pieces, or silent truncation.
- Piece idempotency. Whether re-running a piece is safe, which is the prerequisite for any retry policy that is not manual.
- Rejoining mechanism. Whether results are combined structurally or by a model, and whether that step has a size limit of its own.
- Resumability. Whether completed pieces survive a failure of the surrounding run.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Hand-written splitters for known shapes (per file, per record, per section) | Recurring structured inputs where the right boundary is already known | Does not generalise; a new input shape means new code, and the split is only as good as the structure |
| Map over a collection with the model as the mapper | Bulk work where the collection is the natural unit and items are independent | Per-item cost multiplies quickly; items that reference each other break the independence assumption |
| Model-generated piece lists validated against a schema | Open-ended goals where boundaries cannot be known in advance | Piece quality varies run to run; validation catches shape, not whether the boundary makes sense |
| Hierarchical division with explicit depth limits | Large goals that genuinely nest, such as multi-document analysis | Limits are guesses; too shallow leaves oversized pieces, too deep fragments the work into noise |
| Workflow-engine dynamic fan-out (Step Functions map states, workflow child executions) | Durable bulk processing with per-piece retries and visibility | Engine concurrency limits and payload size caps shape the division more than the problem does |
| Framework fan-out primitives (graph-runtime send and parallel branch constructs) | Agent runtimes that already manage state and want division inside the same graph | Rejoining semantics are framework-defined; non-trivial merges end up written around the primitive |
| Retrieval-oriented chunking as the division | Document-shaped work where the pieces are passages | Chunk boundaries optimised for retrieval are usually the wrong boundaries for reasoning |