AI Agents for eCommerce Data Quality Monitoring (2026)

This is series part 47. Core idea: agents should monitor business data, not only answer questions. Deterministic validation detects. AI may investigate. This is not a remake of catalog extract/publish (part 9). Demo finding_ids in the artifact are fixtures. We do not invent a client defect-rate KPI.

On June 17, 2026, AgentCore Harness reached general availability (What’s New). A scheduled InvokeHarness can host an investigation loop. It must not replace the scanner.

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.

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). Nightly scans should not be 50K chat sessions; model remaining interactive investigations on the AgentCore pricing calculator. Treat ~$791/mo as a platform cost floor to plan against, not as savings. Gateway ~180 → ~95 ms is the CRM canary, not PIM p95.

Reproduce this — Copy data-quality-monitor-rules.md. Replace thresholds with yours. Catalog publish gates remain in catalog-validation-rules.md. Folder: ecommerce-ai-agents-series/.

Opinionated take: ship the rule table in code before you attach an investigator. Trade-off: fewer “smart” auto-fixes in week one. You stop publishing fiction and adjusting ATP because a prompt was confident.

FactualMinds is an AWS Select Tier Consulting Partner. We help merchants split detect vs investigate — we do not sell a model as a validator.

The data agent answers a human question with joins. This post watches the same entities when nobody asked. If you only staff Q&A, drift lands in WISMO and RCA first — usually as a confident sentence with no finding_id.

Detect in code, investigate optionally

Monitors watch streams that already exist: PIM live SKUs, customer identity, price service, inventory ATP, sync watermarks. The data layer must expose asOf and join keys or the scanner pages ghosts.

flowchart LR
  streams[Business data streams]
  rules[Deterministic rules]
  findings[Finding queue]
  investigate[Optional AI investigation]
  human[Human action]
  streams --> rules
  rules --> findings
  findings --> investigate
  findings --> human
  investigate --> human

Why this matters / who breaks without it: Post 9 already fails a draft SKU before publish. Live drift still happens: a price service updates, the storefront cache does not; a receipt posts late and ATP jumps; two guest checkouts create two customer_ids. Answering “is the catalog OK?” in chat is not monitoring. RCA explains a revenue week; this post flags the record that would poison that week.

Monitor catalog (examples — replace thresholds)

From data-quality-monitor-rules.md:

N% and SLA hours are your numbers. The blog will not pick them. Demo ids are fixtures — do not treat counts in a post as your backlog.

Output contract (one finding):

{
  "finding_id": "DQ-DEMO-001",
  "domain": "products",
  "rule_id": "required_attrs_empty",
  "severity": "high",
  "evidence_tool": "scanCatalogCompleteness",
  "evidence_ref": "sku:DEMO-SKU",
  "recommended_action": "draft_enrichment",
  "human_required": true
}

Context: worker language of your choice; rules in git; AgentCore only on the investigation path. Assumed split:

# data-quality-monitor-rules.md
DETECT in code — required attrs, price equality, asOf SLA, duplicate email+id
INVESTIGATE optional — reads only
DENY publishProduct, mergeCustomers, setPrice, updateQuantity on the monitor harness
human_required true on suspicious_change and merge candidates

Exception-shaped work (holds, splits, warehouse misses) is a different playbook — order exceptions and, when it ships, the exception-agent pattern in this cluster. A DQ finding may open that queue. It does not cancel an order.

Finding lifecycle (so Slack does not become the system of record)

1. Open — worker emits finding_id, rule_id, severity, evidence_tool, evidence_ref.
2. Dedup — same rule_id + evidence_ref within the SLA window is one finding, not twelve pages.
3. Investigate (optional) — Harness with read tools: fetch receipt, compare price service asOf, list sibling SKUs for a draft only. No publish.
4. Route — high severity pages ops; medium becomes a ticket; low is a daily digest cap (example: 5), same discipline as the ops brief.
5. Close — human or the owning system (PIM publish, identity merge). The monitor harness does not close by writing commerce state.

Severity without blast radius is noise. A missing care attr on a live apparel SKU is high for shopping agents. A duplicate guest customer_id with no orders is medium until it hits checkout. Sync lag past SLA is high because every other agent will lie with in_stock.

Cadence is your ops choice: nightly catalog completeness, near-real-time price equality if you already have a stream, hourly asOf watermarks. Do not InvokeHarness once per SKU in a chat session to “feel real-time.” That is how you approach a support-shaped ~$791/mo floor without monitoring anything.

If RCA later asks why conversion dropped, a closed finding with evidence_ref on advertised SKU ATP is a hop — not a vibe.

Do not start with AWS

A quality program that begins with CreateHarness will skip the scanner and call the model 50K times.

