What you’ll be able to do
- Break an ambiguous goal into a task graph with the right granularity
- Explain the cost of over-decomposition versus under-decomposition
- Use task volatility to decide how finely to split a workflow
- Recognize when a task graph should be static versus decided at runtime
What you need to know
Decomposition is a granularity decision, not just a division of labor
Given an ambiguous goal — "produce a competitive analysis of these five companies" — the instinct is to decompose it the way a human team would: one step per company, then a synthesis step. That's a reasonable starting point, but it isn't the whole decision. The real question for an architect is how finely to split each of those steps, and that's driven by cost and reliability, not by org-chart intuition.
The cost of over-decomposition
Splitting a task into many small steps means many model calls, each with its own latency and token overhead, and each one an additional point where a handoff can go wrong. A step so fine-grained it could have been done in the same call as its neighbor is pure orchestration tax: you're paying for coordination you didn't need.
The cost of under-decomposition
A single giant step has no internal checkpoints — if it fails a third of the way through, you've lost all of it and have to start over, paying for the successful two-thirds again. Decomposing into isolated, independently retryable steps means a failure in researching company three doesn't cost you the research already done on companies one and two.
Volatility should drive granularity, not habit
The deciding question for how finely to split a given piece of work is: how likely is this piece to fail, need a retry, or produce output whose structure varies? High-volatility work — anything touching an unreliable external API, ambiguous unstructured input, or output whose shape depends heavily on what's found — benefits from finer decomposition, so a failure is isolated and retryable without redoing stable, already-succeeded neighbors. Low-volatility, predictable work can stay coarser; splitting it further only adds overhead without buying reliability, because there was little to fail in the first place.
Static graphs versus runtime-decided ones
Some task graphs can be fully known at design time — the same five steps, every run. Others genuinely depend on what's discovered along the way: a research task might need a variable number of follow-up searches depending on how much the first pass turns up. Forcing a fixed graph onto input-dependent work either over-provisions steps that go unused or under-provisions and truncates real work. Recognizing which kind of task you have — fixed shape or input-dependent shape — is itself part of the decomposition decision.
Key concept
Decompose by volatility, not by how a human team would divide the labor. Split finely where failure is likely and isolation pays for itself; stay coarse where the work is stable and further splitting only adds overhead.
When a scenario describes a workflow where one failure forces redoing everything, look for a task that was under-decomposed — a checkpoint boundary is missing, not a retry policy.
Practice scenario
Work it through, then open this
The batch granularity is too coarse for the failure rate of this input — scanned documents are volatile (formatting varies, some scans are malformed), so a single bad invoice shouldn’t cost 49 good ones. Decompose to per-invoice steps, each independently retryable, so a malformed scan fails and can be flagged or retried in isolation without touching the other 49 results already extracted successfully.
Build exercise — Re-grain a task graph by volatility
Intermediate · 20 min
What you’ll learn
- Identifying which steps in a workflow are volatile versus stable
- Matching decomposition granularity to failure likelihood
- Spotting a step that’s costing orchestration tax for no reliability benefit
-
Take a multi-step task and rate each step’s volatility — how likely it is to fail, need a retry, or vary in output shape.
- Why: Volatility, not habit, is the signal that should drive how finely a step is split.
- You should see: A mix — some steps clearly stable, some clearly volatile.
-
For the most volatile step, check whether a failure there currently forces redoing any stable, already-succeeded work.
- Why: This is the under-decomposition failure mode — one bad piece costing good work that had nothing to do with the failure.
- You should see: Either isolation already in place, or a boundary you need to add.
-
For the most stable step, check whether it’s split more finely than its failure rate justifies.
- Why: Splitting a low-risk step just adds latency and orchestration cost with no reliability payoff.
- You should see: A candidate to merge back into a coarser step, or confirmation the current granularity is already right.
Exam traps
Decomposing by how a human team would divide the work, not by agent reliability
Org-chart intuition is a starting point, not the deciding factor — volatility and failure isolation are.
Splitting stable, low-risk steps as finely as volatile, error-prone ones
Uniform granularity ignores that different steps have very different failure profiles.
Building one giant step that has to be entirely redone on any partial failure
Under-decomposition means no internal checkpoints — one failure costs everything already done.
Fixing a task graph at design time when the right shape depends on the input
Input-dependent work needs a graph that can adapt, not a fixed number of pre-planned steps.
Treating decomposition as a one-time decision instead of something to revisit under load
Failure rates and volatility can change as a system scales — the right granularity isn’t necessarily permanent.