A GitHub Copilot agent calls an external MCP tool that intermittently fails with a timeout error. The agent currently crashes and abandons the task when this occurs. What should be implemented to improve resilience?
Select an answer to reveal the explanation.
Short Explanation
When a tool call times out, you don't pack up and leave. You catch the timeout, log it as a workflow artifact, retry intelligently, and escalate if it keeps failing.
Full Explanation
Robust agentic systems must handle tool failures gracefully without crashing or silently corrupting their outputs.
Structured error handling that catches the timeout, logs the error as a workflow artifact, and triggers an escalation path or retry logic is correct. When a timeout occurs, the agent should catch the specific error type, log it as a durable workflow artifact so the team can investigate, implement exponential backoff retry logic for transient failures, and escalate to a human or alternative path if retries are exhausted. This keeps the agent operational and the team informed.
Increasing the agent's context window size to buffer more data before the tool is called is wrong because context window size has no relationship to tool timeout errors. Timeouts are network or service-level failures, not context management issues.
Removing the external tool from the agent configuration to prevent the error from occurring is wrong because it eliminates the capability along with the error. If the tool provides necessary functionality, the solution is to make the agent resilient to the tool's failures, not to remove the tool.
Configuring the agent to silently ignore all tool errors and continue processing with incomplete data is wrong because it is dangerous. The agent's outputs may be wrong or misleading, and the team has no visibility into what went wrong. Silent failure is worse than loud failure in agentic systems.