Splitting a task that keeps failing

The prompt that is four prompts

Read these 30 customer reviews, work out the main complaints, decide which are worth fixing given that we have one developer, and write a one-page proposal for the board.

That will produce something. It will be shallow, because four different jobs are competing for the same output, and the last one (the proposal) dominates, since it is what the answer must look like.

Split it:

1. Extract. “For each review, output: the complaint in five words, the product area, and whether the customer stopped using us. One line each. No analysis.”
2. Group. “Here are 30 lines. Group them into themes. Give each theme a name, a count, and the two lines that best represent it.”
3. Judge. “Here are the themes with counts. We have one developer for six weeks. For each theme, estimate the effort as small, medium or large, and say what we would need to know to be sure.”
4. Write. “Here is the analysis. Write a one-page proposal for the board. They have five minutes and no technical background.”

Four prompts, ten minutes, and every one of them is checkable. If the grouping is wrong you see it at step two and fix it there, instead of finding a strange conclusion in a finished proposal and not knowing where it came from.

The three signs a task should be split

It contains “and then”. Read and summarise and decide and write. Each “and then” is a boundary.

The output shapes conflict. Step one wants a list. Step four wants prose. A single prompt has to choose, and you get whichever the last instruction implied.

You cannot check the answer. If you would have to redo the work to verify the result, the task is too big. Split until each step produces something you can glance at and accept or reject.

Where to put the boundaries

Split where the shape of the output changes, not by topic.

Extraction produces rows. Grouping produces categories. Judgement produces a ranking with reasons. Writing produces prose. Those are four different artefacts, and each is easy to check in its own terms and impossible to check inside a finished document.

The other good boundary is where you want to intervene. If you would want to correct the grouping before anything is built on it, that is a step boundary by definition.

Keep the intermediates

The lines from step one are worth more than the proposal. They are reusable: next quarter you run the same extraction on new reviews and compare. They are checkable against the source. And they let you rerun step three with different assumptions (two developers instead of one) without redoing anything else.

People throw these away and then repeat all four steps a month later.

Where splitting costs you

Two honest downsides.

Errors propagate and get laundered. If step one mislabels six reviews, steps two to four build on it confidently, and by the proposal there is no trace of the error. A single prompt at least had the original text in front of it. So check the early steps hardest: they are cheap to check and expensive to get wrong.

You lose cross-step context. A detail that mattered to the final judgement may not have survived extraction. Mitigate by carrying identifiers: keep the review number on every line so any step can go back to the source.

When not to split

If the task fits in one pass and comes back right, leave it alone. Splitting is a repair for a failure, not a discipline to apply pre-emptively. Three prompts where one worked is two extra places to make a mistake.

The trigger is straightforward: you have tried once, the answer is confidently wrong or shallow, and you cannot tell which part of it went wrong. That last clause is the real signal. A task you cannot debug is a task that needs splitting, whatever its size.

Splitting is what an agent does, in slow motion

If you have wondered what people mean by an AI agent, this is most of it: a task broken into steps, with the output of each fed into the next, and something deciding what to do at each stage.

Doing it by hand first is worth more than it sounds. You find out which steps are unreliable, which need a human look, and where the errors enter, before automating any of it. Nearly every agent that fails in production fails at a step whose author never ran it manually and never saw how often it goes wrong.