AI Agent for eCommerce Refund Investigation (2026)

Friday, an associate gets this refund request. Polite shopper. Order shows delivered. Carrier scan says delivered. The associate opens Admin, OMS, returns, shipping, and policy — five tabs — and guesses. Baymard 70.22% cart abandonment (50 studies, updated Sep 22, 2025) is checkout. These shoppers already paid. Do not put Baymard on a refund-ROI slide. After July 30, 2026, new agents should not start on the older Agents Classic product.

This post is this refund request — one customer, one order, one product context, shipping evidence, return history, versioned policy — then a recommendation: Approve / Reject / Partial refund / Replacement / Human Review. It is not order exception management (post 8). Post 8 is types of OMS exceptions (payment failure, shortage, address, delay, fulfillment, fraud hold). This matrix is the RMA in front of you.

This is series part 50. Shopper conversation and week-one reads stay with the support agent. The approval queue is HITL architecture. Risk bands that must never become accusations live in return fraud detection. Same store. Different write gates.

The job. Collect the evidence pack — customer, order, product, shipping, return history, policy — and recommend Approve, Reject, Partial, Replacement, or Human Review. Not auto-cash because the shopper was polite.

This week. Draft read OpenAPI for the evidence tools. Clone the decision matrix. No createRefund in week one. Prove DENY on delivered, over-cap, and shopper JWT.

A person still signs. Delivered refunds, over-cap payouts, and reject language stay associate-owned.

Skip it when OMS already closes this refund class deterministically and nobody reads free-text, or when you cannot name a human owner for over-cap and delivered-not-received.

Our take: policy lives in Cedar (and the OMS adapter), not in a paragraph that says “be fair.” Trade-off: some in-window refunds sit in HITL longer than a cowboy auto-refund bot. You also do not train stacked RMAs and delivered-not-received that always pays twice.

Copy the decision matrix — Open refund-investigation-decision-matrix.md. Fill your Auto vs HITL column and Cedar cap. Do not submit demo caps as policy. Series folder: ecommerce-ai-agents-series/. Ship gates: monday-checklist.md.

FactualMinds is an AWS Select Tier Services Partner. We help merchants sequence agents — we do not sell an auto-refund CSAT story.

It is not a client engagement. Caps below are worksheets, not finance policy. We do not publish a refund-rate, a deflection percentage, or a “days to close” from a named merchant.

This refund is not an exception type

Checkout worked. The shopper wants money or a replacement. The failure mode is not “we lack AI.” It is that an associate opens five UIs, guesses, and either over-refunds or copy-pastes a reject that does not match the policy version on the Knowledge Base.

Finance breaks if refunds fire without an evidence pack. Warehouse and carrier break if delivered-not-received auto-cashes out. Legal and brand break if reject language differs by who asked. Fraud ops break if the refund specialist also releaseFraudHold. Build the agent only when investigation spans more than one system and the next action is ambiguous. If OMS already maps “undelivered + in window + under $X” to a deterministic cancel, keep that rule — agent vs workflow.

How stores handle this today

Helpdesk macros. Shopify refund from Admin. A dollar cap in a prompt. “Always yes under $25.” Flow on a tag. Those are rules or habits. Keep the rules if they are encoded in OMS. Kill the habits that live only in Slack.

The agent is for messy packs: delivered flag vs last scan, prior RMAs on the same order, digital goods marked consumed, warranty vs 30-day window, a policy PDF that changed last Tuesday.

Evidence pack (must collect)

From the artifact:

If a required tool is missing, the only legal recommendation is Human Review. Do not “approve because the shopper was polite.”

Recommendations (never silent Execute on delivered)

Prompt caps are not authorization. Put the cap in Cedar. HITL timeout fails closed — never auto-approve because the queue is slow (HITL).

Never auto: delivered-not-received, over-cap, fraud-adjacent, stacked RMAs on one order, reject-without-associate-copy, replacement without QA evidence.

Fairness is a tool contract

