In a multi-agent deployment pipeline, the testing agent fails to complete its task after 3 retries. The deployment must not proceed without passing tests. What should the orchestrator do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A fire alarm that gets ignored after three rings isn't a safety system. When a critical agent fails past its retry limit, the pipeline must stop, preserve the evidence, and get a human involved — not find creative ways to continue without the critical gate.
Full explanation below image
Full Explanation
In agentic pipelines, failure escalation paths are as important as the happy path. When a critical agent (one whose success is required for safe progression) exhausts its retries:
Correct escalation pattern: 1. Halt the pipeline to prevent downstream steps from executing on an untested artifact. 2. Preserve state: Store the failing agent's logs, intermediate outputs, and error details in a durable location (artifact upload, Issue comment). 3. Notify: Create a GitHub Issue, send a webhook notification, or trigger a pager alert to notify the responsible team. 4. Do not destroy state: The preserved logs are critical for diagnosing and fixing the failure.
Why B is correct: Halting with state preservation and notification is the safe failure mode. It prevents unsafe deployments, preserves diagnostic information, and gets a human involved to resolve the root cause.
Why A is wrong: Deploying despite a test failure violates the basic purpose of the testing gate. Flagging in deploy logs is a post-hoc record but does not prevent the unsafe deployment.
Why C is wrong: Skipping testing to reach the security scan phase bypasses a required quality gate. Security scanning cannot substitute for functional testing.
Why D is wrong: Re-running the full pipeline from the beginning consumes resources, discards useful partial state, and is unlikely to succeed if the root cause is a persistent failure (not a flaky transient issue). It should only be considered after diagnosis.