A B2B SaaS platform uses Claude's tool use feature for an AI assistant that can query a CRM, send emails, and update records. During load testing, they discover that when Claude requests a tool call, the orchestration layer occasionally times out waiting for tool execution, leaving the conversation in an ambiguous state. On retry, Claude is called again without the tool result, causing it to re-request the same tool call — potentially creating duplicate CRM records or duplicate emails. What architectural pattern prevents this?

Implementing idempotency keys for all tool calls is the correct architectural pattern. By generating a deterministic key from the conversation identifier and tool call identifier, both of which are stable on retry, tool implementations can check whether the operation was already executed and return the cached result rather than re-executing side effects. Claude's tool_use blocks include a stable identifier field that serves as a natural idempotency key component. Wrapping all tool calls in database transactions that automatically roll back on timeout works for storage operations but not for external side effects like sending emails, because you cannot roll back a sent email. Switching to synchronous tool execution where Claude waits indefinitely for tool results removes the timeout failure mode but introduces unbounded blocking; a hung tool call would indefinitely stall the conversation and exhaust connection resources. Setting tool execution timeouts to 60 seconds reduces but does not eliminate timeouts, and it does not address the duplicate-execution problem when timeouts do occur.