A retry looks simple from the screen
A timeout can seem like a small interruption: run the call again and continue. For a read-only lookup, that may be sensible. For a payment, message or database write, the same habit can duplicate an effect whose first receipt was lost.
The system must distinguish no action, partial action, completed action with a missing acknowledgment, and an unknown state. An error message alone may not tell which occurred. Treating every failure as harmless converts uncertainty into another tool call.
Find out whether anything happened
Suppose a print order times out after the vendor accepts it. A blind retry could buy a second print. An idempotency key identifies one intended order; when supported, supply it before the first submission and reuse it on a safe retry. Otherwise use the vendor's documented reconciliation route. A missing search result may still leave the outcome unknown; it is not permission to reorder.
PHS's tool design defines success and failure semantics. The Governor consumer contract proposes explicit structured errors and execution references. Its scar-and-repair design concerns identity-relevant consequences, not automatic scars for ordinary transport failures. These are architectural requirements, not evidence that a given vendor supports safe retries.
Pause here: Could the first attempt have changed anything despite the reported failure?
Repair the consequence, not just the error
A failed call can also disclose data or consume a scarce resource before it fails. Authorized repair may require revoking access, notifying an owner, restoring a file or correcting a ledger; its effect should be checked. The response should be proportionate to what was at stake, not to how red the error box looked.
We should neither dramatize every timeout nor shrug at one. Ask what operation was attempted, what state is independently visible, whether a retry is safe and who needs to know. That turns a failure from an inconvenience into usable evidence.
My answer: A failed call may be harmless, partial or already effective. Establish what happened, or use a documented retry that prevents duplication; otherwise keep the outcome unresolved and make any authorized repair.