Same evidence pack for every customer on the same policy version. Do not let “VIP” be a prompt adjective. If you have a tier, getCustomerFlags (or CRM equivalent) must return it. If the tool is empty, there is no tier.

Reject and partial language is confirmed by an associate. The model drafts; it does not lecture. Risk scores from post 51 may attach to the HITL ticket. They must not change the customer-facing sentence to “you are fraudulent.”

flowchart TD
  request[This refund request]
  pack[Evidence pack tools]
  policy[Versioned policy plus Cedar]
  rec[Recommend Approve Reject Partial Replacement Review]
  under[ALLOW under cap — optional Execute]
  over[HITL queue — fail closed]
  request --> pack
  pack --> policy
  policy --> rec
  rec --> under
  rec --> over

Request → evidence pack → policy in code → recommendation → under-cap or HITL. Detection of delivered and cap is deterministic. Using the model as the only cashier is how you pay twice.

Do not start with AWS

Procurement wants a stack slide. The honest order is matrix → evidence tools → host.

There is no native Shopify AgentCore connector. Shopify Admin refund is one possible OpenAPI target, not an AgentCore product line.

Run Policy LOG_ONLY, then ENFORCE. Approve must execute the workflow with an idempotency key — do not re-invoke the harness with write tools still attached (HITL).

# From refund-investigation-decision-matrix.md — fill caps for your store
Undelivered + in-window + under cap → Approve optional under Cedar
Outside window / consumed digital     → Reject; associate confirms copy
Partial line / restocking in code     → Partial; usually HITL
Defect + QA evidence                  → Replacement HITL
Delivered-not-received / stacked RMA  → Human Review required
Missing evidence tool                 → Human Review

Week-one evals: delivered fixture must not Execute; stacked listReturnsForOrder → Review; shopper JWT DENY createRefund; timeout does not Approve.

For your technical lead

On June 17, 2026, AgentCore Harness reached general availability (What’s New). A managed loop makes it easier to call createRefund. It does not make it acceptable to skip investigation, Policy, or a human on money. Agents Classic is in maintenance for new customers after July 30, 2026. Net-new refund agents should use Bedrock AgentCore. Full matrix: lifecycle roundup.

First-party signals we reuse (not store results) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Platform TCO silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Model your mix on the AgentCore pricing calculator. Treat ~$791/mo as a platform cost floor to plan against, not as refunds the agent will save.

What broke — Sample support harness with createRefund and a prompt cap of $50. Fixture order delivered, shopper said “never arrived.” The model refunded. Detection: Gateway ALLOW on createRefund with getShipment.status=delivered and no HITL ticket; Policy was prompt-only. Fix: Cedar DENY refund on delivered; matrix routes delivered-not-received to Human Review; carrier evidence required; timeout fails closed. Lesson: in-window plus a story is not an investigation. Prompt caps are not authorization.

A second counter-case: “VIP” in the system prompt. Two fixtures, same policy version, same evidence — one labeled VIP in prose — produced Approve vs Reject. Fix: strip the adjective; tier only from getCustomerFlags; fairness eval must pass both.

Do not merge this prompt with post 8. Exception management owns retryPayment and fraud-hold. If both specialists can refund in one supervisor turn, hop-cap it (store-agents).

Bedrock is the model. Harness or Runtime is the host. Gateway + Cedar on createRefund, createReturn, issueGiftCard. Strands does not replace Policy. Browser off. Support chat may invoke this specialist; shopper JWTs must still DENY writes (support control plane).

Absolute latency will be OMS and carrier, not Gateway. ~180 ms → ~95 ms is the CRM canary. Refund volume is usually far below shopper chat; still model platform + tokens so Browser stays off. If you cannot describe a workload that would notice ~$791/mo at 50K sessions, you are funding a demo.

Context: Python 3.12+ for store-agents stubs; Harness GA June 17, 2026 or Runtime; Gateway OpenAPI; Cedar on money.

How this relates to support, exceptions, HITL, and risk

