TL;DR
V1 Decompose is step two of the V1 Framework. It is the work of breaking a stripped problem into the smallest true units of work, naming the real inputs and outputs, and deciding what is sequential versus what is parallel. Without decomposition, you are asking the AI to do everything at once, and it will hallucinate the boundaries you forgot to draw.
- The irreducible unit has one input, one output, one transformation.
- If a unit needs an "and" in its name, it has not been decomposed.
- Sequence only what must be sequenced. Parallelize the rest.
- AI agents force decomposition discipline whether you do it or not.
- The output of Decompose is a list of named units and the graph between them.
In this article
What decomposition means in AI work
Decomposition is step two of the V1 Framework because Strip alone does not produce a buildable system. Strip produces a clean statement of the job. Decompose turns that statement into a graph of discrete units of work the AI can actually execute and the team can actually verify.
The questions Decompose answers are mechanical. What is the smallest true statement about what needs to happen? What are the real inputs and the real outputs at each step? What transformation actually needs to occur between them? Those are the same three questions whether you are building a single prompt, a five-step workflow, or a multi-agent system.
The output of Decompose is not a flowchart. It is a list of named units, each with a one-sentence description, one input, one output, and the dependency relationships between them. Anything more decorative than that is theater. Anything less than that is unbuildable.
Finding the irreducible unit
An irreducible unit of work is the atom of the workflow. It cannot be broken down further without losing its meaning. It takes one input. It produces one output. It performs one transformation.
The test is linguistic. If you cannot describe the unit in one sentence without using the word "and," it is not irreducible. "Read the ticket and check the order" is two units pretending to be one. The "and" is the seam where the unit splits.
The reason this matters: each unit is something an AI call, a deterministic function, or a human will execute. If a unit hides two operations behind one description, the AI will guess where the boundary is. Sometimes the guess is right. Often it is wrong. Either way, you have given up the ability to verify the boundary, because you never named it.
Most teams stop decomposing too early. They get to a unit that feels small enough and stop. The discipline is to keep asking "can this be split further?" until the answer is genuinely no. The genuinely-no point is usually one or two levels deeper than the comfortable stopping point.
Every "and" in a unit description is a hidden bug. Decompose until the "and"s are gone, then go one level deeper to be sure.
Sequencing versus parallelizing
Once the units exist, the next question is which ones depend on which. Decomposition without dependency mapping is a list, not a graph. The list will not survive contact with execution.
There are two kinds of dependencies:
- Blocking dependencies. Unit B cannot start until Unit A finishes, because B needs A's output as its input. These must be sequenced.
- Non-blocking dependencies. Unit B can start without Unit A's output, even if B will eventually consume something A produces. These can run in parallel.
The most common mistake is treating non-blocking work as sequential. The team writes a workflow that reads the ticket, then looks up the order, then checks inventory, then checks the return policy, then drafts the reply. Most of those lookups have no dependency on each other. They can run in parallel and merge at the draft step. Sequencing them serializes work that did not need to be serialized, doubles the latency, and triples the token cost.
The discipline is to draw the dependency graph and challenge every edge. If an edge cannot be defended as a blocking dependency, it is parallelizable. Most edges in most workflows cannot be defended that way.
How AI agents force decomposition
AI agents are decomposition made visible. An agent that is supposed to "handle customer support" is unbuildable. An agent that is supposed to "classify the ticket type, then route to one of four sub-handlers, each of which performs one lookup and produces one draft" is buildable, debuggable, and cheap.
The agents that fail in production are the ones whose authors skipped decomposition and let the agent's planner decompose at runtime. The planner is a probabilistic system. It will decompose differently every time, miss edges, and forget steps. The team blames the model. The model is doing its best with a prompt that asked it to invent the workflow on the fly.
The agents that succeed in production are the ones whose authors decomposed the workflow at design time, named every unit, wired the dependency graph, and used the model only inside each unit. The agent's graph is the decomposition rendered into code. For more on what that looks like in production, see Building Your First AI Agent Workflow.
The rule of thumb: if the model is responsible for deciding what to do next, you have under-decomposed. If the model is responsible for executing a named unit and reporting the result, you have decomposed correctly. The first failure mode is dramatic and unreliable. The second is boring and works.
A worked example: an AI for customer support
Take the stripped brief from V1 Step 1: Strip: "A customer has asked a question or made a request. We need them to get the right answer fast. The outcome we care about is: the customer is helped, the answer is correct, and the team's time is spent only on the cases that require judgment."
That brief is clean. It is also undecomposed. Asking an AI to do "all of that" is the un-decomposed version. Here is the same brief after decomposition:
- Classify. Input: incoming customer message. Output: one of {order question, refund request, policy question, complaint, other}. One transformation: classification.
- Look up order. Input: customer identifier. Output: order status, shipping status, and the last three line items. One transformation: lookup against the order system.
- Look up policy. Input: classification from step 1. Output: the relevant policy text. One transformation: retrieval.
- Decide path. Input: classification, order status, policy text. Output: one of {auto-resolve, draft for human review, escalate to human, refund up to threshold}. One transformation: rule-based decision.
- Generate response or escalation packet. Input: path decision, classification, order data, policy text. Output: either a customer-ready response or an escalation packet for a human. One transformation: generation.
Five units. Each has one input, one output, one transformation. Units 2 and 3 are non-blocking with respect to each other and run in parallel. Unit 1 is blocking for everything else. Unit 4 is blocking for unit 5. The graph is obvious. The cost per ticket is calculable. The failure mode at each unit is observable. The team can verify each unit independently.
The same workflow, un-decomposed, would have been a single prompt that says "look at the ticket and figure out what to do, then do it." That prompt produces unpredictable output, unpredictable cost, and an un-debuggable failure mode. The decomposed version produces all the same outcomes the un-decomposed version was trying to produce, except it works and you can prove that it works.
The decomposed workflow is boring to build and easy to ship. The un-decomposed workflow is exciting to demo and impossible to operate.
Common decomposition failures
Three failure modes show up over and over. Each is fixable.
1. Stopping too early. The team gets to a unit that feels reasonable and stops. The unit still contains an "and." The unit still has two transformations in it. The team ships it, the AI does one of the two transformations well and the other poorly, and the team cannot tell which. Keep decomposing until each unit is genuinely irreducible.
2. Serializing the graph. The team writes the workflow as a list because lists are easy to read. The list is not the graph. Every step that does not need its predecessor's output should be parallel. Serial lists are the easiest way to triple your latency and your cost for no reason.
3. Letting the model decompose at runtime. The team writes a prompt that says "figure out the steps and do them." The model decomposes inconsistently across runs. The output looks fine most days and fails strangely on the days the model decomposes differently. Decompose at design time. Use the model inside the units, not above them.
A fourth mode is worth naming because it looks like success: over-decomposing. Some teams break the workflow into so many tiny units that the orchestration cost dwarfs the work. The test is whether each unit, in isolation, is worth naming. If a unit's sole purpose is to pass data through, merge it back into the unit before or after it. The right altitude is one transformation per unit, not one line of code per unit.
Where Decompose fits in the larger framework
Decompose is the bridge between thinking and building. Strip produced the clean problem statement. Decompose produces the graph of units that will become the actual system. Step 3: Constrain will then define the boundaries inside each unit and across the graph. By the time you reach Step 5 and write the prompt, the prompt is mostly already written, because the decomposition has named what each unit does.
This is also where the V1 Framework starts to interact with the broader AI transformation playbook. Decomposition at the workflow level is the same posture as decomposition at the program level. The pilots that ship are the ones whose authors named the units, mapped the dependencies, and ran the parallel work in parallel. The pilots that stall are the ones whose authors handed the model a monolith and asked it to figure things out.
The bottom line
V1 Decompose is the step that turns a stripped problem into a buildable system. It is mechanical, not creative. Name the irreducible units, draw the dependency graph, parallelize what does not need to be sequential, and resist the urge to let the model decompose at runtime. The next step is V1 Step 3: Constrain, where the boundaries of each unit get defined.
FAQ
What is V1 Step 2?
V1 Step 2 is Decompose, the second step of the V1 Framework. It is the work of breaking a stripped problem into its irreducible units: the smallest true statements about what needs to happen, the real inputs, the real outputs, and the transformation that has to occur between them.
How small should you decompose?
Decompose until each unit can be described in one sentence, takes one input, and produces one output. That is the irreducible unit. If a unit needs an "and" in its description, it has not been decomposed yet. The test is whether you could hand the unit to an AI or a human without further explanation.
When are dependencies blocking?
A dependency is blocking when the downstream unit cannot start until the upstream unit finishes. Blocking dependencies must be sequenced. Non-blocking dependencies can run in parallel. Most decomposition failures come from treating non-blocking work as sequential, which serializes work that could ship in half the time.
What is an irreducible unit of work?
An irreducible unit is a piece of work that cannot be broken down further without losing its meaning. It has one input, one output, and one transformation. It is the atom of the workflow. If you can split it into two units that each still make sense alone, it was not irreducible.
Can decomposition be skipped?
No. Skipping decomposition is how teams end up asking an AI to do everything at once. The AI hallucinates the sequencing, the dependencies, and the boundaries. Decomposition is the step that turns a vague brief into a list of discrete tasks the AI can actually execute and the team can actually verify.
How does decomposition apply to AI agents?
AI agents force decomposition discipline. Each tool call, each sub-agent, and each step in an agent graph is a unit that was decomposed at design time. A poorly decomposed agent is a slow, expensive, unreliable agent. A well-decomposed agent is a fast, cheap, debuggable one.