- In short
- Decomposition failure modes are the ways a single-prompt approach or a poorly ordered decomposition produces shallow, unauditable, or contradictory results. A single prompt that bundles deriving criteria, scoring, weighing trade-offs, and recommending yields a recommendation with no visible reasoning. Most decomposition failures are ordering problems - such as drafting before confirming a shared extraction - not wording problems, so the fix is restructuring into ordered steps, not asking Claude to be more thorough in one pass.
Diagnosing why a multi-stage task went wrong
The final knowledge point of the decomposition task statement is analytical: given a multi-stage task that produced a poor result, identify whether the cause was bundling everything into one prompt or ordering the steps badly, and prescribe the structural fix. The Claude Certified Associate - Foundations (CCAO-F) exam pitches this at analyse level because the credited answer requires seeing past the surface symptom - shallow, unauditable, or contradictory output - to the structural cause underneath.
The recurring insight is that these failures are almost never wording problems. A bundled request does not get better because you added more adjectives to it, and a mis-ordered sequence does not improve because you rephrased each step. The lever is structure: how the work is split and, above all, which step goes first. Reaching for wording when the problem is structure is the exact error the exam is probing.
- Decomposition failure modes
- The ways a single-prompt approach or a poorly ordered decomposition produces shallow, unauditable, or contradictory results. A single prompt bundling criteria, scoring, trade-offs, and a recommendation yields a recommendation with no visible reasoning. Most failures are ordering problems - such as drafting before confirming a shared extraction - not wording problems, so the fix is restructuring into ordered steps, not asking for more thoroughness in one pass.
The bundled-prompt failure
The first failure mode is bundling a genuinely multi-stage task into a single prompt. When one prompt asks Claude to derive criteria, score options against them, weigh the trade-offs, and recommend, all in one pass, the result is a recommendation with no visible reasoning. Every stage was done shallowly and none of it was surfaced, so you cannot see the criteria, cannot check the scoring, and cannot audit how the conclusion was reached. The output looks complete but is hollow.
The tempting non-fix is to make the single prompt more demanding - "be thorough," "show your reasoning," "consider all factors." This does not work, because the constraint is structural: one pass cannot produce and verify four distinct stages. The real fix is to restructure the bundle into ordered steps, each producing a checkable intermediate result. Recognising that shallow multi-stage output needs restructuring rather than a sterner single prompt is the heart of this failure mode.
The ordering failure
The second and subtler failure mode is a decomposition that split the work correctly but ordered it wrong. The classic example is drafting parallel deliverables before confirming the shared extraction they all depend on: the steps are all present, but because the high-stakes shared step did not go first, an error in it propagates into everything downstream. The output here is not shallow - each piece may be well-made - but it is contradictory or wrong in a way that traces back to sequence.
This is why "any multi-step breakdown is fine" is false. Two decompositions with the same steps in different orders are not equally valid; the one that confirms the foundation before building on it succeeds, and the one that builds first fails. Diagnosing an ordering failure means asking which step depended on which, and whether a step that needed a confirmed prior result ran before that result existed. The fix is to reorder - put the shared, high-stakes, or foundational step first - not to reword any individual step.
What the CCAO-F exam trips candidates on
Two traps recur, and both mistake a structural problem for a wording one.
The first is fixing a decomposition failure by adding more instructions to the single prompt instead of splitting it into steps. A scenario shows a hollow recommendation from a bundled prompt and offers "tell Claude to be more thorough" as bait. The credited reading is that thoroughness cannot be added to a single pass that has too much to do - the fix is to split the bundle into ordered, checkable steps.
The second is assuming any multi-step breakdown is equally valid regardless of which step goes first. A scenario decomposes correctly but orders the shared extraction after the drafts, and a distractor treats the mere presence of steps as sufficient. The reliable reading is that ordering is decisive: the foundational or shared step must go first, and a breakdown that gets the order wrong fails despite having all the right steps.
Worked example
A team decomposes a make-or-buy decision into steps, but their report contradicts itself: the recommendation favours 'buy' while the trade-off section leans 'build.' A colleague suggests fixing it by rewording each step to be clearer. Is that the right diagnosis, and what is the actual fix?
Rewording is the wrong diagnosis. The contradiction between the recommendation and the trade-off analysis is a signature of an ordering or structural failure, not unclear phrasing. Two structural causes are worth checking. If the whole thing was actually run as one bundled prompt that produced a recommendation alongside a trade-off summary without either being built on the other, then neither was grounded in a confirmed shared analysis, and they diverged - the classic hollow, bundled output. If instead it was decomposed but the recommendation step ran before the trade-offs were confirmed, then the recommendation rested on an unconfirmed foundation and the later, better trade-off analysis contradicts it.
Either way, the fix is structural, not verbal. Restructure into ordered steps where the shared analytical foundation comes first: derive and confirm the criteria, score each option, produce and confirm the trade-off analysis, and only then generate the recommendation from that confirmed analysis. Sequenced this way, the recommendation is forced to rest on the same trade-offs the report shows, so it cannot contradict them. Rewording each step in the current broken order would leave the contradiction in place, because the problem was never the words - it was that a conclusion was produced before the analysis it should depend on. That is the essence of a decomposition failure mode: diagnose the structure, then reorder or split, rather than polishing the language.
Common misreadings to avoid
Misconception
Shallow output from a multi-stage prompt can be fixed by instructing Claude to be more thorough.
What's actually true
Misconception
As long as a task is broken into steps, the order of those steps does not really matter.
What's actually true
How this shows up on the exam
Domain 1 questions on this knowledge point present a multi-stage task that failed and ask you to diagnose the cause and choose the fix. The reliable analysis is to ask whether the work was bundled into one pass (fix: split into ordered steps) or decomposed in the wrong order (fix: reorder so the shared or foundational step goes first) - and to reject any option that merely rewords or demands more thoroughness.
This knowledge point pulls together the whole decomposition task statement. It builds on sequencing a shared foundation before parallel deliverables and single-conversation vs separate-conversation steps, and it applies the recognition skill from recognising when a request needs decomposition to diagnose failures after the fact. The same structure-over-wording instinct carries into the iteration task statement.
A decomposed vendor analysis produces a recommendation that contradicts its own scoring section. Which diagnosis and fix are correct?
People also ask
Why does my decomposed task still fail?
Is a decomposition failure a wording problem?
How do I fix shallow multi-stage output?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.