AI saw no reply and tried again. Could the first action already have happened?

A missing response does not establish that a writing action failed. Check the existing result and the service’s retry rules before repeating it.

RFC 9110 distinguishes operations whose intended effect can be repeated unchanged from non-idempotent requests. It advises against automatic retries of the latter without evidence about repeat behavior or whether the original was applied.

Our local simulation created two notes

A fictional function appended a note, then threw an error to simulate losing the response after writing. Calling it again appended a second note. We tested local code, not an HTTP failure or an AI agent.

A second simulation returned the existing note

Our other function remembered a fictional operation identifier in an in-memory map. With that same identifier, a repeated call returned the first note instead of creating another. This demonstrates a mechanism; it does not establish a real service’s expiry, concurrency or recovery behavior.

Ask AI to inspect before repeating

Suggested input: “Treat the action’s outcome as unknown. Check for an existing result using the documented operation identifier or status view. Show the service’s repeat rules before proposing another write.” Keep the original details so the check refers to the same action.

A retry label is not a duplicate-prevention guarantee

If a service documents a repeat key, use its actual rules for the same logical operation. Merely inventing a new key or waiting longer does not prove the earlier action never happened. An unresolved result should remain unresolved until evidence changes it.

Published October 14, 2026. Two original in-memory function simulations were tested locally. No server, HTTP request, actual note, external app, payment, message, concurrency test or AI writing action was performed.

Sources: IETF · HTTP retries.