The problem
Refund tickets are repetitive and risky at the same time. Most are duplicate charges that take a minute to confirm, but an agent that refunds the wrong charge, or refunds twice, costs real money and trust.
How the workflow runs
A new ticket triggers the run. An LLM step classifies intent and pulls out the order or charge it mentions. Tool steps fetch the account and the last 60 days of charges, and a policy step checks the refund window.
Refunds under $200 on a confirmed duplicate go straight through, with an idempotency key on the charge ID so a retry can never refund twice. Anything larger pauses in waitForEvent until a support lead approves in chat.
What changes
Support leads only see the refunds that need judgement. Every decision, automatic or human, lands in the trace with the charge IDs and the policy that allowed it, which is what finance asks for at month end.
