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?

Idempotency keys are the standard solution to duplicate-execution problems in distributed systems. By generating a key deterministic to the conversation and tool call (both of which are stable on retry), tool implementations can check whether this operation was already executed and return the cached result rather than re-executing. Claude's tool_use blocks include a stable id field that serves as a natural idempotency key component. Option A (database transactions) works for storage operations but not for external side effects like sending emails — you cannot roll back a sent email. Option C (60-second timeouts) reduces but does not eliminate timeouts, and doesn't address the duplicate-execution problem when timeouts do occur. Option D (indefinite waits) removes timeouts but introduces unbounded blocking — a hung tool call would indefinitely stall the conversation and exhaust connection resources.