Task Decomposition Strategies for Agentic Workflows

Why Task Decomposition Matters

When an agent attempts a complex, multi-faceted task in a single pass, it faces three compounding challenges: the full task may exceed the model's effective reasoning span; errors at any point in the implicit pipeline are hard to detect and correct; and there's no opportunity to verify intermediate results before they propagate to subsequent steps. Task decomposition addresses all three by making the implicit pipeline explicit.

The empirical evidence for decomposition's effectiveness is strong. Across diverse agent benchmarks, structured decomposition improves success rates by 20–40% on tasks that are above average complexity. The improvement comes not from the decomposition itself, but from the quality control opportunities it creates: checkpoints, verification gates, error containment, and the ability to apply the right tool to the right sub-task.

What Decomposition Enables

• Specialized processing: Different sub-tasks can be routed to the most capable model or tool for that specific sub-task type.
• Parallel execution: Independent sub-tasks can run simultaneously, reducing total latency.
• Partial recovery: When one sub-task fails, completed sub-tasks are preserved and only the failed one needs to be retried.
• Progress visibility: Users and monitoring systems can see which sub-tasks have completed, providing better transparency than a monolithic black-box task.
• Iterative refinement: Each sub-task output can be evaluated and refined before passing to the next sub-task.

Core Decomposition Patterns

Pattern 1, Sequential Decomposition

Sequential decomposition breaks a task into ordered steps where each step's output is the input to the next. This is the most common pattern and the easiest to implement. Best used when: steps have hard ordering dependencies (you must research before writing, analyze before recommending), or when later steps require the full output of earlier steps.

Pattern 2, Parallel Decomposition

Parallel decomposition identifies sub-tasks that are independent of each other and runs them simultaneously. The results are aggregated by a synthesis step. Best used when: sub-tasks answer different aspects of a question (research multiple sources simultaneously), or when sub-tasks can be partitioned by data segment (process 5 documents in parallel).

Pattern 3, Hierarchical Decomposition

Hierarchical decomposition creates a tree of tasks: an orchestrator delegates to managers, who delegate to workers. Each level operates at a different abstraction level. Best used when: tasks are complex enough to require multiple levels of planning, or when different parts of the task require different domain expertise and should be handled by specialized sub-agents.

Error Compounding in Pipelines

A decomposed pipeline multiplies both success probabilities and failure risks. If each sub-task has 90% accuracy, a 5-step linear pipeline achieves only 59% end-to-end accuracy (0.9^5). This error compounding is a fundamental challenge that decomposition creates even as it solves other problems.

Strategies to Combat Error Compounding

• Reduce pipeline length: Every additional step multiplies error risk. Question whether each sub-task is truly necessary. Merge steps that can be combined without losing quality.
• Improve individual step accuracy: A step that performs at 95% accuracy compounds much less than one at 80%. Invest in prompt optimization for each step individually.
• Add verification gates: An explicit check after each step that can catch and correct errors before they propagate. Even imperfect verification (80% error detection) significantly improves end-to-end accuracy.
• Use parallel decomposition where possible: Parallel sub-tasks fail independently rather than cascadingly. A failure in one parallel branch doesn't automatically fail other branches.

Calibrating Sub-Task Granularity

Sub-task granularity, how fine-grained the decomposition is, dramatically affects both quality and efficiency. Too coarse and you don't get the quality benefits of decomposition. Too fine and you create overhead without proportional benefit.

Signs of Over-Decomposition

• Many sub-tasks that could be combined without losing quality: 'retrieve data', 'format data', 'validate format' could be one step.
• Sub-task outputs that are only meaningful in the context of adjacent steps: they're not truly independent.
• Sub-tasks so simple that a single LLM call is overkill for each.
• Pipeline overhead (context passing, orchestration) exceeds the compute of the actual work.

Signs of Under-Decomposition

• Single steps that regularly fail on complex instances of the task.
• No natural checkpoint for verifying intermediate correctness.
• Steps that combine multiple distinct operations (research + analyze + recommend = three distinct steps).
• Steps that could benefit from different models or tools but are forced to use one.

The Goldilocks Principle

The right granularity is: each sub-task should be the smallest unit that produces a meaningfully verifiable intermediate output. If you can't describe what 'done correctly' means for a sub-task independently of the surrounding steps, it's too fine-grained. If a sub-task has multiple independently verifiable components, it's too coarse.

Dependency Mapping Between Sub-Tasks

Explicit dependency mapping unlocks parallel execution and makes failure impact analysis tractable. A dependency map answers: which sub-tasks must complete before each sub-task can start?

Dependency Graph Construction

Build a directed acyclic graph (DAG) where nodes are sub-tasks and edges represent 'must complete before' dependencies. Sub-tasks with no predecessors can start immediately. Sub-tasks whose predecessors are all complete can start as soon as they're ready. The critical path (longest sequence of dependencies) determines the minimum possible execution time.

from dataclasses import dataclass, field

@dataclass
class SubTask:
    id: str
    description: str
    depends_on: list[str] = field(default_factory=list)
    status: str = "pending"  # pending/running/done/failed
    result: object = None

def get_ready_tasks(tasks: dict[str, SubTask]) -> list[SubTask]:
    """Return tasks whose dependencies are all complete."""
    return [
        t for t in tasks.values()
        if t.status == "pending"
        and all(tasks[dep].status == "done" for dep in t.depends_on)
    ]

