A model can give two different answers to the same request. That doesn’t excuse losing the request, charging twice, or forgetting which tool calls actually completed.
I separate a poor answer from a broken operation. A weak interpretation needs better examples, evaluation or a chance for the user to correct it. A timeout, duplicate action or lost file needs an engineering fix. Changing the prompt won’t recover missing state.
Give the job an ID. Record attempts and tool results. Put limits on retries and spend. Save intermediate work when it is useful. Those are familiar habits, and they remain useful when a model is deciding the next step.
The difficult boundary is a tool call with an external side effect. If sending a message succeeds but the reply is lost, repeating the call may send it again. Where possible, use idempotency keys. Otherwise reconcile the outcome before retrying, and keep the uncertainty visible.
I don’t expect identical prose from a generative system. I do expect it to distinguish “I planned this,” “I attempted this” and “I confirmed this happened.” That’s a reasonable place to start.