cookbook enablement · refund-enablement-guard

Issue customer refunds

Give a support agent the refund button. Customers get their money back; the order can't be paid out twice.

Agno Bedrock · Claude Haiku 4.5 ISSUE_REFUND

before Refunds sat in a human queue — an agent that retries on a flaky connection pays the same refund out again and again.

ISSUE_REFUND the line ↓ ISSUE_REFUND sends real money back to a customer.

now you ship The agent issues the refund directly. The boundary clears the real one and absorbs the retries.

1 Agent proposes ISSUE_REFUND on a Order.

2 KIFF reads the Order's current state — before anything runs.

3 State is PAID → the agent's action runs, receipt signed.

4 State is now REFUNDED → every repeat is a no-op. You don't babysit it.

The flow you ship

A support agent issues a refund on a PAID order and it goes through. A flaky connection makes it retry the same call; each retry is individually legitimate, but only the first should ever pay out. You put the agent on refunds, because the boundary makes the rest no-ops.

Why your team ships it

After the refund the order advances to REFUNDED, and ISSUE_REFUND is allowed only from PAID — so every retry is declined (state_not_allowed) before it double-pays. The agent owns refunds; the money moves once.