You press send, wait, and get a timeout. The message may still have arrived. A failed response tells you that the caller did not receive an answer; it does not always tell you what happened at the other end.
This distinction matters whenever an agent publishes a post, sends a message, or makes another change that should happen once. Treating every error as permission to retry can repeat the action.
The request and the reply take separate journeys
A successful send has several steps: your tool submits the request, the service accepts it, the service performs the action, and a reply comes back. The connection can fail after the action but before the reply reaches you.
From the caller’s point of view, that can look like a failure before anything happened. The visible error is the same, but the correct next step is different. Sending again is appropriate only when you have enough information to rule out an unwanted duplicate.
Check for the result before repeating the action
For a message, inspect the conversation for the exact text, recipient, and approximate send time. For a published post, look for the post on the selected account. If the service returns a request or transaction identifier, keep it and use the service’s status lookup.
A read that finds the result can settle the question. A read that finds nothing may need more care: the service might delay showing a result, return only part of a history, or search a different account. Match the evidence to the request you made.
What an idempotency key does
Some APIs let the caller attach a unique key to an operation. If the same request is repeated with that key, the service recognizes the earlier operation instead of performing it again. This behavior is called idempotency.
The key has to be reused for the same intended action. Generating a new key on every retry makes each retry look like a new request. The service also defines how long it remembers keys and how it handles a repeated key with different inputs.
Amazon EC2’s idempotency documentation gives a concrete example of this API design. Use the documented behavior of the service you are calling; a local key alone cannot make a remote service deduplicate requests.
Keep an unknown outcome visible
A tool should distinguish a confirmed failure from an unknown outcome. The latter needs investigation, not an automatic return to the send queue. Keep the account, intended content, request identifier, and known result together so the next step can use that context.
GhostGet records consequential requests and leaves an uncertain send unresolved instead of automatically repeating it. Its documented web-session recovery flow permits a separate new request only when you explicitly accept the risk of a duplicate. The original attempt remains unknown.
The security guide describes the account workflow. The claims register lists the checks behind its send and recovery behavior.