Your retry advice and your autonomy ladder meet at one field: who mints the idempotency key. If the model generates it, a re-plan after a timeout can produce a fresh key, and the payment system will correctly treat the second refund as a new request. The key has to come from the system, derived from the approved intent and stored before the first call.

The same binding is what makes step two of the ladder hold. "Carry out refunds a human already approved" is only safe if the approval names the exact order, amount and customer, and the executor refuses when the call differs. Otherwise the human approved one refund and the agent executed a similar one.

An approval ID that doubles as the idempotency key covers both. Each approved intent can produce at most one refund, and the trace links the approver to the change the payment system recorded. That gives your "did it stay inside its limits" check something concrete to compare against.