An orchestrator agent calls an MCP tool to deploy a configuration change to a staging environment. The tool call exceeds its timeout threshold and returns a timeout error — but the agent cannot determine whether the deployment actually completed before the timeout occurred. What is the most appropriate error-handling strategy?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A timeout on a non-idempotent operation is like mailing a check without getting a delivery receipt — retrying blindly means you might pay twice. The right move is to stop dependent steps, check the actual state, and escalate when the state remains ambiguous. Humans need to be in the loop on non-recoverable uncertainty, not just on failure.
Full explanation below image
Full Explanation
A deployment operation is typically non-idempotent — running it twice may create duplicate infrastructure, double-apply configuration, or cause partial state corruption. When an MCP tool call times out and the success/failure state is unknown, the agent cannot safely retry without risk.
Option A is wrong. Blind retries with exponential backoff are appropriate for idempotent operations where running the same call multiple times produces the same result safely. Deployment operations are often not idempotent. Retrying without first checking deployment state could result in duplicate deployments, conflicting configuration, or partially applied changes on top of partially applied changes.
Option B is wrong. While it is correct to halt and not proceed, simply marking the pipeline as failed and waiting passively is insufficient. The agent should actively attempt to determine the deployment state using available status-check tooling before purely handing off to a human. Passive waiting wastes time when automated state verification is possible.
Option C is a strong partial answer but is wrong because it stops at checking state and deciding to retry or rollback — it omits the critical escalation step when state remains ambiguous after the status check. Some deployments may show inconclusive status (for example, in progress indefinitely), requiring human judgment. An agent must know its own limits and escalate appropriately.
Option D is correct. The full correct pattern is: block all downstream pipeline steps that depend on this deployment; invoke a status-check tool to get the actual deployment state; if the state is definitively successful then proceed; if definitively failed then rollback; if ambiguous then escalate to a human operator. This combines automated recovery where possible with appropriate human escalation for non-recoverable uncertainty.