• Support: week-one reads plus escalate. This post is the investigator those escalations join when you attach refund tools.
• Order exceptions: types on the OMS happy-path break. Share shipment tools; do not share payment-retry tools.
• HITL: the queue. Session id + tool trace on the ticket. Approve does not re-loop the model with writes.
• Return fraud: internal risk band. Never customer-facing accusation. Never Execute solely because the band is low — eligibility still follows this matrix.

What to do this week

1. List refund classes OMS already closes deterministically. Leave those in the workflow.
2. Clone refund-investigation-decision-matrix.md. Fill Cedar cap and Human Review rows with finance and CX in the room.
3. Draft read OpenAPI: customer, order, product, shipment, returns, refunds. No createRefund yet.
4. Harness (GA June 17, 2026) or Runtime; Gateway; Policy LOG_ONLY. Identity: associate only for writes.
5. Prove DENY: delivered refund, over-cap, shopper JWT, stacked RMA Execute.
6. Enable one optional Approve path (undelivered, in-window, under cap) only after goldens pass. Everything else HITL.
7. HITL UI: session id + trace. Timeout fails closed. Fairness eval: same pack, same policy version.
8. Model cost on the AgentCore pricing calculator. Need Policy on refunds? Contact us. Amazon Bedrock, Generative AI on AWS, AWS for retail / eCommerce.

Full ship list: monday-checklist.md.

If you only do one thing

Put Cedar on createRefund (status, cap, role) and require the evidence pack before any recommendation. Investigation is tools plus policy in code — not a helpful tone.

What this post doesn’t cover

• Exception classes (payment, shortage, address, delay, fulfillment, fraud hold) — post 8
• Measured refund-rate, chargeback-rate, or handle-time from a FactualMinds client
• Risk scoring bands — post 51
• Card data, PCI SAQ, PAN in Memory
• AgentCore Payments / x402
• Marketplace (FBA, WFS) refund APIs as first-class targets
• A native Shopify AgentCore refund app (it does not exist)
• Classic Agents cutover

FAQ

When should we NOT use an AI agent for refund investigation?

Skip it when a deterministic OMS rule already closes this refund class (in-window undelivered cancel under a named cap) and nobody is reading free-text. Also skip it when you cannot name a human owner for over-cap, delivered-not-received, and reject language. An agent without a matrix is a second, quieter cashier.

What could go wrong if we auto-approve every in-window refund?

Stacked RMAs, delivered-not-received without carrier evidence, consumed digital goods, and high-value orders cash out. In-window is not permission. The matrix still requires the evidence pack. Delivered, high value, fraud-adjacent, and stacked returns are Human Review. Timeout fails closed — never auto-approve on SLA.

When should we NOT let the agent Execute createRefund?

Week one: never. Later: never on delivered, never over the Cedar cap, never when return history or shipping evidence is missing, never on shopper JWT. Prompt caps are not authorization. Partial refunds and replacements stay HITL unless policy is in code and evals prove the path.

What could go wrong if VIP is a prompt adjective instead of a CRM tool?

The model invents a tier, approves outside policy, and you fail a fairness review. Same evidence pack for every customer on the same policy version. VIP must be a getCustomerFlags (or equivalent) tool result. Reject language is confirmed by an associate — the model does not lecture the shopper.

How is this different from order exception management?

Post 8 classifies exception types (payment, shortage, address, delay, fulfillment, fraud hold) on the ops side of the OMS. This post is this refund request: one RMA, one evidence pack, one recommendation. Share getOrder and getShipment. Do not share retryPayment or releaseFraudHold with the refund specialist. order exceptions.

Is there a native Shopify AgentCore connector for refunds?

No. Refund, order, shipment, and return APIs are your OpenAPI or MCP targets on Gateway. AgentCore does not ship a Shopify refund app. Keep payment capture and PAN out of tools. Net-new builds should not use Agents Classic after July 30, 2026.

Need a refund investigator that recommends instead of cashing out? Contact FactualMinds or start from the support agent.