PM-301f · Module 1

When to Decompose

4 min read

The single-prompt limit is not primarily a token limit — it is a coherence limit. A prompt that asks a model to do too many distinct things in a single call produces outputs that are coherent on none of them. The model cannot maintain complete fidelity to ten simultaneous requirements across a long generation. It satisfies some and drifts on others.

The diagnostic question is not "how long is this task?" It is "how many distinct things does this task require?" A single task that requires synthesis of multiple document sources, construction of multiple distinct output formats, and application of multiple independent rule sets is a decomposition candidate — not because it is long, but because its requirements are heterogeneous.

  1. Signal 1: Ambiguous Scope If you cannot state the task's output in a single sentence without qualifications, the scope is ambiguous. Ambiguous scope in a single prompt produces ambiguous output. Decompose: separate the scope clarification from the execution, or decompose the execution into scoped sub-tasks.
  2. Signal 2: Multiple Output Types A task that requires both a JSON summary and a narrative explanation and a numbered action list is three tasks. Each output type has different format requirements. Combining them in a single prompt produces inconsistent compliance on all three. Separate them.
  3. Signal 3: Long Reasoning Chains Tasks that require more than 5-7 reasoning steps before reaching a conclusion are prone to error accumulation. Each reasoning step introduces potential for error. Decompose into checkpointed sub-tasks where each intermediate conclusion can be validated before the next step depends on it.
  4. Signal 4: Contradictory Constraints When a task has constraints that pull in opposite directions (maximize detail AND minimize length; be comprehensive AND be concise), the model negotiates a compromise rather than satisfying either. Decompose: separate the comprehensive draft from the condensed summary. Both can be done well; neither can be done simultaneously.

Do This

  • Decompose when the task has multiple distinct output types
  • Decompose when the reasoning chain is long enough that intermediate errors compound
  • Decompose when constraints are heterogeneous across sections of the task
  • Keep the task in a single prompt when the output is homogeneous and the reasoning is linear

Avoid This

  • Decompose every task by default — decomposition has overhead; apply it when it solves a problem
  • Decompose based on task length alone — a long single-output task may not need decomposition
  • Decompose without mapping dependencies first — incorrect dependency order propagates errors
  • Over-decompose into trivial single-sentence sub-tasks that each make one API call