async def execute_dag(tasks: dict[str, SubTask], executor) -> dict:
    """Execute a task DAG respecting dependencies, maximizing parallelism."""
    while any(t.status == "pending" for t in tasks.values()):
        ready = get_ready_tasks(tasks)
        if not ready:
            break  # Deadlock or all done
        # Run all ready tasks in parallel
        results = await asyncio.gather(
            *[executor(t) for t in ready], return_exceptions=True
        )
        for task, result in zip(ready, results):
            if isinstance(result, Exception):
                tasks[task.id].status = "failed"
            else:
                tasks[task.id].result = result
                tasks[task.id].status = "done"
    return {tid: t.result for tid, t in tasks.items() if t.status == "done"}

LLM-Driven Task Decomposition

Rather than hard-coding decomposition logic, you can use an LLM to decompose tasks dynamically. The decomposer model takes a task description and produces a structured decomposition plan, sub-tasks, dependencies, and verification criteria.

Decomposition Prompt Design

You are a task decomposition specialist. Break the following task into sub-tasks.

For each sub-task, provide:
- id: A short snake_case identifier
- description: What this sub-task accomplishes
- depends_on: List of sub-task IDs that must complete first ([] for none)
- success_criteria: How to verify this sub-task completed correctly
- tool_type: The type of tool or process best suited (llm_call/api_call/retrieval/code_execution)

Output as JSON array.

Task: {task_description}

Sub-tasks:

Validating LLM Decompositions

LLM-generated decompositions must be validated before execution: check that the dependency graph is acyclic (no circular dependencies), that all referenced dependency IDs exist, and that the sub-tasks collectively cover the full task scope. Add a second LLM call: 'Review this decomposition plan. Is any part of the original task not covered by these sub-tasks? Are there any unnecessary sub-tasks?'

Verification Gates Between Sub-Tasks

Verification gates check the quality of each sub-task output before passing it to the next step. They're the primary mechanism for preventing error compounding.

Gate Types by Sub-Task Type

• Schema validation gates: For sub-tasks that produce structured data, validate the output schema before proceeding. A JSON schema validator catches structural errors that would silently cause the next step to fail.
• Completeness gates: Check that all required fields in the sub-task output are present and non-empty. 'Does this research summary contain at least 3 cited sources?'
• Factual consistency gates: Use an LLM judge to check that the sub-task output is internally consistent and consistent with the inputs it received.
• Quality score gates: Score the output on a 1–5 rubric. If below threshold (typically 3), retry the sub-task with the failure mode identified in the score.
• Semantic coverage gates: For research or analysis sub-tasks, check that the output covers all the dimensions it was supposed to. 'Does this analysis cover cost, timeline, and risk?'

Parallel Sub-Task Execution

Parallel execution is one of the most impactful optimizations for decomposed agent workflows. Tasks that would take 5 minutes sequentially can complete in 90 seconds when independent sub-tasks run simultaneously.

Identifying Parallelizable Sub-Tasks

• Data partitioning: Process N documents, N rows, N API records, all of these partition naturally into parallel sub-tasks.
• Multi-source research: Searching multiple databases, querying multiple APIs, analyzing multiple code files, independent queries run in parallel.
• Independent analysis dimensions: Analyzing 'cost', 'quality', and 'risk' of a proposal are independent and can run in parallel.
• Draft + review pattern: Generate draft in parallel with preparing review criteria. Merge when both complete.

Concurrency Limits

Unconstrained parallelism causes rate limit issues with LLM providers and external APIs. Set a concurrency limit based on your provider rate limits. For Anthropic, a safe default is 10–20 concurrent calls. Use an async semaphore to enforce the limit while still running as much in parallel as the limit allows.

Decomposition Failure Modes

Failure Mode 1, Critical Information Lost Between Steps

Each sub-task receives only the output of its declared dependencies, not the full task context. Critical information from the original task description may be lost. Mitigate by explicitly passing the original task specification to every sub-task, not just the preceding step's output.

Failure Mode 2, Wrong Decomposition for Task Instance

A decomposition that works well for typical task instances may be wrong for specific edge cases. A task described as 'research and summarize' that turns out to require a calculation step has been incorrectly decomposed. Mitigate with dynamic re-decomposition: allow the executing agent to flag when the current decomposition is wrong and trigger a re-planning step.

Failure Mode 3, Aggregation Errors

Parallel sub-tasks produce outputs that must be aggregated into a coherent final result. Aggregation is itself a complex step that can introduce errors, merging conflicting information, losing nuance during synthesis, or producing incoherent combinations of independently-correct outputs.

Dynamic Re-Decomposition at Runtime

Static decomposition plans created before execution may need revision once execution begins. Information revealed during execution, a tool failing, a data source being empty, a sub-task taking far longer than expected, may make the original plan incorrect or suboptimal.

Re-Decomposition Triggers

• Sub-task failure: When a sub-task fails permanently, the agent must assess whether the remaining plan is still viable and replan if needed.
• Unexpected sub-task output: If a sub-task returns significantly different output than expected (empty results, different data structure, unexpected error), trigger a replanning evaluation.
• Scope expansion: If executing a sub-task reveals that the task is significantly larger or more complex than originally decomposed, the agent should surface this and offer to redecompose.
• Resource constraints: If execution is tracking to exceed budget (time or cost), the agent can redecompose to reduce the remaining scope to the highest-value sub-tasks.