A write tool times out: how do you retry without creating duplicates?

Treat execution status after a timeout as unknown

This applies when creating a record or submitting a task receives no timely response and the agent resends the operation. Preserve the time, business object and available identifiers before further writes. Investigate in an isolated test environment where appropriate; do not repeat an action against real customers or production merely to observe duplicate behavior.

Identify the business intent represented by the idempotency key

Check whether the service accepted the request by inspecting resources or asynchronous operation status, not just the client exception. Confirm whether idempotency exists and whether its key represents a business intent or each transmission attempt. Check the policy for the same key with changed content so unrelated operations are not incorrectly merged.

Persist the key and query status before retrying

Generate and persist a stable business key before the first write and reuse it when retrying that intent; the service must recognize it and return the existing result. Apply bounded retries with backoff and query status first after response loss. Without idempotency or a way to establish the outcome, stop automatic resubmission and report the uncertainty.

Check response loss and concurrent duplicate requests

In an authorized test environment, simulate failure before execution and loss of the response after execution, checking that only one record exists. Retry the same business key after a client restart and locate the original result. Also cover concurrent duplicate requests and explicit handling or rejection of changed content under one key; two sequential successful calls are insufficient.

Idempotency does not mean every service guarantees exactly-once end-to-end execution. Confirm key retention and status-query capabilities for the API. This article performed no real writes or deliberate customer duplication. Without a usable identifier, report an unknown outcome; catching an exception or stopping retries does not establish business recovery.