An agent calls a `charge_customer` tool to process a one-time payment. The HTTP request to the payment provider actually succeeds and the charge goes through, but the response is lost to a network timeout before the agent's tool-calling code sees it. Reading this as a failure, the agent's loop retries the same charge_customer call with the same arguments. If the payment provider's API accepts a caller-supplied idempotency key tied to that specific transaction, and the tool is built to reuse the same key on a retry of the same logical action, what happens on the second attempt?
- The payment provider processes the charge a second time regardless of the key, since idempotency keys only affect logging and have no effect on whether the underlying charge is executed again
- The payment provider recognizes the repeated key as the same logical request and returns the original charge's result instead of executing a second, duplicate charge, preventing the customer from being billed twice for what the agent's retry logic mistakenly treated as a fresh action
- The retry is blocked entirely before it reaches the payment provider, because a repeated idempotency key causes the agent's own tool-calling code to refuse to send the request at all
- The idempotency key causes the payment provider to automatically refund the first charge and only keep the second one, treating the first attempt as invalid
Why B? And why not the others?
Correct answer: B. The payment provider recognizes the repeated key as the same logical request and returns the original charge's result instead of executing a second, duplicate charge, preventing the customer from being billed twice for what the agent's retry logic mistakenly treated as a fresh action
An idempotency key lets a caller mark a request as representing one specific logical action rather than a fresh one; when the same key is attached to a retried call, a provider that supports this checks whether it has already completed a request under that key and, if so, returns the original result instead of executing the operation again -- which is exactly the protection needed here, since the agent's retry was triggered by a lost response to a charge that had, in fact, already succeeded, and without this mechanism the customer would be billed twice for a single intended action. The option claiming idempotency keys only affect logging is wrong: their entire purpose is to change execution behavior on the provider's side, skipping re-execution rather than merely recording that a repeat happened. The option claiming the retry never reaches the provider at all is wrong: the deduplication check described here happens on the provider's side once the request arrives, not by the calling code silently refusing to send it. The option describing an automatic refund of the first charge is wrong and inverts the mechanism: the provider keeps and returns the result of the original successful charge rather than treating it as invalid.
Source: General API idempotency-key pattern as applied to agentic tool retries (e.g. TianPan.co, 'The Idempotency Problem in Agentic Tool Calling'; 'Idempotent AI Agents: Retry-Safe Patterns for Production') -- describes attaching a stable key to a request so a provider that sees the same key twice returns the original result instead of re-executing the side effect