Task Decomposition

Task Decomposition simply means breaking a task down into parts. A large, unclear task is divided into several small, clearly defined sub-steps. Each sub-step is solved individually, and at the end the results are put back together. Humans do this constantly: someone writing an essay first gathers material, then makes an outline, and only afterward writes the text. For programs that generate text or carry out tasks autonomously, exactly the same thing applies. Instead of demanding the entire task at once, the program is made to proceed step by step.

Why decomposed tasks go wrong less often

A language model — a program that predicts text word by word — has no plan in its head. It decides anew with each word what fits next. For a short question, that’s completely sufficient. For a task with five conditions at once, however, something quickly gets lost. Typically, the last condition simply gets ignored.

If the task is decomposed, the model only has to get one thing right per step. This noticeably lowers the error rate. It also makes it possible to trace where exactly something went wrong. With a single long answer, you only see that the result is wrong, not why. This traceability is one of the main reasons why companies work this way.

But there is also a price. Each sub-step is a separate request to the model and costs compute time and money. Ten small steps can easily cost ten times as much as a single request. And if step two contains an error, all subsequent steps build on it. This error propagation is the biggest risk with long chains.

From plan to sub-step

Usually it runs in two phases. First, the model creates a list of sub-tasks, similar to a to-do list. Then it works through this list, one task after another. The result of each step is written into the request for the next step. This preserves the context, even though these are technically separate requests.

An example: the task is to compare the quarterly figures of three companies. Decomposed, it looks like this: first, look up each company’s figures individually; second, put them into a shared table; third, describe the differences. For the first step, the system may launch a search; for the third, it may not. Each step is thus given only the tools it actually needs.

Related but not identical is the chain of thought. There, the model writes down its intermediate reasoning within a single response. With Task Decomposition, by contrast, these are separate runs, often with different tools or even different models. The decomposition can be fixed in advance by the developer, or the model can create it itself. Fixed specifications are more reliable, self-generated plans more flexible.

Where decomposition is already in use

It’s most clearly visible with so-called AI agents. These are programs that pursue a task independently over multiple steps instead of just answering once. When a chatbot reports that it is currently researching, then checking sources, and finally summarizing, a decomposition is behind it. The features called Deep Research in ChatGPT, Gemini, or Perplexity work according to this pattern.

It has also become standard in programming. Tools like GitHub Copilot or Cursor break a task down into reading files, planning changes, writing code, and running tests. If a test fails, only that sub-step is repeated.

In news about AI, the term usually appears in connection with agents and automation. A common misconception is that Task Decomposition is a property of the model itself. It is almost always part of the surrounding software that calls and controls the model.