A single well-crafted prompt handles a single well-defined task. Most real business processes aren't single tasks, they're a sequence: extract, then classify, then draft, then check. Chaining is the practice of designing that sequence deliberately, as a series of connected steps each doing one job well, rather than asking one enormous prompt to do everything at once and hoping the output holds together.
Why one giant prompt usually underperforms a chain
A single prompt asked to extract data from a document, classify it, draft a response and check its own work tends to do all four tasks adequately rather than any one of them well, because the instructions compete for the model's attention within one pass. Breaking the same process into four separate, focused calls, each with a narrow job and its own clear success criteria, consistently produces better output at each individual step, even though it means more total API calls.
A practical chaining pattern
Step one: extract raw information from the source (an email, a document, a form) into a structured format
Step two: classify or route the extracted information based on type, urgency or category
Step three: generate the actual output (a draft, a summary, a response) using the structured, classified input
Step four: a separate verification pass checking the output against the original source before it's used
A worked example
A Melbourne insurance broker chains four steps to process an incoming claim email: extract the claim details into a structured record, classify urgency and claim type, draft an acknowledgement and next-steps email using that structured record, then a final pass checking the draft against the extracted details for any mismatch. Each step costs a small amount of token spend individually, but the combined accuracy of the chained process caught errors a single-prompt version had been missing roughly 1 in 12 times during a two-week comparison test the broker ran before switching over.
Where chaining adds cost without adding value
Not every task benefits from being broken into steps. A simple, low-stakes task, a quick internal summary, a one-line classification, doesn't need four separate calls when one does the job adequately and the cost of an occasional minor error is genuinely low. Reserve chaining for tasks where each step's output feeds meaningfully into the next, and where getting an intermediate step wrong would compound into a worse final result.
If you're running a workflow that feels like it's asking too much of a single prompt, get in touch through /contact and we'll help you design it as a proper chain.
What the extra API calls actually cost
A four-step chain typically costs more in raw token spend than a single combined prompt, often by 30-50%, because each step re-sends relevant context. For the Melbourne broker's claims workflow, that difference worked out to roughly $180 extra a month across their claim volume. Against the accuracy improvement (catching the 1-in-12 error rate that a single-prompt version was missing) and the downstream cost of a mishandled claim acknowledgement, that $180 a month was an easy trade to make once it was actually measured rather than assumed to be prohibitively expensive.
The token cost of chaining also drops significantly once prompt caching is applied to the shared context each step re-sends, since the source document or extracted record doesn't need to be recomputed fresh on every call. Combining chaining with caching typically claws back most of the raw cost difference against a single-prompt approach, while keeping the accuracy benefit of the broken-out steps.
A useful discipline when designing a new chain: sketch the steps on paper first, labelling exactly what goes into each one and what comes out, before writing a single prompt. This forces clarity about where one step's responsibility ends and the next begins, which is usually where a poorly designed chain breaks down, a step that tries to do two jobs at once because the boundary wasn't clearly drawn before the build started.
Chains also make debugging dramatically easier than a single giant prompt. When a four-step chain produces a wrong output, checking each step's individual result quickly narrows down which link in the chain went wrong. A single monolithic prompt producing a bad output offers no such visibility, leaving a team guessing at which part of a long, dense instruction caused the failure.
For a team just getting started with chaining, the simplest first project is a workflow already running as one overloaded prompt today. Splitting it into two clean steps, rather than four or five, is a manageable first attempt at the pattern, and it usually reveals immediately whether the added clarity is worth the extra token cost for that specific task before committing to a more elaborate chain.
