What blocks skill retrieval in task decomposition?

When routing a query across a large skill library, the failure cascades from the top. Standard LLM decomposition reaches only ~34% category recall at the step level — meaning the sub-tasks it produces often don't correspond to the skills that exist. Because retrieval can only find skills for the steps it's given, decomposition granularity gates retrieval: get the step count wrong and no amount of good retrieval recovers. A conditioning analysis makes this concrete — supplying the correct decomposition raises top-1 category recall, and ~75% of an iterative fix's gain comes precisely from queries where the vanilla model produced the wrong step count; on already-correctly-decomposed queries the fix's per-step benefit is statistically zero.

So the iterative, retrieval-augmented decomposition method (SAD) is best understood as a granularity corrector, not a vocabulary-alignment learner — it repairs how finely the query is carved, not which words map to which skill. That precision about what is being fixed is the useful part: it tells you the next lever isn't more decomposition. Pinning step count to ground truth recovers decomposition accuracy but still leaves a large residual gap to the retrieval ceiling, which relocates the bottleneck to representation-level reranking — a cross-encoder reranker over the top candidates is shown to lift recall further, moving reranking from speculative future work to a validated, composable lever.

This is a cascading-bottleneck result: fix the gating stage (decomposition), and the binding constraint moves downstream (reranking), which is why it belongs alongside How should agents route across thousands of skills?. It generalizes the decomposer-first lesson: since Does separating planning from execution improve reasoning accuracy?, the decomposition stage deserves its own diagnosis and its own fix rather than being tuned implicitly through end-to-end accuracy.