How would you decide whether to collapse a five-call prompt chain into one call?

## Why the question keeps coming up Every chain encodes an assumption about how much a model can do in one call, and that assumption expires. A pipeline that splits extraction, normalisation, classification, verification, and drafting into five calls was probably right when it was written and may now be pure overhead: five times the latency, five prompt preambles, four seams where information is lost, and four multipliers below one on end-to-end accuracy. As of mid-2026 the practical guidance is that consolidation deserves rechecking at every model upgrade, because the direction of travel has consistently been toward more capability per call. The failure mode on both sides is deciding by taste. Some teams chain everything because it feels engineered; others collapse everything because the code is prettier. Neither knows what it cost them. ## Make it an experiment The decision needs a golden set: real inputs with labelled correct final outputs, and ideally labels at each stage so you can attribute regressions. Build the single-call variant properly, giving it the accumulated instructions the stages carried, and run both variants over the set. Measure four things. **Quality** end to end on the labelled outputs, with the same scorer for both. **Latency** at p50 and p95, since the tail is what users feel and a chain's tail is the sum of five tails. **Cost per successful request**, counting retries and any validation calls, not cost per call. And **variance**, by running each variant several times: a single call that is right on average but unstable across runs may be worse operationally than a slower chain that is boringly consistent. Only then compare. A common outcome is that the single call matches quality within noise, halves cost, and cuts p95 by two thirds, which makes the choice easy. Another common outcome is that it matches on the easy eighty percent and collapses on the hard tail, which argues for collapsing the chain for the common path and keeping the staged path for inputs a classifier flags as hard. ## Price what you give up Quality and cost are the visible axes. Three less visible ones decide the argument as often. **Attribution.** A chain gives you a per-stage trace, so a production regression can be localised in minutes. A single call gives you an input, an output, and a hypothesis. If this pipeline is on a path where someone is paged, that trace has real operational value, and losing it should be a deliberate trade rather than a side effect. **Heterogeneous routing.** Stages are the unit at which you can send mechanical work to a small fast model and reserve the strong model for judgement. Collapse the chain and everything runs at the price of its hardest step. For high-volume pipelines that alone can dominate the cost comparison, and it can invert the result you got from a naive per-call count. **Checkpoints that must exist.** Some seams are not there for prompting reasons. A boundary where a deterministic validator runs, where a record is written for audit, or where a step must be replayable after a failure is load-bearing regardless of model capability. Those seams survive consolidation. Against that, collapsing has real gains beyond latency and cost. It removes information loss at the seams, since a single call sees the original material rather than an upstream summary of it. It removes the compounding multiplier on accuracy. And it removes code: five prompts, five schemas, five sets of error handling, five things to keep in sync when the requirement changes. ## Decide per seam The useful framing is not five calls versus one, it is which of the four boundaries earns its keep. For each boundary ask what you assert there, what you would route differently across it, and what you would log there that you could not log otherwise. A boundary that answers none of those three is overhead and its neighbours should merge. That usually leaves a two or three stage pipeline rather than either extreme, which is the shape most mature systems settle into. Be alert to the prompt-length argument, which is the weakest reason to keep a seam and the most commonly given. Splitting because a prompt got long treats a symptom; the underlying issue is often an instruction set that has accreted contradictory rules over time, and merging stages after cleaning it up frequently works better than the split did. ## Keep the decision repeatable Whatever you decide, the eval is the durable artifact, not the verdict. Keep both variants runnable behind a flag, keep the golden set current as inputs drift, and re-run the comparison when a model changes. That turns an architectural argument that would otherwise recur every six months into a scheduled measurement. It also lets you roll back cheaply when a consolidation that looked fine on the golden set turns out to have hidden a failure mode the set did not cover, which is the main risk of collapsing a chain on evidence that is narrower than production.