You're designing an agent that helps the marketing team at a mid-sized e-commerce company plan campaigns. The team uses it for tasks ranging from "write me a quick subject line for tomorrow's email" to "build a quarterly campaign strategy for our new product line."
A junior teammate proposes implementing both kinds of requests through the same fixed pipeline: (1) gather context, (2) brainstorm options, (3) evaluate options, (4) draft output, (5) review draft. They argue this gives consistency.
Why is this the wrong approach?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Task decomposition strategy should match task complexity. Simple requests ("write a subject line") need maybe one step — direct generation. Complex requests ("quarterly strategy") may need adaptive decomposition where later subtasks depend on what's discovered earlier. Forcing both through the same five-step pipeline either over-engineers simple requests or under-serves complex ones. The right architecture is request-aware: the agent (or a routing layer) assesses complexity and chooses the appropriate decomposition pattern.
Dynamic decomposition has real costs — unpredictability, harder debugging, higher latency, more failure modes. For predictable workflows, fixed pipelines are more reliable, not less. The right answer is matching strategy to task, not picking one strategy for all tasks.
Adding a formatting step doesn't fix the underlying mismatch between task complexity and pipeline rigidity. This option captures the instinct to "fix the pipeline" rather than question whether one pipeline should fit all cases.
Parallelizing brainstorm/evaluate/draft for a "write me a subject line" request is incoherent — those steps depend on each other. Parallelization is a real optimization, but it doesn't address the fact that simple requests don't need all the steps in the first place.