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
Here's the deal — checkpoint-based orchestration is right because persisting each stage's output lets you resume from the last successful checkpoint after a relationship mapper failure, so you rerun only the remaining stages instead of the whole pipeline. That saves the expensive document parsing and entity extraction work from being repeated.
Full Explanation
Checkpoint-based orchestration is correct because it is the standard pattern for expensive sequential pipelines with non-trivial failure rates: persisting stage outputs means a 3% failure at the relationship mapper only requires rerunning the relationship mapper and downstream stages, not the entire pipeline. This is particularly important when early stages, such as document parsing and entity extraction, are expensive or time-consuming. The option that restarts the entire pipeline from the document parser on any failure is wrong because it multiplies the cost of the 3% failure rate by the full pipeline cost, since the document parser and entity extractor are rerun unnecessarily. The option that runs all six stages in parallel to reduce end-to-end latency 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, and parallelism cannot substitute for data dependencies. The option that skips the relationship mapper and continues with the knowledge graph builder using partial data is wrong because 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.