AI Agent for eCommerce Refund Investigation (2026)

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new refund agents should use Bedrock AgentCore. Full matrix: lifecycle roundup.

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.

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.

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.

First-party signals we reuse (not eCommerce outcomes) — 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.

Reproduce this — Copy 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.

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.

Opinionated 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.

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

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.

Why this matters / who breaks without it: 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.

Baymard 70.22% cart abandonment (50 studies, updated 22 Sep 2025) is checkout. These shoppers already paid. Do not put Baymard on a refund-ROI slide.

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.

Production shape

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.

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).

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

# 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.

What broke

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).

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 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

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 17 June 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.

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

FAQ

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

Skip it when OMS already closes this class deterministically 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.

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

Stacked RMAs, delivered-not-received, consumed digital, high-value orders. In-window is not permission. Delivered, high value, fraud-adjacent, and stacked returns are Human Review. Timeout fails closed.

When should we NOT let the agent Execute createRefund?

Week one: never. Later: never on delivered, never over the Cedar cap, never with missing evidence, never on shopper JWT. Prompt caps are not authorization.

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

The model invents a tier and you fail fairness. Same evidence pack, same policy version. VIP only from a named tool.

How is this different from order exception management?

Post 8 is exception types on the OMS. This post is this refund. Share reads; do not share retryPayment. See order exceptions.

Is there a native Shopify AgentCore connector for refunds?

No. Wire Gateway to Shopify Admin, OMS, carrier, and RMA yourself. Keep payment capture out of tools. Skip Agents Classic after 30 July 2026.