Splitting refunds.draft from refunds.submit is the pattern that has worked best for us too, since it lets the approval step live in your own system rather than in the client's confirmation dialog. One thing I'd add to the draft-handle design: bind the draft_id to the arguments hash at creation, so a model can't get a human to approve one amount and then submit with a different one. How are you handling approver identity, and does the approving human see the raw tool arguments or a rendered summary?