Splitting a task can cost you the thing that held it together

Decomposition is advice, not a law

Splitting a job into stages is usually right. Each stage is inspectable, each can be corrected without disturbing the others, and a failure has an address. Applied indiscriminately, though, it produces processes that are more complicated than the work and worse at it.

The tasks that suffer are the ones where a decision in one part depends on material in another. Editing a long document for length is the clearest example: deciding what to cut requires knowing what else is present, and a per-section editor cannot know that, so every section is trimmed by the same proportion regardless of which parts were carrying the argument.

The symptom is a result that is locally reasonable and globally wrong. Every piece defensible, the whole thing incoherent — repetition between sections, an argument that restarts three times, a summary that does not match what it summarises. That is the fingerprint of a split that should not have been made.

The test is whether the parts need to see each other

Ask what a step needs to know that lives outside itself. Translating a paragraph needs only that paragraph plus a glossary, so splitting is free. Deciding whether that paragraph should exist requires the whole document, so splitting destroys the decision.

This gives a usable rule. Split where the work is uniform and per-item — extract, classify, convert, translate, format. Keep whole where the work is comparative or structural — prioritise, cut, order, resolve contradictions, decide what matters. The first category is where volume lives; the second is where judgement does.

The intermediate case is common and has a decent answer. Produce a compact global view first — an outline, an index, a list of what each section contains — and pass that to every local step. The steps stay small and each one knows enough about the whole to make a sensible local decision.

Splitting adds machinery, and machinery has failures of its own

A single request either works or does not. A six-step process has six places to fail, five interfaces where a format can drift, a retry policy to design, and an error at step two that quietly poisons everything downstream. That is a real cost and it is usually left out of the comparison.

It also gets slower and more expensive per unit of work, because material is re-supplied at each stage. A chain that passes an entire document through four steps is doing four times the reading, which matters when the job runs on a schedule or across thousands of items.

The maintenance cost is the one that bites later. Every step is a place someone has to understand before they can change anything, and a process with several stages tends to be modified by whoever built it and avoided by everyone else. Fewer, larger steps are frequently the more durable design.

Split by the boundary in the work, not by the count

When splitting is right, the seams should follow natural divisions rather than an arbitrary number of stages. A good boundary is one where the intermediate output is meaningful on its own — a list, an outline, a set of extracted facts, a draft — because something you can look at is something you can check.

A poor boundary produces intermediate output that is only meaningful to the next step. If you cannot say what a stage produces without describing what happens afterwards, the split is administrative rather than real, and it adds a failure point without adding any inspectability.

Volume is a legitimate reason to split, separately from structure. If the input genuinely does not fit in one pass, division is forced, and the design question becomes how to give each piece enough surrounding context that its local decisions are not made blind.

Start whole, split under pressure

The pragmatic order is to attempt the task in one request first, even when you expect it to be too much. Either it works, in which case you have saved yourself a process, or it fails in a specific way that tells you exactly where the seam should be.

Splitting speculatively is how people end up with elaborate chains for jobs a single well-specified request handles. The chain then becomes the thing being maintained, and the original question of whether it was needed is never revisited because it now looks like infrastructure.

Reversing a split is also worth doing occasionally. Tools change, capacity grows, and a division that was necessary a year ago may now be pure overhead. A process that has never been simplified is usually carrying at least one step that exists for a reason that no longer applies.