A school district orchestrator fans out five parallel subagents, each summarizing one set of board policies. Three return usable summaries; two fail partway through with tool errors. How should the orchestrator proceed?

Parallel subagents are independent by construction: separate contexts, disjoint inputs, no shared state. That independence has a direct consequence for failure handling—one slice failing carries no information about whether another slice's output is valid—so recovery should operate at the granularity of the slice, not the batch.

Treating each of the five board-policy summaries as a unit of work with its own status lets the orchestrator keep what succeeded and relaunch only what did not. The re-run is cheap because it is scoped to two slices, and the merged result is still complete because every unit reports success before assembly.

Discarding all five and re-running the whole fan-out pays for three summaries twice and adds latency to fix a problem those three never had; recording the failed policy sets as having produced no findings converts an infrastructure error into a substantive claim about district policy, yielding a summary that looks complete and is not; retrying inside the contexts that already failed misreads delegation—a retry launches a fresh subagent context, and there is no partial state waiting to be resumed.

Exam caveat: keeping partial results is only safe when the slices are genuinely disjoint; if two subagents consumed a shared input that was itself corrupt, the successful outputs may be wrong for the same reason the failures were. Operational check: have each subagent return a status field alongside its summary, and require the merge step to assert every slice identifier is present and marked complete before publishing.