An LLM-powered agent has a tool that charges a customer's payment method, and the agent's HTTP call to your backend times out after the charge has actually already been processed. The agent's retry logic then calls the same tool again with the same arguments. What design choice prevents this from resulting in a duplicate charge?
- Having the tool accept a unique idempotency key per logical operation, so the backend can recognize a retried call with the same key and return the original result instead of processing the charge a second time
- Increasing the model's `max_tokens` limit, so the agent has enough space to reason more carefully about whether a retry is safe before calling the tool again
- Lowering the model's `temperature` to 0, so the agent always generates the exact same tool call arguments and therefore never issues an unintended duplicate request
- Disabling the agent's ability to call tools more than once per conversation, so any repeated call is rejected outright regardless of what happened to the first one
Why A? And why not the others?
Correct answer: A. Having the tool accept a unique idempotency key per logical operation, so the backend can recognize a retried call with the same key and return the original result instead of processing the charge a second time
The generally correct fix is at the tool and backend layer, not the model layer: attaching a unique idempotency key to each logical operation lets the backend detect that a retried request represents the same intended operation and short-circuit to returning the original result rather than executing the side effect again, which is the standard pattern for exactly this kind of network-timeout-then-retry scenario in payment and other side-effecting APIs, and is the recommended orchestration-layer practice for agent tool calls that can be retried. Increasing `max_tokens` only affects how much text the model can generate and has no bearing on whether a backend call is executed twice. Lowering temperature to 0 only makes the model's chosen arguments more deterministic across similar prompts; it does nothing to prevent the exact same request from actually being re-sent and re-executed after a timeout, since the retry happens regardless of how deterministic the arguments were. Blanket-disabling repeat calls to any tool would also break legitimate cases where a tool is meant to be called multiple times with different arguments in the same conversation, making it too blunt a fix for this specific failure mode.
Source: OpenAI, 'In production' guide for Agentic Commerce (idempotency keys for retried tool/side-effect calls), https://developers.openai.com/commerce/guides/production