Task Decomposition

Task decomposition is splitting a job into pieces whose outputs you can check without running the rest. Three checkable steps cut from one document job: classify it, extract these five fields, verify each field against the source. Each step’s output can fail loudly on its own.

The reason to bother is the arithmetic of chaining: errors in a chain multiply rather than average, so a long run of steps that each work most of the time still fails as a whole surprisingly often. Two levers exist: raise each step’s success rate, or make each step checkable so a failure stops where it happened. You do not train the model, so only the second lever is in your hands.

A good piece is also closed: everything it reads exists before it runs. Take an invoice check in four steps: read the text out of the PDF, fetch the matching purchase order, compare the two, write the result to the ledger. Compare reads the extracted text and the fetched order, so it cannot run until both exist. Reading the PDF and fetching the order consume nothing from each other, so they can run in either order, or at the same time. Written out for every step, those read-before-run constraints are the job’s dependency graph.

That is why it is better to cut than to rewrite the prompt when something fails repeatedly. A prompt that asks for six things at once fails in six ways at the same time, and the output tells you nothing about which one broke. The same work as three checked steps tells you exactly where it went wrong, on the first run.