Task decomposition: named on three Claude tracks, absent from the fourth

Task decomposition is a named objective on three of the four Claude certification tracks: CCAO-F asks for techniques that structure complex requests, CCAR-F for strategies across complex workflows, and CCAR-P for techniques applied to complex problem solving. CCDV-F does not name it at all. Read those three wordings side by side and the skill is not repeating — the unit being divided changes at every level.

Named on three tracks

The CCDV-F row is an absence rather than a claim. The guide does not name decomposition and does not explain why, so the honest thing is to say where the nearest material sits: that track’s Domain 1 covers agent architecture and agent patterns, which examine how work divides between a workflow, an agent and its subagents without using the term.

The unit changes at each level

This matters more than it sounds. A candidate who revises decomposition from architect material and sits the associate exam will reach for team boundaries on a question about structuring a single request; one who does the reverse will divide a multi-team programme into conversational stages. Both answers are coherent and both are aimed at the wrong unit.

Associate: structuring a request

The associate objective is about one complex task and the stages inside it. What makes a stage worth separating is that someone can inspect what it produced while acting on it remains possible — a division that creates a place to verify, not merely a shorter prompt.

The recurring wrong answer divides on length rather than on risk. Splitting a long request into two long requests changes nothing you can act on. Splitting it where an error would otherwise propagate gives you somewhere to look, which is the same instinct examined in evaluating Claude output.

Foundations: dividing a workflow

The architect foundations objective moves up to workflows, and the decomposition question arrives attached to a second one: where the checkpoints go. Steps that run without a defined stopping point or terminal action carry on past the point where something went wrong.

There is also a trap sitting next to this objective. A task that divides cleanly into known steps has made the case against autonomy rather than for it — if every path can be written down in advance, a workflow does the job and an agent adds cost and uncertainty. That decision is covered in when not to build an agent, and how the pieces get handed to workers in subagents and coordinator patterns.

Professional: dividing ownership

At the professional level the pieces are not steps, they are responsibilities. A boundary between two components is also a boundary between two teams, two release cadences and two people who have to agree on what crosses it.

Which is why decomposition on CCAR-P keeps arriving at documentation and handoff. A division that is correct on a diagram and unclear in practice has not been made — see stakeholder communication on CCAR-P for the domain where that consequence is examined directly.

Both ways of dividing badly are quiet

There are exactly two ways to divide work wrongly, and neither raises an error. Pieces that overlap cause the same work to be done and paid for more than once, and the duplicated result looks like agreement rather than waste. Pieces that leave a gap produce a confident, well-formed answer about part of the problem, with nothing in it indicating the missing part.

Both are caught by the same discipline, and it is the one candidates skip: reconcile the set of returns against the set of dispatches before doing anything with the results. That comparison is the only step in the whole sequence whose job is to notice that a division was wrong, which is why options that omit it are the ones the exam is testing you on.

Key takeaways

• Three tracks name it, one does not. CCAO-F, CCAR-F and CCAR-P have decomposition objectives; CCDV-F does not, and the guide gives no reason.
• The unit changes with the level. Stages of a request, steps of a workflow, then ownership across teams and systems.
• Divide on risk, not on length. A stage earns a boundary when its output can be inspected while acting on it is still possible.
• Clean decomposition argues against an agent. Enumerable steps mean a workflow does the job with less cost and less uncertainty.
• Overlap and gaps are both silent. One pays twice, the other answers half the question, and neither raises an error.
• Reconcile before you synthesise. Reconciling returns against dispatches is the only step whose job is catching a bad division.