An orchestrator dispatches a subagent to analyze 200 files in a repository. The subagent successfully analyzes 180 files but times out before completing the remaining 20. The subagent discards all results because its implementation returns only when all 200 files are complete. The orchestrator receives no output and treats the entire analysis as failed. What design would have produced a better outcome?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Getting 180 out of 200 files analyzed and then throwing all of it away because the last 20 didn't finish is like burning a manuscript because the last chapter isn't done yet. Partial results are real value. Orchestrators should stream and accumulate results as subagents produce them, so a timeout means 'done with what we have' rather than 'done with nothing.'
Full explanation below image
Full Explanation
The all-or-nothing completion model is a common but fragile design for long-running subagent tasks. It creates a binary outcome where a timeout results in total work loss, regardless of how much had been completed. A partial-results-accepting design produces incrementally better outcomes as more work is completed.
The implementation involves two changes: 1. Subagent streaming: the subagent emits results for each completed file (or batch of files) as they are produced, rather than accumulating all results in memory and returning them at the end 2. Orchestrator partial acceptance: the orchestrator collects results as they arrive from the subagent stream and marks each received result as complete. When the subagent times out, the orchestrator's accumulated results represent the work that was completed.
The orchestrator can then decide how to handle the gap: re-queue the remaining 20 files for another subagent, skip them and note the coverage gap, or escalate to a human.
Option A (increase timeout) reduces the frequency of timeouts but does not change the failure mode. If the task set grows, or if a subagent is slower on a given day, the timeout may still be exceeded and the same all-or-nothing failure occurs.
Option C (one file per subagent) is extremely granular and introduces very high orchestration overhead for 200 subagents, most of which would spend more time starting up and communicating than analyzing a single file.
Option D (compress files before analysis) is a meaningless suggestion — compression reduces storage size, not the amount of analysis work required.