Decomposition Comes in Three Shapes, and the Work Decides Which One Fits

Once you have accepted that a complex goal has to be broken into pieces, a second question arrives that is easy to skip past: what shape does the broken-down work run in? There are only three answers that matter, and almost every agentic system is some arrangement of them. Work can be nested, so that a high-level intent is split into subgoals and those into smaller tasks, each level worrying only about its own tier. Work can be chained, so that one step’s output becomes the next step’s input and the order is fixed. Or work can be spread, so that pieces with no need of one another run at the same time. Hierarchical, sequential, parallel. The mistake teams make is treating these as a stylistic menu, three ways to draw the same diagram, and picking the one that looks cleanest. They are not interchangeable and they are not a matter of taste. Each shape is the correct reading of a particular structure in the work, and the work, not a preference, is what selects it.

The reason this matters is that choosing the shape by aesthetics rather than by structure produces two distinct classes of failure, and one of them is silent. Serialize work that was independent and you have simply left speed on the table. Parallelize work that was actually dependent and you get output that is wrong and looks entirely successful. So the shape is not a cosmetic decision about how the pipeline reads. It is a claim about how the parts of the goal relate, and if the claim is false the system misbehaves in ways that range from wasteful to dangerous.

Hierarchical decomposition organizes the work by level of concern

The hierarchical shape splits a goal into subgoals, subgoals into tasks, tasks into steps, and arranges the result as a tree. Its defining property is that no level carries more than the concerns native to its own altitude; whatever sits below is delegated, not held. A controller near the top decides how to divide the overall intent and hands each division downward without needing to know how the division will be carried out. The level beneath does the same with what it receives. Organizations run on the same arrangement: someone sets a direction, someone else turns it into concrete work, and the person doing any single piece of it never has to keep the whole objective in view. The payoff is specialization by altitude. A tier that only ever sees one kind of subproblem can be built narrowly and well for it, free of the surrounding context that would only distract it.

The cost of the hierarchical shape is paid in layers, and the central design decision is how many to have. Every level you add buys more specialization and charges more coordination. It also lengthens the path an error has to travel. A failure at the bottom of a deep tree cannot be handled where it happens; it has to climb back up through every intermediate controller before anything with the authority to respond even learns of it, and every controller it passes through can soften the report, relabel it, or lose it outright. Depth, in other words, does not just add coordination overhead. It widens the gap between where a problem occurs and where it is caught.

The discipline that follows is to collapse any layer that is not doing distinct work. When the agent on one tier and the agent below it are doing recognizably the same job, told to do it in nearly the same terms, the line between them carries no information, and a line that carries no information is pure cost. A level belongs in the tree only when the work genuinely changes at that boundary, in kind or in the sort of agent it needs. Where the work does not change, the extra tier buys nothing but the look of added thoroughness, and pays coordination cost on every run to keep it.

Sequential order is imposed by the data, not chosen for convenience

The sequential shape is the one everyone reaches for first because it is the one everyone already understands: a step runs, produces something, and the next step consumes it. What is worth being precise about is why the order exists. In a genuine sequential chain, the ordering is not a convention the designer picked. It is a property of the data itself. A step cannot start before the step that produces its input has finished, because there is nothing for it to act on until then. The order is discovered, not imposed, and where the underlying dependency is real the order is not negotiable.

That constraint comes with a real compensation. A chain gives up the least of any shape when you have to trace a fault. Because control moves through one step at a time, a failure has an unambiguous location and the state of the system at the moment it failed is fully determined. You are never asking which of several concurrent things went wrong or what order they touched a shared resource in. You are looking at exactly one step and exactly the input it was handed. That legibility is worth a great deal when something breaks at three in the morning.

What the chain gives up is time. Every step waits on the one before it, so the whole runs no faster than its parts added end to end, and it can exploit no concurrency anywhere. When the dependencies are real, that cost is simply the price of correctness and there is nothing to be done about it. The failure is paying that price when the dependencies are not real, when steps were strung into a line out of habit even though nothing in the data required it. A chain of genuinely independent steps is latency accepted for no return.

Parallelism is available exactly when the dependency is absent

The parallel shape runs pieces at the same time, and its precondition is the exact inverse of the sequential one: it is available precisely where there is no data dependency between the pieces. If two parts of the goal each need only inputs that already exist, and neither needs anything the other produces, nothing forces them into an order, and holding them to one throws away time for no reason. Running them together collapses their combined duration from the sum of their lengths toward the length of whichever single piece takes longest. The time a chain has no choice but to spend is exactly the time this shape wins back.

The requirement that makes it safe is strict independence, and it is stricter than it first sounds. The moment two branches reach for the same piece of mutable state, the result starts to depend on which of them happens to get there first. Order returns through the back door, uncontrolled, and the outcome turns on timing instead of logic. Independence has to hold for the data the branches touch, not merely for the boxes they occupy on a chart.

