Returns and order agent

A return comes in through two channels and a timeout. Each refund is valid on its own; the order is refunded twice.

01The workflow

An AI agent handles returns, exchanges and order changes across the storefront, payments and the warehouse.

02The rule that must hold

sum(refunds[order])  ≤  amount_paid[order]   ∧   reserved[sku]  ≤  on_hand[sku]

An order is never refunded beyond what was paid, and stock is never promised beyond what is on hand.

03How it breaks

A customer starts a return in chat and, impatient, also submits it in the returns portal.
The chat agent issues the refund. The payment provider’s acknowledgement is lost, so the agent retries.
The portal flow reads the order view, sees no refund yet, and issues its own.
The retry is absorbed by its key, but the portal refund is a different, valid operation, so the order is refunded twice.
Each refund passed every check. The overage appears only when someone totals the order.

04Why monitoring misses it

Task successEvery agent completed; nothing errored or retried.Healthy
Distributed tracingOne clean trace per action; every span OK.Healthy
ReconciliationNo lag, no drift, no duplicate keys.Healthy
The ruleAn order is never refunded beyond what was paid, and stock is never promised beyond what is on hand.Broken

05Reproduced in the lab

Each failure mode below is reproduced deterministically in the public Agent Control Lab and can be run by its id.

06What we would engineer

One operation identity per return, so the portal, the chat agent and a retry can never refund it twice.
Recovery & Idempotency →
Stock and refund totals held by one authority per order, not re-derived from views each channel reads.
State & Side Effects →
Order-level invariants checked against what was paid and what was shipped, not the API response.
Business Outcomes →

07Outside the lab

ACIDRain (SIGMOD 2017) ↗

Supports12 eCommerce platforms deployed on over 2M websites; 22 verified attacks that over-spend gift cards and corrupt inventory, 17 of them even under the strongest transactional guarantees those databases offer.

Does not supportThose applications share one database, so a correctly scoped transaction exists in principle. Same class of harm, reached by an easier road.

08What the diagnostic delivers

The rules this workflow must keep, written down and classified.
For each rule, the system that can enforce it, or the gap where none can.
Priority failure modes reproduced where feasible.
An ordered hardening plan.

Discuss this workflow See a sample assessment (PDF)

Boundary Illustrative engagement, not a client engagement or a measured production result. The failure modes listed are reproduced in the public lab.