There is no native Shopify AgentCore connector. Shopify Admin, PIM, and inventory APIs are OpenAPI you own. Do not Browser-scrape Admin as a monitor — you will page on UI lag and still miss asOf.

Gateway ~95 ms on the CRM canary is irrelevant to a 2 a.m. batch. Keep scans off the conversational session meter when you can. Interactive investigations are what you price on the calculator.

Memory, if used, stores finding_id and last scan watermark — not the full catalog blob. Knowledge Bases may hold the rule prose for investigators (“what missing care means on apparel”). They must not be the scanner. Observability: findings opened, duplicate suppressed, investigate turns, attempted DENY on write tools, tokens per investigation — not a vanity “AI quality score.”

What broke

What broke — A “quality agent” used the same prompt as catalog draft (post 9) and was given publishProduct “so monitors could heal the feed overnight.” The model filled empty care instructions from a similar live SKU and published. Detection: Observability showed publishProduct with scanCatalogCompleteness never emitting human_required; validation worker was skipped because the monitor was treated as the gate. Fix: delete publish from the monitor catalog; deterministic scan only; createDraft stays on the merchandiser loop in post 9; findings are tickets. Lesson: monitoring is not auto-remediation.

A second failure: inventory anomaly rule called updateQuantity when receipts lagged by 20 minutes. ATP went to zero on an advertised SKU, then bounced. Fix: investigate receipts; page ops; never adjust ATP from this harness.

What to Do This Week

1. Confirm data-layer asOf and join keys exist for the domains you will scan.
2. Clone data-quality-monitor-rules.md. Set your N% and SLA.
3. Implement six deterministic checks in a worker. Do not ask the model whether a required attr is empty.
4. Keep PIM publish gates in catalog-validation-rules.md / post 9. Monitors do not publish.
5. Optional: Harness (GA June 17, 2026) with read-only investigate tools; Cedar DENY on writes. Not Classic after July 30, 2026.
6. Schema: finding_id, rule_id, evidence_tool, human_required. No personnel accusations.
7. Route warehouse/order breaks to exception handling — do not absorb them here.
8. Price investigation sessions, not a scan-as-chat, on the AgentCore pricing calculator. Contact us with the rule table.

What This Post Doesn’t Cover

• Join-key design — part 45
• PIM extract / merchandiser publish — part 9
• Cross-entity conversational joins — part 46
• “Why did revenue decline?” hops — part 48
• Order hold/split/cancel playbooks — order exceptions
• A FactualMinds client “findings closed per week” KPI — we are not inventing one
• Great Expectations / warehouse tests as a product comparison
• Auto-merge, auto-price, auto-ATP from monitors

FAQ

When should you NOT use an AI agent as the data-quality validator?

Never let the model be the gate for required fields, price equality, or asOf freshness. Those are code. Skip an investigation agent when you have no deterministic scanner, when findings would auto-publish or auto-adjust ATP, or when the only monitor is “ask the bot if the catalog looks fine.” Post 9 already owns PIM publish gates — do not remake extract/publish here.

What could go wrong if the model both detects and remediates?

It will “fix” a missing care instruction from a sibling SKU, merge two real customers, or write ATP because a jump “looked like a sync bug.” Detection without a human_required flag is how monitors become writers. Deterministic rules detect; the agent may draft an investigation; Cedar denies merge, publish, setPrice, and updateQuantity in week one.

How is this different from catalog management (post 9)?

Post 9 is how you produce catalog quality: extract, deterministic validate, merchandiser publish. This post is continuous monitoring across business data — products, customers, prices, inventory, sync lag — after records are live. Catalog publish gates stay in catalog-validation-rules.md. Monitors open findings; they do not press Publish.

What could go wrong if inventory anomaly investigation can call updateQuantity?

A false-positive jump (receipt not yet posted, location filter wrong) becomes a live ATP lie. The sample rule allows investigate receipts only. Adjust ATP is an inventory/exception write with HITL. Treat a monitor with updateQuantity as an unattended stock clerk.

Should monitors run in the same Harness as the data agent?

Prefer a scheduled InvokeHarness (or a worker that is not a chat session) for scans. Keep the conversational data agent on read tools for humans. Mixing “scan 50k SKUs” into a shopper or associate session blows token cost toward the ~$791/mo silhouette at 50K sessions without helping WISMO. Batch in a worker; page ops on severity.

Can the agent accuse a person of fraud or theft from a price change?

No. Suspicious change is a risk flag with evidence_tool, not a personnel finding. Fraud labels are not facts in listReturnsForOrder either. A human owns HR and loss-prevention language. The output schema sets human_required: true on those rows.

Need deterministic eCommerce data-quality monitors with optional investigation — not a model that publishes? Contact FactualMinds or start from Generative AI on AWS and AWS for retail / eCommerce.