Judging a Sub-Question Decomposition
A deep research agent is asked "should we expand into the European market?" and the planning step produces this decomposition:
-
What is our current market share in comparable markets?
-
What regulatory hurdles exist for our product category in the EU?
-
Given the answer to (1), which specific countries should we target first?
-
What do European customers in this segment say they need that current offerings don't provide?
-
Identify the problem with this decomposition as a plan for parallel sub-agent execution, and explain precisely why it's a problem.
-
Propose a fix, and say whether your fix changes the number of sub-agents, the number of planning rounds, or both.
-
Would you rather catch this failure at plan-review time or after all four sub-agents have already run? Justify your answer with the cost/latency stakes involved.
1. The problem
Sub-question 3 explicitly depends on the answer to sub-question 1 ("given the answer to (1)") — it cannot be researched independently and concurrently with (1), because a sub-agent assigned to (3) has nothing to condition on until (1)'s sub-agent has actually finished and reported back. Dispatching all four as if they were independent, parallel sub-tasks either produces a sub-agent for (3) that has to guess at (1)'s answer or silently ignore the dependency and answer a different, unconditioned question than the one actually asked.
2. The fix
Split into two rounds: round 1 dispatches sub-questions 1, 2, and 4 in parallel (all genuinely independent); round 2, run only after round 1's supervisor has aggregated results, dispatches a reformulated sub-question 3 that's now given round 1's market-share finding as context rather than asking a sub-agent to answer a conditional it can't resolve on its own. This changes the number of planning rounds (one round becomes two) more fundamentally than the number of sub-agents — the total sub-agent count might stay at four, but they no longer all dispatch and run concurrently in one wave.
3. When to catch it
At plan-review time, decisively — the whole point of treating plan generation as worth reasoning-tier spend is that a bad decomposition corrupts everything dispatched from it, and this dependency is exactly the kind of structural flaw a stronger model (or an explicit plan-validation check: "does every sub-question in this plan avoid referencing another sub-question's answer?") can catch before any sub-agent work happens. Catching it after all four have already run means round 1's compute was fine but sub-agent 3's entire run was wasted — full cost and latency spent on research that has to be redone anyway once the dependency is noticed, which is strictly worse than a cheap validation check before dispatch.
Share this question