--- title: The AI Exception Agent: Automatically Investigating eCommerce Business Problems (2026) description: Reusable detect to approve-or-execute for order, inventory, customer, and payment exceptions. Reuse Gateway ~180 to 95 ms and ~$791/mo at 50K sessions. Not a client refund KPI. url: https://www.factualminds.com/blog/ai-exception-agent-ecommerce-2026/ datePublished: 2026-08-27T00:00:00.000Z dateModified: 2026-08-27T00:00:00.000Z author: palaniappan-p category: AI Agents tags: ai-agents, ecommerce, bedrock-agentcore, generative-ai, amazon-bedrock, operations --- # The AI Exception Agent: Automatically Investigating eCommerce Business Problems (2026) > Reusable detect to approve-or-execute for order, inventory, customer, and payment exceptions. Reuse Gateway ~180 to 95 ms and ~$791/mo at 50K sessions. Not a client refund KPI. This post is the **reusable** exception-agent pattern: **detect → investigate → collect evidence → recommend → request approval or execute**. Inputs are **order, inventory, customer, and payment** exceptions. It is **not** a remake of [AI order exception management](/blog/ai-order-exception-management-ecommerce-2026/) — that is the **order specialization** (payment fail, address, delay, fulfillment, fraud) with Auto vs HITL columns you still have to fill. Order IDs and decline codes in artifacts are demo shapes. They are not a FactualMinds refund KPI. **On June 17, 2026**, AgentCore **Harness** reached general availability ([What's New](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-harness-generally-available/)). A managed loop makes it cheap to **call** `getOrder` and `getInventory` in one turn. It does not make it acceptable to staff a new chatbot for every OMS exception code. > **AWS lifecycle notice (June 30, 2026)** — Amazon Bedrock Agents Classic is in maintenance for new customers after **July 30, 2026**. Net-new exception agents should use [Bedrock AgentCore](/blog/amazon-bedrock-agentcore-production/). Full matrix: [lifecycle roundup](/blog/aws-service-lifecycle-updates-june-2026/). > **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](/blog/amazon-bedrock-agentcore-gateway-server-side-tool-execution-2026/). Platform TCO silhouette: support-style AgentCore at **50K sessions/mo ~$791/mo** platform + model ([decision guide](/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)). Exception volume is usually far below shopper chat; still model platform + tokens on the [AgentCore pricing calculator](/tools/amazon-bedrock-agentcore-pricing-calculator/). Treat **~$791/mo** as a **platform cost floor**, not as savings from fewer holds. > **Reproduce this** — Clone [`exception-agent-pattern.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/exception-agent-pattern.md). Fill **your** Detect sources and default autonomy. For orders, also fill [`order-exception-playbook.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/order-exception-playbook.md). Series folder: [`ecommerce-ai-agents-series/`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/README.md). **Opinionated take:** one harness (or one Runtime service) with **tools per class**, not forty disconnected zaps. Trade-off: a new exception type waits until you add a tool and a Cedar rule. You also do not train two specialists to refund the same order in one afternoon. Signals that start the loop live in [store monitoring](/blog/ai-ecommerce-monitoring-agent-2026/). Writes that must stop live in [HITL](/blog/human-in-the-loop-ai-agents-ecommerce-2026/). The mixed ops queues are the [back-office matrix](/blog/ecommerce-back-office-automation-ai-agents-2026/). FactualMinds is an AWS Select Tier Consulting Partner. We help merchants sequence this loop — we do not sell auto-refund as kindness. ## The loop (reuse it; do not rename it per ticket type) ```text Detect → Investigate → Collect evidence → Recommend → Request approval or execute ``` Context: Python 3.12+, AgentCore Harness GA **June 17, 2026** or Runtime, Gateway OpenAPI, Cedar on writes, Browser **off**. Detection is **not** the model watching Slack. ```mermaid flowchart TD Detect[Detect] Investigate[Investigate] Evidence[CollectEvidence] Recommend[Recommend] Gate[ApproveOrExecute] Detect --> Investigate Investigate --> Evidence Evidence --> Recommend Recommend --> Gate ``` | Step | Who owns it | Failure if you skip | | ---- | ----------- | ------------------- | | **Detect** | Deterministic rule or webhook | Missed holds; invented holds | | **Investigate** | Named tools only | Five UI hops and a guess | | **Evidence** | `evidence_tool` + `evidence_ref` on every finding | A story that no system measured | | **Recommend** | Structured decision, autonomy tagged | Slack prose that cannot be approved | | **Approve or execute** | Cedar + HITL per [autonomy spectrum](/blog/ecommerce-ai-agent-autonomy-spectrum-2026/) | Prompt text as authorization | Why this matters / who breaks without it: finance breaks if refunds fire without a playbook; warehouse breaks if every shortage becomes a silent cancel; CRM breaks if duplicate-customer "cleanup" writes accounts. Build the agent when investigation spans **more than one system** and the next action is **ambiguous**. If a decline code already maps to "retry once," keep that in the payments processor. ## Four input classes (defaults, not a client mix) From [`exception-agent-pattern.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/exception-agent-pattern.md): | Exception class | Examples | Default autonomy | | --------------- | -------- | ---------------- | | **Order** | Payment fail, address, delay | Investigate + recommend. Fill [post 8](/blog/ai-order-exception-management-ecommerce-2026/) for Auto vs HITL | | **Inventory** | ATP vs advertised, receipt miss | Analyze + recommend. No qty write in week one | | **Customer** | Duplicate create, B2B credit hold | Recommend. **No** account write | | **Payment** | Decline codes, AVS | Retry **only** on an allow-list. AVS / fraud-tool hold → human | Do not flatten order into "payment" and delete the playbook. Post 8 still owns fulfillment short-pick, fraud-release, and split-ship that spends margin. This table is the **shared** loop those rows sit on. ### Order (specialization, not a copy) Shopper-facing [WISMO](/blog/wismo-automation-ai-agents-ecommerce-2026/) answers where the order is. Support triages returns. Exception management sits on the **ops** side of the OMS: the order already failed a happy-path rule. Same Gateway family, different Identity, different write tools. Link the playbook. Do not paste its six-class table into this post and call it new. ### Inventory Available vs reserved is a number. The judgment is wait, split, substitute, or cancel. The agent **recommends** with `getInventory` and `asOf`. Cancel and ATP mutation stay HITL. Advertised ATP=0 is often a [monitor](/blog/ai-ecommerce-monitoring-agent-2026/) detect, then this investigate step. ### Customer Duplicate create spikes and B2B credit holds are quality and AM problems. The agent may cluster and recommend a merge or a hold review. It must not `updateCustomer` or touch PII beyond what the tool already strips. Prompt "do not show PII" is not a control. ### Payment Most declines are already classified by the processor. The agent adds value when OMS status does not match what finance thinks posted. **Auto:** retry only on an allow-list. **HITL:** AVS mismatch, 3DS failure, fraud-tool hold. Unconstrained retries look like card testing. ## Evidence is the product Every finding needs both fields. If a hop has no tool, stop and list the gap. ```json { "exception_id": "EXC-DEMO-001", "class": "inventory", "detect": { "source": "webhook:oms.exception", "code": "SHORTAGE" }, "findings": [ { "claim": "ATP 0 on advertised SKU DEMO-1 asOf fixture timestamp", "evidence_tool": "getInventory", "evidence_ref": "sku:DEMO-1", "causation": "possible_contributor" } ], "unknowns": ["Substitute availability — no getSubstitutes tool"], "recommended_action": { "action": "Hold and recommend split", "autonomy": "recommend" }, "human_required": true } ``` Fixture IDs and SKUs are **demo**. Do not cite them as a store outcome. The same evidence contract shows up in [alerts](/blog/ai-business-alerts-ecommerce-2026/) and RCA. Share the schema; do not share refund tools with the shopper-facing agent. ## One host, tools per class | Piece | Role here | | ----- | --------- | | **Gateway** | Per-class reads; narrow writes only after Cedar | | **Policy (Cedar)** | Default-deny `refundOrder`, `cancelOrder`, `updateInventory`, `updateCustomer`; allow `retryPayment` only with decline-class entity | | **Identity** | Associate vs shopper. Shopper JWTs DENY every exception write | | **Memory** | Exception-id scoped; no PAN, no raw 3DS | | **HITL** | Queue with session id and tool trace — [HITL architecture](/blog/human-in-the-loop-ai-agents-ecommerce-2026/) | Run Policy **`LOG_ONLY`**, then **`ENFORCE`**. The [store-agents Cedar sample](/blog/ecommerce-ai-agents-amazon-bedrock-agentcore-2026/) already gates `cancelOrder` and `createReturn`. Reuse it. There is **no native Shopify AgentCore connector**. Gateway **~180 → ~95 ms** is the CRM **platform** canary. Absolute latency is OMS + payments + WMS. Session economics: if exception volume would not notice a ~$791/mo floor at 50K sessions, you are still allowed to start — just do not staff Browser-on-every-hold as the path to "saving" that floor. ## One fixture walkthrough (replace the IDs) Not a client case. `EXC-DEMO-001`, SKU `DEMO-1`. 1. **Detect** — OMS webhook `SHORTAGE` on order `ORD-DEMO-9`. No model in this step. 2. **Investigate** — `getOrder`, `getInventory` (require `asOf`), `getShipment` if the playbook says the class needs it. Stop if a tool 404s; do not guess ATP. 3. **Evidence** — ATP 0 on advertised `DEMO-1` with `evidence_tool: getInventory`. Substitute availability is an **unknown** if `getSubstitutes` is not on the OpenAPI. 4. **Recommend** — hold and split; autonomy `recommend`. Cancel/refund stay HITL per post 8. 5. **Approve or execute** — Cedar DENY `refundOrder` for this role; HITL queue gets session id + tool trace. That is the whole pattern. Payment-fail and duplicate-customer reuse steps 1–5 with different tools. They do not reuse refund tools with the shopper-facing support agent. | Anti-pattern | Replacement | When the replacement applies | | ------------ | ----------- | ---------------------------- | | Zap per OMS code | One investigator, tools per class | You have more than a handful of codes and shared writes | | Model as detector | Webhook / queue / join | OMS or WMS already emits a code | | Shared Admin token | Identity JWT + Cedar | Any write exists | | Prompt "be careful" | HITL queue | Refund, cancel, account, ATP mutation | ## What broke > **What broke** — A program plan that staffed one zap per OMS exception code (forty prompts, shared Admin token). Two specialists both called `refundOrder` on the same fixture hold: support for "be kind," exceptions for shortage. **Detection:** Gateway traces showed two write tools, two idempotency keys, one order. **Fix:** one investigator; tools per class; Cedar default-deny refund; HITL for refund/cancel; order rows stay in the [order playbook](/blog/ai-order-exception-management-ecommerce-2026/). **Lesson:** reuse the loop. Do not multiply chatbots. A second counter-case: detect left in the model ("look for weird orders"). The OMS already emitted `payment_failed`. The agent retried through a fraud-tool hold — the same class of bug post 8 already documented. **Fix:** webhook first; allow-list retries in Cedar and in the payments adapter, not only in the prompt. ## What to Do This Week 1. Copy [`exception-agent-pattern.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/exception-agent-pattern.md). Map **your** four classes to tools. 2. For orders, fill [`order-exception-playbook.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/order-exception-playbook.md) — do not skip it. 3. Put Detect in webhooks / queue depth / joins. Do not ask the model to notice. 4. Require `evidence_tool` + `evidence_ref`. Refuse recommendations that skip them. 5. Default autonomy: investigate + recommend. Retry only on a payments-owned allow-list. 6. One harness (or one Runtime service). Kill the zap-per-code plan. 7. HITL queue for refund, cancel, account, ATP write — [`hitl-approval-architecture.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/hitl-approval-architecture.md). 8. Run [`monday-checklist.md`](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-ai-agents-series/monday-checklist.md). 9. Model sessions on the [AgentCore pricing calculator](/tools/amazon-bedrock-agentcore-pricing-calculator/). 10. [Contact us](/contact-us/) for an architecture conversation. Bedrock path: [Amazon Bedrock](/services/aws-bedrock/). If you only do one thing: **stop staffing a chatbot per exception code**. Share the loop; specialize the tools. ## What This Post Doesn't Cover - The six-class order Auto vs HITL table — [order exception management](/blog/ai-order-exception-management-ecommerce-2026/) - Always-on signal catalog — [monitoring agent](/blog/ai-ecommerce-monitoring-agent-2026/) - Ten back-office task rows — [back-office automation](/blog/ecommerce-back-office-automation-ai-agents-2026/) - Approval queue mechanics — [HITL](/blog/human-in-the-loop-ai-agents-ecommerce-2026/) - A guaranteed ticket-deflection or refund-rate outcome from a named client - PCI-scoped capture automation - A native Shopify AgentCore connector ## FAQ ### When should you NOT staff a new chatbot per exception type? Skip a new prompt per OMS code when the loop is the same: detect, investigate, evidence, recommend, approve or execute. Tools and Cedar change by class. Forty disconnected zaps is how you get two refunds on one order. One harness (or one Runtime service) with tools per class. ### What could go wrong if this post replaces the order-exception playbook? You lose the six order classes, Auto vs HITL columns, and the fraud-hold veto. This is the reusable pattern. Post 8 is the order specialization. Fill that playbook for payment fail, address, delay, fulfillment, and fraud. Do not flatten it into four generic buckets and call the work done. ### When should you NOT auto-execute after investigate? Veto payment capture, ATP mutation, live price, account or PII writes, fraud-release, and refunds that are not on a named allow-list. Default autonomy is investigate plus recommend. Retry payment only on a decline-code allow-list your payments team owns. ### What could go wrong if evidence_tool is optional? The model will fill the gap with a story. Sample turns recommended cancel on a shortage without calling getInventory. Detection is evals that fail when evidence_tool or evidence_ref is missing. Fix: refuse the recommendation; return the unknown. ### How is this different from the monitoring agent or back-office pillar? Monitoring decides that a signal fired and should be investigated. Back office is a task matrix of ten queues. This pattern is the investigation loop those queues share. Do not merge week-one prompts: a monitor that refunds is a purchaser you did not review. ### Harness or Runtime for a cross-domain exception agent? Harness can host one investigator with a short tool list per class. Use Runtime plus Strands when hop caps, a supervisor, or Cedar-scoped writes across payments, OMS, WMS, and CRM matter. Net-new builds should not use Agents Classic after July 30, 2026. --- Need a single exception loop without a zap farm? [Contact FactualMinds](/contact-us/) for an architecture conversation, or start from the [order playbook](/blog/ai-order-exception-management-ecommerce-2026/). ## FAQ ### When should you NOT staff a new chatbot per exception type? Skip a new prompt per OMS code when the loop is the same: detect, investigate, evidence, recommend, approve or execute. Tools and Cedar change by class. Forty disconnected zaps is how you get two refunds on one order. One harness (or one Runtime service) with tools per class. ### What could go wrong if this post replaces the order-exception playbook? You lose the six order classes, Auto vs HITL columns, and the fraud-hold veto. This is the reusable pattern. Post 8 is the order specialization. Fill that playbook for payment fail, address, delay, fulfillment, and fraud. Do not flatten it into four generic buckets and call the work done. ### When should you NOT auto-execute after investigate? Veto payment capture, ATP mutation, live price, account or PII writes, fraud-release, and refunds that are not on a named allow-list. Default autonomy is investigate plus recommend. Retry payment only on a decline-code allow-list your payments team owns. ### What could go wrong if evidence_tool is optional? The model will fill the gap with a story. Sample turns recommended cancel on a shortage without calling getInventory. Detection is evals that fail when evidence_tool or evidence_ref is missing. Fix: refuse the recommendation; return the unknown. ### How is this different from the monitoring agent or back-office pillar? Monitoring decides that a signal fired and should be investigated. Back office is a task matrix of ten queues. This pattern is the investigation loop those queues share. Do not merge week-one prompts: a monitor that refunds is a purchaser you did not review. ### Harness or Runtime for a cross-domain exception agent? Harness can host one investigator with a short tool list per class. Use Runtime plus Strands when hop caps, a supervisor, or Cedar-scoped writes across payments, OMS, WMS, and CRM matter. Net-new builds should not use Agents Classic after July 30, 2026. --- *Source: https://www.factualminds.com/blog/ai-exception-agent-ecommerce-2026/*