How to Build a Refund & Returns Resolution Agent (2026 Tutorial)

This is a hands-on tutorial for building a Refund & Returns Resolution Agent — an agent that reads a refund or return request, checks it against policy, approves what clearly qualifies within caps, and routes everything else to a human. It maps directly to our Refund & Returns Resolution Agent blueprint, so you can read the build here and then grab the full runnable kit (system prompt, tool contracts, and a one-command starter) when you're ready. It's written for support and operations teams drowning in a high volume of refund tickets.

Returns are now a structural cost, not an edge case. The NRF and Happy Returns 2025 Retail Returns Landscape put U.S. returns at roughly $850 billion — about 15.8% of sales, and 19.3% of online sales — with around 9% of all returns judged fraudulent. The fraud is not exotic: overstated quantities, empty-box or "box of rocks" returns, and decoy or counterfeit items lead the list, and a majority of consumers admit to at least one return behavior that costs the retailer money. That mix — high volume, policy-bound decisions, and a real abuse rate — is exactly where an agent earns its keep, provided you build it with the right boundary.

Throughout, the single most important design rule is this: the agent's worst-case action is preparing an incorrect refund decision, and that decision is reviewed or executed by a human or a hard-capped tool — the agent itself never moves money. Everything else follows from that.

What you're building

The agent is a control loop, not a single prompt. It takes a request, verifies it, reasons about policy, calls tools to gather evidence, and produces a structured decision — approve within cap, deny with a reason, or escalate. The stack in the blueprint is Claude, LangGraph, OpenAI, but the design transfers to any framework, because what matters is the shape of the loop and the boundary around it, not the library.

Concretely, the finished agent accepts a refund/return request, confirms the order and that the requester actually owns it, checks eligibility against the live policy, recommends a decision and an amount, and routes anything over cap, out of window, disputed, or suspicious to a person — with every step logged for audit.

The tools the agent needs

An agent is only as capable as the tools you give it, and only as safe as the contracts on those tools. This blueprint uses 8 tools: get_request, verify_order, check_policy, check_eligibility, process_refund, detect_abuse, escalate, and log_decision. Notice the split — most are read tools that gather evidence (retrieve the request, confirm ownership, pull the policy, assess eligibility, screen for abuse), and the one tool that moves value, process_refund, is hard-capped at the contract level: it rejects any over-cap or out-of-policy amount outright. The agent cannot talk it into a larger refund.

That division is deliberate, and it is what makes the agent safe to run at volume. Give it broad read access to do the tedious checking; give it narrow, capped write access so the damage it can do is bounded by code, not by the model's good behavior. Define each contract tightly before you wire up any reasoning — loose tool definitions are where agents go off the rails.

Step by step

1. Start with the boundary. Before writing the system prompt, write down the worst-case action (an incorrect or over-policy refund) and decide what is gated. Here the answer is firm: the agent prepares decisions and may auto-approve only within the return window and at or under the refund cap; everything beyond either edge goes to a human. This one decision shapes the whole build.

2. Verify ownership before anything else. The first hard rule is that no refund action or order detail is exposed until the agent confirms the requester owns the order. Wire verify_order first and make a mismatch a full stop that escalates — this is both a fraud control and a data-leak control, and it has to sit before the agent reveals anything.

3. Ground the decision in the live policy. Pull the applicable policy and windows with check_policy, then run check_eligibility against the real return window, item condition, and required proof. An agent reasoning over a hard-coded or stale policy will confidently approve things it shouldn't, so treat policy as live input, never as something baked into the prompt.

4. Screen for abuse as a first-class step. Run detect_abuse to flag serial refunders, identity mismatches, and the "refund me or I'll chargeback" pressure pattern. With roughly one in eleven returns fraudulent, abuse detection isn't a nice-to-have bolted on at the end — it's a gate that can override an otherwise-eligible request and send it to a human.

5. Decide, explain, and cap. Within the window and under the cap, the agent recommends approval; over cap, outside the window, or non-standard, it escalates rather than improvising an exception. When it denies, it gives the policy reason and offers any policy-allowed alternative, such as store credit. Honest and consistent beats generous and arbitrary — and it keeps the agent defensible.

6. Instrument every decision. Use log_decision to record the inputs, the policy basis, and the outcome for every request, so you can evaluate whether the agent was right, not just whether it ran. Most production agents have logging but skip evaluation, and that gap is where quiet over-refunding hides.

The guardrails that make it production-ready

The difference between this agent and a flashy demo is entirely in the boundaries. It never moves money on its own — execution is a hard-capped tool, not a thing the model can decide to do at scale. It verifies ownership before it reveals or acts. It auto-approves only inside the policy window and under the cap, and escalates everything else. It treats abuse detection as a gate, not a footnote. And every decision is logged with its policy reason. The blueprint encodes all of this in an AgentAz™ governance section — an A3 (Human-Approved) Trust Level, an explicit worst-case action, and an authority boundary that keeps issuing-refund and order-modify tools out of the agent's registry entirely.

If you want the deeper reasoning behind these boundaries, see our guide to designing safe AI agents, and for how the pieces fit together architecturally, the agent engineering stack. If chargeback pressure is a big part of your volume, the Payment Dispute & Chargeback Agent and the E-commerce Order Support Agent pair naturally with this one.

Get the kit

This tutorial walks the design; the Refund & Returns Resolution Agent blueprint gives you the rest — the full system prompt, all 8 tool contracts, worked examples (including the hard cases where the agent correctly denies, caps, or escalates), Basic/Advanced/Enterprise tiers, and a runnable run.py starter that executes the real loop with one command and an API key, on Anthropic or OpenAI. Read it, adapt it to your policy and systems, and ship it behind the cap. For the broader production checklist, see building production-ready AI agents.