Human-in-the-Loop AI Agents for eCommerce: Where Automation Should Stop (2026)

This post is where automation should stop. It is the approval architecture for the autonomy spectrum — Request Approval and everything that must never reach Execute. It is not a rewrite of support control plane (week-one reads) and not agent vs workflow (who owns the path). You already have an agent. You need a queue.

On June 17, 2026, AgentCore Harness reached general availability (What’s New). A managed loop makes it easier to call createReturn. It does not make it acceptable to skip a human on the cases that wreck margin, identity, or trust.

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

It is not a client engagement. SLAs below are worksheets.

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.

Reproduce this — Copy hitl-approval-architecture.md. Paste the JSON payload into the RFC. Series folder: ecommerce-ai-agents-series/.

Opinionated take: HITL is Gateway Policy plus a queue. Trade-off: associates still click Approve on expensive refunds and POs. The alternative is a prompt that says “be careful” and a finance ticket on Monday.

Where the agent must stop

Support week-one already forbids createRefund until Policy is reviewed. This post is the queue those writes join when you do attach them.

Fraud-adjacent chat is not a slow HITL. It is stop writes now, then a risk queue. Do not “look up the order first” on attorney or regulator language — extra tools in the trace, same human at the end. That rule is in the support post; the architecture here is how the ticket is built.

Approval architecture (two gates)

flowchart TD
  proposal[Agent proposes named write]
  cedar[Gateway Cedar Policy]
  deny[DENY: stop and alarm]
  under[ALLOW under auto cap]
  over[ALLOW over HITL threshold]
  wf[Workflow executes with idempotency key]
  queue[HITL queue]
  human[Associate / buyer / risk]
  proposal --> cedar
  cedar --> deny
  cedar --> under
  cedar --> over
  under --> wf
  over --> queue
  queue --> human
  human -->|approve| wf
  human -->|reject| memory[Memory note + safe customer text]

Gate 1 — Cedar on Gateway. Role, order status, amount cap. LOG_ONLY then ENFORCE. Prompt is not authorization. Identity JWT (shopper vs associate vs admin) must flow into Policy even if specialists share an entrypoint.

Gate 2 — HITL queue. Helpdesk, Slack, or a Next.js + TypeScript + Tailwind ops dashboard. Required fields:

1. runtimeSessionId (Harness data plane: ≥33 characters)
2. Tool trace (which operations, which ids)
3. Proposed action + Cedar decision + HITL reason
4. Idempotency key the workflow will use

DENY does not create a ticket for every model hallucination. Alarm on DENY spikes. Queue only ALLOW-over-threshold and explicit escalate intents (fraud, PII, legal).

Harness hosts the loop (CreateHarness / InvokeHarness) on Runtime microVMs. Tools via Gateway or MCP. Memory is the shopper/associate notebook — not the approval ledger. Observability and CloudTrail on bedrock-agentcore.amazonaws.com are how you replay a bad Approve. Bedrock Converse + Guardrails complement Cedar; they do not replace it. Strands 1.0 after export still has no Policy or Identity — keep Gateway.

Browser and Code Interpreter off by default. A Browser session is not an approval UX.

Ticket contract

Context: illustrative JSON, not an OMS schema. Python 3.12+ if a Lambda posts this to helpdesk.

{
  "approvalId": "hitl-2026-08-27-001",
  "runtimeSessionId": "11111111-1111-1111-1111-111111111111",
  "proposedAction": "createReturn",
  "orderId": "ORD-1001",
  "refundUsd": 140,
  "identity": { "role": "associate" },
  "cedarDecision": "ALLOW",
  "hitlReason": "refundUsd > storeCap75",
  "toolTrace": ["getOrder", "getShipment", "getReturnPolicy"],
  "idempotencyKey": "createReturn:ORD-1001:ret-88"
}

Approve calls OMS createReturn (or your return API) once. It does not InvokeHarness again with write tools attached. Reject stores a Memory note and a customer-safe sentence (“a specialist will follow up”) — not a invented policy.

The ~$75 cap in public Cedar sketches is a demo ceiling. Your finance number goes in Policy, not in the model card.

Queue design (fail closed)

