A big task doesn't get done in a single turn

In the previous Track you learned to decompose a task inside a single prompt: role + context + examples + format, all together. For small, well-scoped tasks, that's enough.

But for big tasks (an incident report, a migration plan, a technical proposal) a single prompt brings back a mediocre output on five things at once. The timeline comes out weak because the model spent tokens thinking root cause. The impact comes out generic because it ran out of attention.

The multi-turn equivalent technique: decompose the task into a sequence of turns, where each turn delivers ONE piece and you review it before asking for the next.

Why it works

In a single prompt, the model has to satisfy 5 objectives at the same time. Quality per objective drops. In separate turns, each turn has ONE objective. the model puts all its tokens on it. and you review it before the error propagates to the next.

Same idea as in software: a function doing 5 things is hard to test. 5 functions doing 1 thing each are easy. Multi-turn is the "one function at a time" version of prompt engineering.

The 4 rules for decomposing well

1. One piece per turn. If your ask has an "and" in the middle, split it.
2. Review before continuing. Each turn is a checkpoint. If the timeline has wrong timestamps, don't move on. fix it right there.
3. Order matters. What comes later depends on what came before. Timeline → cause → impact → actions, not the other way.
4. Close with an explicit assembly. The last turn asks to merge the pieces into a coherent output.

When NOT to decompose

For small tasks (classify a message, extract a date), decomposing is overkill. A solid prompt is enough. Multi-turn decomposition pays off when:

• The task has 3+ independent pieces.
• Early errors propagate to later pieces.
• You can add value reviewing between turns.

On the right you have an incident report for the captain. Hex put the 6 turns out of order. Put them in order.