LLM agents are introducing a classic distributed systems problem into AI workflows: duplicate side effects. When an agent framework retries a timed-out request or the model itself re-requests a tool call, the system must determine if the action was completed once or twice. A recent analysis by Obligra highlights that while HTTP clients have long used idempotency keys to handle this, agent architectures create three distinct layers of potential repetition: the SDK, the agent loop, and the model's own decision-making process.

The Three Layers of Accidental Repetition

Most developers only configure retries at the HTTP client or SDK level, intentionally handling timeouts and 5xx responses. However, the agent loop may re-run a step after an internal error, and the model itself may request the same action again if it does not perceive a clear result from the previous turn. These latter two sources of repetition are often unintentional and appear in logs simply as 'the agent did it twice,' masking the root cause as a logic error rather than a transport failure.

Standardizing the Fix with IETF Draft-08

The solution lies in making side-effecting operations idempotent, a pattern described in the IETF draft 'The Idempotency-Key HTTP Header Field' (draft-08, dated October 22, 2026). Although still an Internet-Draft and not yet an RFC, it mandates that keys be unique, typically using UUIDs, and strictly prohibits reusing a key with a different request payload. The specification dictates that servers should return HTTP 422 for payload mismatches and HTTP 409 if a request arrives while the original is still processing, ensuring that retries are safe and predictable.

Implementing Key Generation in Agent Loops

For agents, the critical implementation detail is key generation timing. If a tool wrapper generates a fresh UUID on every call, a model-initiated repeat receives a new key and executes the side effect again. The correct approach is to derive the key when the agent plans the action, storing it with the step record. This ensures that if the model asks for 'the same refund' in a later turn, the loop matches it to the existing step and reuses the original key, preventing duplicate refunds.

Production Considerations and Error Handling

Production systems must define clear policies for key expiration and error replay. Stripe’s v1 API, for example, removes keys after 24 hours and returns saved responses for retries, including 500 errors. This behavior is predictable but means transient failures will not be retried under the same key. Developers must also fingerprint the payload canonically to avoid false HTTP 422 errors caused by whitespace or key ordering differences in client libraries.

Key Takeaways

  • Agents retry at three layers: SDK, agent loop, and model decision.
  • IETF draft-08 requires unique keys and mandates HTTP 422/409 responses.
  • Keys must be generated at the planning step, not the execution wrapper.
  • Stripe’s 24-hour expiration and error replay model offers a production benchmark.

The Bottom Line

Treating idempotency as an afterthought is a reliability bug waiting to happen in any agentic system. Frameworks should enforce key generation at the planning layer by default, not leave it to developer discretion.