Task Decomposition Agent Pattern: Break Complex Tasks Down

Pattern essence

Task Decomposition is a pattern that allows an agent to break a complex task into smaller subtasks before execution.

When to use it: when a complex task cannot be reliably completed in one step and must be split into subtasks.

Instead of solving everything at once, it:

• analyzes the task
• defines steps
• executes them in sequence

Each step is a separate subtask.

Problem

Imagine the agent receives a task:

"Prepare a monthly sales report."

In practice, this is not one step but a sequence of subtasks:

• collect data
• clean and validate it
• calculate metrics
• create the conclusion

Without an explicit plan, a complex task quickly becomes opaque: steps get lost and logic breaks.

If the agent tries to do everything "in one pass", chaos usually appears:

• missing intermediate steps
• wrong execution order
• mixing planning and execution
• weak error controllability

That is the problem: without structure, a complex task is easy to execute unstably and with errors.

Solution

Task Decomposition adds a separate planning stage before execution.

Analogy: it is like assembling furniture with instructions. Without instructions, it is easy to mix up the order or miss a part. With instructions, each step is transparent and errors are easier to find.

Key principle: First plan, then action. This is what makes the process controllable.

To prevent the agent from jumping straight to the final answer, decomposition-policy defines:

• which subtasks are mandatory
• in which order they should run
• when re-plan is required

The controlled process looks like this (as shown in the diagram):

1. Goal: clarify goal and constraints
2. Plan: split the task into subtasks and dependencies
3. Step execution (Step 1..N / Execute): run subtasks according to the plan
4. Combine Results: merge step outputs into one result
5. Done: produce the final output

Intermediate result capture (checkpoint) happens inside the execution stage.

Task Decomposition helps to:

• increase predictability
• avoid missing important stages
• localize errors at a specific step
• get more stable results in long tasks

It works best if:

• there are clear step boundaries and dependencies
• each step has a completion criterion
• re-plan rules are set for changing conditions
• the execution stage does not bypass the approved plan

Even if the model "wants" to give a final answer immediately, decomposition-policy returns the process to structured steps.

How it works

Task Decomposition does not execute steps by itself.

It only defines which subtasks must be done, and each of them can be executed via a separate ReAct loop.

So the agent first builds a plan, then usually solves subtasks sequentially, step by step.

In code it looks like this

steps = plan(goal)

for step_no, step in enumerate(steps, start=1):
    result = execute(step, context=context)  # each step sees outputs from previous steps
    if not result.ok:
        return stop_or_replan(step_no=step_no, reason=result.error)
    context.append(result.data)

return build_final_output(context)

The agent splits the task into subtasks and executes them in sequence.

How it looks during execution

Goal: prepare a monthly sales report

Plan:
1. collect sales data
2. clean data
3. calculate key metrics
4. build charts
5. write a conclusion

Execute step 1: system calls fetch_sales_data(month)
Observe: raw data received
Between steps: raw_data becomes input for cleaning

Execute step 2: system calls clean_sales_data(raw_data)
Observe: data cleaned and validated
Between steps: clean_data becomes input for metric calculation

Execute step 3: system calls calculate_metrics(clean_data)
Observe: metrics calculated

Execute step 4: system calls build_charts(metrics)
Observe: charts built

Execute step 5: system composes summary
Observe: final report is ready
Stop: after the final step, the loop ends

Each step is executed separately, and intermediate output becomes input for the next stage.

When it fits - and when it does not

Fits

Does not fit

Because the plan may be inaccurate or unnecessary.

When to use Task Decomposition among other patterns

Use Task Decomposition when you need to first split a large goal into smaller executable subtasks.

Quick test:

• if you need "first break a complex task into subtasks" -> Task Decomposition
• if you need "after each step decide what to do next" -> ReAct Agent

How to combine with other patterns

• Task Decomposition + ReAct - each subtask is executed step by step, so errors are easier to control.
• Task Decomposition + Routing - for each subtask, the most suitable executor is selected automatically.
• Task Decomposition + Orchestrator - the Orchestrator manages dependencies and parallelism, so the plan runs without blocking.

How it differs from ReAct

ReAct helps execute a step.

Task Decomposition defines which steps should be executed at all.

In short

Pros and Cons

FAQ

Q: Is a plan always required?
A: No. For simple tasks, it may be unnecessary.

Q: Can the agent change the plan?
A: Yes. If new data appears during execution or one step fails, the agent can revise the initial plan: add new subtasks, change order, or create a new plan before next actions.

Q: Does Task Decomposition work without ReAct?
A: Yes. Subtask planning can run separately, for example if each step has a fixed Workflow. But in more complex tasks, each subtask is often executed through a ReAct loop.

What next

Task Decomposition allows splitting a task into steps.

But what should you do if you need to choose between multiple agents?