The parallel shape also introduces a failure mode the chain does not have. When several branches run at once, one can come back clean while another comes back broken, and the point where the branches rejoin has to decide what a partial result means. Does the workflow proceed on what completed, retry only what failed, or abandon the whole batch? A chain never faces this question because it stops at the first failure, with everything before it intact and everything after it simply not yet started. The rejoin is a genuine design surface of its own, with its own collection and partial-failure policy to settle, and it deserves more care than a diagram’s converging arrows suggest. The point here is narrower: the moment you choose the parallel shape, you have taken on the obligation to define what happens when the branches do not all come back.

Dependency chooses between chained and spread; specialization chooses whether to nest

Put the three shapes together and the selection logic is almost mechanical, which is the good news, because it means the choice can be made from the structure of the work rather than from intuition. Between running steps in a line and running them side by side, the deciding fact is always data dependency. If one step consumes what another produces, the order is fixed and the shape is sequential. If two steps depend only on inputs that already exist and not on each other, they can be spread and run together. And the question of whether to nest at all, to introduce a hierarchy of controllers rather than a flat list of steps, turns on whether the work genuinely changes in kind as it proceeds and whether that change is worth giving its own tier and its own specialized agent.

This is why the shape has to be settled by mapping dependencies before anything is wired together, and why getting it from preference instead is a real hazard rather than a stylistic wobble. The two ways to get it wrong are not symmetric. Serializing steps that were actually independent is a missed optimization: the system is slower than it needed to be, but it is correct, and the cost is only time. Parallelizing steps that were actually dependent is something worse. A step fires before the input it needs exists, proceeds on whatever stale or empty value it finds, and returns something that passes every outward check and is wrong underneath. Nothing throws. The workflow reports completion. The error surfaces, if it surfaces at all, far downstream and far from its cause. Of the ways to misread the work’s structure, treating a dependency as if it were absent is the one that gives no outward sign of itself, and failures with no outward sign are the ones that cost the most.

Real systems are all three at once

Presenting the shapes one at a time makes them look like alternatives, and they are not. Any system of consequence is a composition of all three; isolating one shape is a convenience for explaining it, not a picture of how the system actually runs. A top-level split might hand several independent workstreams off to run at once, and inside any one of them the steps might be strictly ordered, and a single one of those ordered steps might itself open into a spread of parallel calls that close back together before the next step begins. The nesting can go the other way too, and to any depth. The three shapes sit inside one another, each governing only the stretch of work it fits.

What makes this tractable is that nothing forces one verdict on the whole system. Each segment is judged on its own, against the same short list of questions. Do these parts depend on one another’s output? Then they are a chain. Are they independent? Then they can spread. Does the work change in kind here in a way that warrants its own tier of control? Then nest. Durable architectures come from letting each segment’s structure answer for itself and accepting that the answers will differ across the system, not from settling on one shape and applying it everywhere out of habit. A house style pressed onto a structure it does not fit is exactly how the wrong shape gets chosen.

Diagnosing a workflow by the shape it got wrong

Because each shape is the right answer to a specific structural question, each way of getting the shape wrong has a recognizable signature, and reading the signature tells you what the fix is. When coordination starts to cost more than the work it coordinates, the grain is too fine: the pieces have been cut smaller than the overhead of connecting them, and the repair is to merge steps back together, not to tune any one of them. When a single failure destroys an entire run and recovery means starting over, the grain is too coarse: the work was left in units too large to recover, and the repair is to introduce the boundaries that were missing. Those two are questions of how finely the work was cut, and the piece that a designer feels most tempted to over-apply is the parallel one, because spreading work feels like pure speed with no downside.

That temptation produces the third and most dangerous signature. A system that treats dependent steps as independent and runs them together will not announce the problem the way a crash does. It will return answers, and the answers will sometimes be wrong, because a step keeps starting before its real input exists. This is the failure that survives testing and reaches production intact, precisely because nothing about it looks like a failure from the outside. When a system produces intermittently incorrect results with no error to point at, the first thing to suspect is a dependency that was modeled as absent. The other two signatures cost effort and resilience; this one costs correctness, and it hides while doing it.

The shape is a reading of the work, not a choice of style

Between them, nesting, chaining, and spreading exhaust the ways decomposed work can run, and none of them is a default. Hierarchy exists to buy specialization at the price of layers. Sequence exists because data dependencies leave no alternative, and it rewards you with a system that is easy to understand when it breaks. Parallelism exists to reclaim the time that dependencies would otherwise cost, on the strict condition that the independence is genuine. The skill that separates a durable architecture from a fragile one is not fluency in any single pattern. It is the habit of reading a segment’s actual structure, its dependencies and its shifts in kind, and letting that reading pick the shape, then doing it again for the next segment and being willing to arrive at a different answer. The shape of a good decomposition is not designed onto the work. It is discovered in it.