An orchestrator agent manages a pipeline of 6 sequential specialist agents: document parser → entity extractor → relationship mapper → knowledge graph builder → query generator → answer synthesizer. The pipeline fails approximately 3% of the time at the relationship mapper stage. What orchestrator design pattern minimizes reprocessing cost on failure?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — d is correct because checkpoint-based orchestration is the standard pattern for expensive sequential pipelines with non-trivial failure rates: persisting stage outputs means a 3% failure at stage 3 only requires rerunning stages 3–6, not stages 1–6. This is particularly important when early stages (document parsing, entity extraction) are expensive or time-consuming.
Full explanation below image
Full Explanation
D is correct because checkpoint-based orchestration is the standard pattern for expensive sequential pipelines with non-trivial failure rates: persisting stage outputs means a 3% failure at stage 3 only requires rerunning stages 3–6, not stages 1–6. This is particularly important when early stages (document parsing, entity extraction) are expensive or time-consuming. A is wrong because restarting from stage 1 on every failure multiplies the cost of the 3% failure rate by the full pipeline cost — stages 1 and 2 are rerun unnecessarily. C is wrong because parallel execution of sequential pipeline stages is logically incorrect — the knowledge graph builder requires entity extractor output, which requires document parser output; parallelism cannot substitute for data dependencies. B is wrong because skipping a failed stage and continuing with invalid downstream inputs produces corrupt outputs that may not be detected until much later, requiring full pipeline reruns; surface the failure at the point of occurrence.