Quick answerWhat should the agent do if the customer says they'd rather keep waiting past the hard threshold? Respect the customer's stated preference for staying in the conversation, but still trigger the internal escalation and ops alert at the hard threshold regardless, since a call stuck that long is a system-health issue independent of what the customer wants to do while it's investigated. Does a slow call need the same accuracy validation as a completed one, once it does return? Yes; a call returning late doesn't get a pass on the plausible-but-wrong-result validation any other tool output goes through. Slowness and inaccuracy are independent failure modes and both checks should run regardless of how long the call took.
Quick answer
Set a tiered timeout, not a single cutoff: a short first threshold (a few seconds) after which the agent should proactively tell the customer the call is still running rather than going silent, a second, longer threshold (tens of seconds to low minutes depending on the operation) after which it should offer a choice, keep waiting or switch to an alternative path, and a hard outer threshold after which it should stop waiting and escalate to a human or a documented fallback regardless of what the customer chooses. The core design goal is never letting a customer sit in silence wondering whether the agent is still working, and never letting a truly stuck call run indefinitely.
Why this is neither a wrong-result problem nor a hard-failure problem
A tool call returning a plausible but wrong result is an accuracy problem: the call completed, but you can't trust what it returned. A hard tool or API outage is a different problem again, one with a clear failure signal the agent can detect and respond to immediately with a fallback. The genuinely hard case this post addresses sits between those two: the call hasn't failed and hasn't returned, it's just slow, or stuck in a pending state a multi-system workflow can produce, an inventory check waiting on a slow downstream warehouse system, a payment authorization waiting on a processor, a multi-step booking waiting on a partner API. The agent has no error to catch and no bad result to validate, only silence, and silence is the state that's easiest to design badly for.
Why silence is worse than either alternative
A customer facing a clear error message understands what happened. A customer facing a clearly wrong-looking result can at least sense something's off. A customer facing silence, no error, no result, just a spinner or nothing at all, has no information and no ability to judge whether to keep waiting, retry, or give up, and will typically assume the worst well before an objectively reasonable timeout has actually elapsed. The design goal is closing that information gap immediately, well before the call itself needs to time out.
Setting the three thresholds
First threshold, proactive status update: for anything expected to take more than two or three seconds, have the agent say so before the customer has to ask, "checking with the warehouse system now, this can take a moment." Second threshold, offer a choice: once a call has run past its expected duration by a meaningful margin, tell the customer explicitly and offer a real choice, continue waiting, or take an alternative path if one exists (a manual follow-up, a different data source). Third threshold, hard escalation: set an outer bound past which the agent stops waiting regardless of the customer's preference, since an indefinitely pending call is a system health signal that needs a human or an automated ops alert, not just a patient customer. Calibrate each threshold to the specific operation's normal latency distribution, not a single global number, since a payment authorization and a multi-warehouse inventory check have very different normal ranges.
Escalation and logging beyond the single conversation
Every call that crosses the hard outer threshold should log enough detail (which system, which operation, how long it actually ran) to feed an ops-facing latency dashboard, since a rising rate of hard-threshold breaches on a specific downstream system is an early warning of a developing outage, worth catching before it becomes the harder failure case the tools-down fallback design already has to handle. It is also worth wiring the same event stream into a self-imposed circuit breaker for when your AI agent's own error rate spikes, since a spike in stuck or slow calls on one system is frequently the earliest signal of the same underlying degradation an error-rate circuit breaker is designed to catch.