## TL;DR
Wrong-template refunds happen because the macro picker shows ten similar options and the agent picks fast under queue pressure. The fix isn't telling agents to be careful; it's making the wrong choice hard: fewer templates, preconditions on each, and a confirmation step for money. Guardrails beat vigilance every time.

## The query

```text
agent's macro applied the wrong refund template: guardrails
```

## Use this when

- Agents apply the wrong refund macro
- Refunds go out with wrong amounts or reasons
- You're designing macro libraries for agent teams


## Not for

- Chatbot macro selection issues
- Refund policy design
- Payment processor errors


## Steps

### 1. Shrink the refund template list

Count the refund macros. If there are more than five, consolidate: one per refund reason, not one per historical accident. Every extra template is another wrong choice waiting to happen.

Expected output: five or fewer refund templates, each with a distinct reason.

### 2. Add preconditions to each template

Each macro should declare when it applies: order age, amount limits, reason codes. If the ticket doesn't meet the preconditions, the macro shouldn't be offered. The picker filters; the agent doesn't have to remember.

Expected output: preconditions on every refund macro, enforced by the picker.

### 3. Require confirmation for money

Applying a refund macro should show a confirmation with the amount, the reason, and the customer, and require an explicit confirm. One extra click catches most misfires.

Expected output: a confirmation step showing amount and reason before any refund sends.

### 4. Log macro applications with context

Record which macro was applied to which ticket by whom. When a wrong refund happens, the log shows whether it was a picker problem, a precondition gap, or an agent override, and you fix the right thing.

Expected output: a macro application log reviewed after every wrong refund.

## Variant phrasings

### support agent wrong refund macro

Steps 1 and 2: fewer templates with preconditions.

### refund template guardrails support

Step 3's confirmation is the backstop that catches the rest.

## Why it happens

Under queue pressure, agents satisfice: they grab the first macro that looks right. A long list of near-identical refund templates is a trap designed by nobody and sprung by everyone. The error rate is a function of list length and similarity, not agent carelessness, so the fix is in the list, not the lecture.

## Edge cases

- Partial refunds need their own template with amount validation. Don't reuse full-refund macros.
- Currency and tax rules differ by region. Preconditions should encode the regional limits.
- Agent overrides of guardrails should require a reason code. Unexplained overrides are a training signal.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vpfdwtrmI7AxI-8SNMQmTA