A city treasury office launches eight parallel subagents, each drafting one section of a quarterly financial report. The published report must present the sections in a fixed, mandated order. What must the merge step do?

Parallel execution trades ordering guarantees for speed. A fan-out says nothing about which branch returns first—a section needing three tool calls will often finish before one needing fifteen, regardless of launch sequence. When the published artifact has a mandated order, that order has to come from somewhere other than timing.

Assigning each of the eight treasury subagents an explicit ordering key at launch and sorting on it at merge makes order a property of the data rather than an accident of scheduling. The fan-out stays fully parallel, and the assembled quarterly report comes out identical run to run because the sort is deterministic.

Appending on arrival assumes completion order tracks launch order, which is exactly the guarantee parallelism gives up, so section order would vary between runs; having all eight write into one shared document introduces concurrent writes to a single target, a data-loss risk that does not even address ordering; abandoning the fan-out surrenders the speedup to avoid a problem one integer per subagent already solves, and its premise that parallel results cannot be ordered is false.

Exam caveat: the ordering key must survive the round trip—if a subagent returns prose without echoing its key, the merge step has nothing to sort on. Operational check: require each returned result to carry its section index, and have the merge assert that indices one through eight each appear exactly once before the report is assembled.