Auto-approve on SLA breach is Fully Automated with extra latency. Do not ship it. If leadership wants faster refunds, lower the Cedar cap and staff the queue — do not delete the queue.

Gateway ~180 → ~95 ms is tool RTT after server-side execution. Associates waiting on HITL are waiting on humans. Do not quote the CRM canary as an approval SLA. Platform TCO at 50K sessions ~$791/mo is what you model while the queue exists; HITL does not make sessions free.

What broke

What broke — An RFC that treated HITL as instructions: “If the refund is large, ask a human.” No queue, no payload, no owner. The model called createReturn at $140 on a delivered fixture because the shopper typed “you already said yes in chat.” Detection: Gateway trace with a write and zero helpdesk tickets that hour; Policy was LOG_ONLY and nobody watched ALLOW. Fix: strip the write; enqueue Request Approval with session id + trace; Approve hits the workflow; timeout fail-closed. Lesson: unsure-prompts do not create tickets.

The delivered-not-received auto-refund failure in the support post is the same family: CSAT as authorization. HITL is the operational fix, not a nicer prompt.

What to Do This Week

1. Name the six stop-classes: high-value refund, price/discount, large PO, fraud/dispute, account change, irreversible inventory/catalog.
2. Copy hitl-approval-architecture.md into the RFC.
3. Pick one queue (helpdesk is enough). Attach session id + tool trace.
4. Prove Cedar LOG_ONLY on the first write; flip ENFORCE only after a canary.
5. Implement Approve → workflow, not Approve → second harness turn.
6. Write three goldens: over-cap enqueue, DENY no ticket spam, fraud stop-writes.
7. Price sessions on the AgentCore pricing calculator. Run monday-checklist.md.
8. If the first HITL is refunds, contact us before chat goes public.

What This Post Doesn’t Cover

• Per-action Observe→Execute matrix — autonomy spectrum
• Secrets, PII minimization, payment out of tools — secure store agents
• Week-one support allow-list — support agent
• Helpdesk vendor bake-off (Gorgias vs Zendesk vs Salesforce)
• Guaranteed handle-time or CSAT from HITL — we did not measure a client here
• PCI mapping of the approval UI — a dashboard is not a BAA

FAQ

When should you NOT skip human-in-the-loop for an eCommerce agent write?

Do not skip HITL for high-value refunds, live price changes, large purchase orders, fraud or dispute language, account or PII changes, or any irreversible catalog/inventory mutation. Cedar ALLOW under a small cap is not a reason to delete the over-cap queue. Timeout must fail closed — never auto-approve.

What could go wrong if HITL is only a system prompt that says ask a human if unsure?

The model will not be unsure. It will call createReturn because the shopper asked nicely. There is no ticket, no session id, no tool trace, and no associate who can see why the bot stopped — or did not stop. HITL is a queue. Prompt humility is not a control.

When should you NOT build a Next.js approval dashboard first?

Skip a custom dashboard when helpdesk or Slack already is the queue and you can attach session id plus tool trace to the ticket. Next.js + TypeScript + Tailwind is a typical FactualMinds ops surface. It is not the AgentCore runtime and it is not required for every merchant.

What could go wrong if approve re-invokes the harness with write tools still attached?

The second turn can call a different tool, a different amount, or a second order. Approve must execute the workflow (OMS, ERP, promo engine) with the idempotency key on the ticket. The model does not get another unbounded loop to “finish up.”

Is Gateway Cedar a substitute for HITL?

No. Cedar is the first gate (role, status, cap). HITL is the second gate for over-cap and irreversible actions. Policy DENY should not spam the queue. ALLOW-under-cap may execute. ALLOW-over-threshold must enqueue. Prompt text is not authorization. LOG_ONLY then ENFORCE.

What could go wrong if delivered-not-received auto-refunds while HITL is “coming later”?

You train friendly fraud and skip the investigation warehouse and carrier need. That failure is already the week-one support rule — read-only plus escalate. HITL is where reship or refund is decided after evidence, not a backlog item behind CSAT.

Need a HITL payload and Cedar on refunds before the bot can write? Contact FactualMinds or see AWS for retail / eCommerce.