Task Decomposition with Workflow Patterns: Chaining, Routing, Parallelization

1.Who decides the subtasks: workflows vs. agents

Every decomposition technique answers one question: who decides how the problem gets split? Anthropic groups all multi-step LLM systems under the name *agentic systems*, then makes one architectural distinction. Workflows run LLMs and tools through predefined code paths. You write the steps, and the model fills each one in. Agents are systems where LLMs dynamically direct their own processes and tool usage. The model picks the next step itself.

Both kinds are built from the same unit, the *augmented LLM*: a model with retrieval, tools and memory, which can generate its own search queries and choose its own tools. So decomposing a problem means arranging augmented LLM calls, either in a shape you fix in code or in a shape the model works out for itself.

The right choice depends on how predictable the work is. Anthropic's research team says research problems are hard to plan in advance: "You can't hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent." A support ticket that always needs the same three steps is the opposite case. The Managed Agents platform shows what dynamic decomposition looks like in practice: the coordinator starts with one thread, and additional threads are spawned at runtime when the coordinator delegates work. Nobody declares those threads ahead of time.

The same post also warns against reaching for complexity first. The teams that succeeded most were not using complex frameworks. They built with simple, composable patterns. The rest of this page covers the fixed patterns. Dynamic decomposition with orchestrators and subagents builds on them.

Sources123

2.Sequential decomposition: prompt chaining and evaluator-optimizer loops

Prompt chaining is the simplest way to decompose a task. You split it into a fixed sequence of steps, and each LLM call processes the output of the previous one. Between steps you can add programmatic checks, which Anthropic calls *gates*, to confirm the process is still on track before you spend another call. Chaining fits when the task can be easily and cleanly decomposed into fixed subtasks. The examples Anthropic gives are writing marketing copy and then translating it, and writing an outline, checking it against criteria, and then writing the document from it.

Anthropic's basic-workflows cookbook shows a four-step chain on a quarterly report. Step one pulls out each number with its label. Step two converts the values to percentages where that makes sense. Step three sorts the lines in descending order. Step four formats the result as a markdown table. None of these steps is hard alone. Chaining works because no single call has to do all four jobs at once.

The same reasoning carries over to agent systems. In the Agent SDK, each subagent can have its own tailored system prompt, so knowledge that one step needs doesn't clutter the instructions of the others.

Sometimes one step can't be finished in a single pass and has to be repeated until it's good enough. That calls for the evaluator-optimizer workflow. One LLM call generates a response, and another evaluates it and gives feedback, in a loop. It fits when you have clear evaluation criteria and each round of refinement measurably improves the result. Anthropic names two signs of a good fit: the response gets better when a human gives feedback, and an LLM can give that same kind of feedback. Literary translation is the example: an evaluator catches nuances the translator missed on the first pass.

Sources425

3.Routing: decomposing by input type

Chaining splits a task across *time*. Routing splits the input space instead. A first step classifies the input and sends it to a specialised follow-up task. This gives you separation of concerns: each downstream prompt can be tuned for one kind of input. Without routing, Anthropic notes, optimising for one kind of input can hurt performance on other inputs.

Routing works under two conditions. The task must have distinct categories that are better handled separately. And you must be able to classify inputs accurately, either with an LLM or with a more traditional classifier. If classification is unreliable, every downstream specialist gets the wrong inputs.

The standard examples show two reasons to route. The first is specialisation: general questions, refund requests and technical support each go to their own process, prompts and tools. The second is capability and cost: easy, common questions go to a smaller, cheaper model such as Claude Haiku 4.5, and hard or unusual ones go to a more capable model such as Claude Sonnet 4.5.

The same two moves appear as named patterns in Managed Agents multiagent orchestration. *Specialization* means sending work to agents with domain-focused system prompts and tools, such as a security agent or a documentation agent, instead of loading one agent with every capability. *Escalation* means consulting a more capable agent or model for a subset of complex subtasks. So routing is something you can use either as a fixed workflow step or as a choice a coordinator agent makes.

Sources12

4.Parallelization: sectioning and voting

When subtasks don't depend on each other, you don't have to run them in sequence. In parallelization, several LLM calls work at the same time and code aggregates their outputs. There are two variations, and they decompose differently:

- Sectioning splits a task into *different* independent subtasks. - Voting runs the *same* task several times to get diverse outputs.

Parallelization pays off in two situations: when splitting the work makes it faster, or when you need several perspectives or attempts to be confident in the result. Anthropic also notes that for complex tasks with several considerations, LLMs generally do better when each consideration gets its own LLM call.

Take guardrails as an example. One model instance answers the user while another screens the query for inappropriate content. This sectioned design tends to beat having one call handle both. Automated evals work the same way, with each call scoring a different aspect. Voting fits tasks like reviewing code for vulnerabilities with several prompts, or judging whether content is inappropriate using different vote thresholds to balance false positives against false negatives.

The speed benefit is specific. In the Agent SDK, independent subtasks run concurrently, so they finish in the time of the slowest one rather than the sum of all of them. A chain whose steps depend on each other can't get that benefit. The dependencies between subtasks determine whether you chain or parallelise.

Sources42

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Splitting a prompt into a chain of smaller calls is mainly a way to reduce latency.Why is that wrong?

   Chaining adds latency because the calls run one after another. You accept that to make each call an easier task and raise accuracy.

   Covered in Sequential decomposition: prompt chaining and evaluator-optimizer loops

2. 2.One well-prompted call should handle both the core response and the safety screening, since splitting them just adds calls.Why is that wrong?

   For guardrails, giving screening and responding to separate parallel calls tends to work better than one call doing both.

   Covered in Parallelization: sectioning and voting