An agent calls an external search tool to gather context before generating a code fix. The search tool has a 30-second timeout but occasionally takes longer than that under high load, causing the tool call to time out. When this happens, the agent raises an unhandled exception and terminates the entire task. What is the correct pattern to handle this scenario?

External tool calls in agentic workflows are often for gathering optional or supplemental context rather than for mandatory inputs. When such a call times out, the correct response is graceful degradation — the agent acknowledges the unavailable data and proceeds with whatever context it already has, possibly noting reduced confidence or limited context in its output.

The implementation pattern is: catch the timeout exception specifically, log it with sufficient detail for debugging, and continue execution with a fallback path (cached results, empty context, or a note that the search was skipped). This keeps the overall task alive and produces partial value rather than complete failure.

Option A (increase timeout to 120 seconds) reduces timeout frequency but does not address what happens when a timeout does occur. Under heavy load, even a 120-second timeout may be exceeded. The fundamental problem — unhandled exception on timeout — remains.

Option C (silent fail in try/catch) is the opposite of the correct fix. Silent failure hides the timeout from monitoring and debugging, producing no output and no log, making the failure invisible. The task should be logged and should produce partial output, not silence.

Option D (remove the search tool) eliminates the timeout risk by removing capability rather than handling it gracefully. Removing a useful tool to avoid its failure is the least desirable engineering approach — it degrades the agent's capability rather than making it resilient.

Graceful fallback keeps optional-tool failures from becoming task-terminating failures.