The AI Data Agent: Connecting Orders, Customers, Products and Inventory (2026)

Tuesday, an associate asks: “Can we ship SKU DEMO-SHOE-10 on order DEMO-1001?” They open Shopify, the OMS, inventory, the PIM, and returns — five tabs, no single answer. After July 30, 2026, new agents should not start on the older Agents Classic product.

This is series part 46: the cross-entity evidence agent that joins orders, customers, products, and inventory. It is not store intelligence / analytics Q&A (part 6). It is not a warehouse copilot. There is no unrestricted SQL. Fixture ids in the artifact are demo data. We do not invent a client “join success rate.”

The job. Answer cross-entity questions — where is the order, can we pick this line, has this order had an RMA — with named tools and evidence on every fact. Not a graph database with opinions. Not SELECT *.

This week. Stand up six named read tools (getOrder, getCustomer, getProduct, getInventory, listReturnsForOrder, searchOrdersByCustomer). Require evidence_tool on every fact. Cap rows at 25. No SQL tool.

A person still signs. Customer merges and ATP writes stay human-owned with Cedar and HITL.

Skip it when join keys are undocumented, leadership wants executeQuery on a replica, or the “agent” is supposed to merge accounts or adjust stock.

Our take: every answer cites named tools and a join, or the agent refuses. Trade-off: more “I don’t have a tool / the join is missing.” Operators stop treating the bot as a warehouse with opinions.

Copy the tool catalog — Open ai-data-agent-tool-catalog.md. Every fact field needs evidence_tool + evidence_ref. If a join fails, return unknown. Folder: ecommerce-ai-agents-series/. Prerequisite: AI-ready business data layer.

FactualMinds is an AWS Select Tier Services Partner. We help merchants bound the tool catalog — we do not sell SQL-to-Slack.

Not the analytics bot, not a warehouse

If the layer does not exist, stop. A hosted loop will not invent shopify_order_id → oms_order_id.

From floor question to evidence

flowchart TD
  BusinessQuestion[Business Question]
  DataAgent[AI Data Agent]
  ControlledTools[Controlled Business Tools]
  Orders[Orders]
  Customers[Customers]
  Products[Products]
  Inventory[Inventory]
  AnswerEvidence[Answer + Evidence]
  BusinessQuestion --> DataAgent
  DataAgent --> ControlledTools
  ControlledTools --> Orders
  ControlledTools --> Customers
  ControlledTools --> Products
  ControlledTools --> Inventory
  Orders --> AnswerEvidence
  Customers --> AnswerEvidence
  Products --> AnswerEvidence
  Inventory --> AnswerEvidence

The model sees tool JSON, not a warehouse. Orders, customers, products, and inventory are views behind operationIds. There is no native Shopify AgentCore connector — Gateway calls Admin, OMS, PIM, or inventory APIs you wrap.

Allowed read tools

From ai-data-agent-tool-catalog.md:

Every answer field that is a fact must set evidence_tool + evidence_ref. If a join fails, return unknown — do not invent. Cap result rows (example: 25). Reject tools that accept raw SQL. Log tool name, args hash, and latency on Gateway.

WISMO needs getOrder + carrier fields, not a customer export. A merchandiser asking “is this SKU pickable for order X?” needs getOrder lines joined to getInventory on the sellable SKU. Analytics post 6 still owns “why did sales move this month?” with salesByPeriod. Mixing the catalogs in week one produces a bot that quotes industry stats when getInventory was never called.

Worked turns (fixtures — replace ids)

These are demo turns. They are not a FactualMinds engagement.

Turn A — WISMO. Associate: “Where is order DEMO-1001?” Allowed path: getOrder(order_id=DEMO-1001) → status + asOf. If OMS id is missing, return unknown and the join gap — do not guess WMS PICK-88 as the customer-facing number. searchOrdersByCustomer is the wrong first tool unless the associate only has an email and Cedar allows that search.

Turn B — pickability. “Can we ship DEMO-SHOE-10 on DEMO-1001?” Required: getOrder (line exists, not cancelled) then getInventory(sku=DEMO-SHOE-10) with location the role may see. If ATP asOf is older than SLA, say unknown, not in_stock. Do not call getProduct for a tracking answer; do not skip inventory because the title “looks available.”

Turn C — returns context. “Has this order already had an RMA?” listReturnsForOrder returns rma_id + reason_code. Fraud-shaped labels stay off the payload. The data agent does not approve the refund.

Eval the three turns. Fail if evidence_tool is missing, if SQL appears in args, or if a join miss is narrated as a fact.

Assumed eval contract:

# ai-data-agent-tool-catalog.md
FAIL if tool args contain SQL
FAIL if result rows > 25 without pagination
FAIL if fact field missing evidence_tool
FAIL join: return unknown — do not invent
PII stripped in the tool, not in the prompt

Who sees which tools

That table is the security post applied to this catalog. Identity JWT claims must flow into Gateway Policy. The harness execution role is what AWS APIs the loop may call — it is not least privilege inside commerce APIs. Secrets for OMS live in Secrets Manager, not in instructions.

Do not start with AWS

Do not start with a stack slide. Start with the data layer and this catalog.

Use Harness for this short read list. Export to Runtime plus Strands when a supervisor must hop-cap a data specialist away from exception writes. Strands does not give you microVMs, Gateway, Identity, Policy, or secrets. Next.js can render evidence cards for associates; it must not embed the tool sandbox in a server action.

Knowledge Bases, if you use them, hold policy text (return windows, WISMO scripts) — not live ATP. Retrieval of a stale help article is not getInventory. Memory holds the current order_id / runtimeSessionId (≥33 characters on the Harness data plane), not a nightly replica dump.

Observability should show: tool name, args hash, latency, DENY on any write operationId you accidentally attached, token count per turn. CloudTrail on bedrock-agentcore.amazonaws.com is how you replay a leak. A BI screenshot in Slack is not that log.

For your technical lead

On June 17, 2026, Amazon Bedrock AgentCore Harness reached general availability — a config-driven loop with Gateway tools (What’s New). 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 store results) — 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). Chatty “ask anything about the graph” sessions are session time + tokens; model them on the AgentCore pricing calculator. Treat ~$791/mo as a platform cost floor to plan against, not as savings. Gateway ~180 → ~95 ms is that CRM canary — not your OMS.

What broke — A prototype labeled “data agent” reused the post 6 analytics prompt and added executeQuery “for flexibility.” A turn asked whether order DEMO-1001 could ship SKU DEMO-SHOE-10. The model queried a replica, joined on email, and reported ATP from a warehouse the associate role cannot see. Detection: evals that only checked “sounds right”; Gateway log showed raw SQL and a 2k-row payload; Observability had no evidence_tool. Fix: delete executeQuery; six named tools; row cap 25; shopper vs associate Cedar; fail the golden if getInventory was skipped. Lesson: flexibility on a replica is how you skip the join contract and leak PII.

A second failure: attaching mergeCustomer so duplicates “clear overnight.” That is an account write. Keep duplicate_flag on getCustomer; a human merges.

Context: Python 3.12+ or Node 24+; AgentCore Harness GA June 17, 2026; Gateway OpenAPI.

Platform math, not savings: if you cannot describe a workload that would notice a ~$791/mo floor at 50K sessions, you are funding a demo. Gateway ~95 ms is not getInventory p95. Six tools × a chatty floor team will dominate tokens long before Hosting looks expensive — price your mix.

What to do this week

1. Confirm join keys exist — data layer. If not, stop.
2. Clone ai-data-agent-tool-catalog.md. Map operationIds to your OMS / PIM / inventory APIs.
3. Implement PII stripping in the tool. Cap rows at 25. Reject SQL.
4. Goldens: WISMO-style getOrder; “can we pick this line?” = getOrder + getInventory; join miss → unknown.
5. Stand up Harness (GA June 17, 2026); Gateway reads only; Policy LOG_ONLY then DENY writes. Not Classic after July 30, 2026.
6. Do not merge this catalog with analytics tools in week one.
7. Walk ecommerce-agent-security-checklist.md.
8. Price sessions on the AgentCore pricing calculator. Contact us with the catalog, not a SQL URL.

What this post doesn’t cover

• Join-key design and seven-domain checklist — part 45
• Analytics Q&A tool catalog — part 6
• Deterministic quality monitors — part 47
• Revenue RCA hops — part 48
• Customer merge, ATP adjust, price writes (Cedar + HITL on other agents)
• A native Shopify AgentCore connector (it does not exist)
• Measured FactualMinds “tickets deflected by joins” — we are not inventing them

FAQ

When should we NOT deploy an AI data agent?

Skip it when join keys are undocumented (see the data-layer post), when leadership wants executeQuery on a replica, or when the question set is five saved BI tiles nobody will converse with. Also skip it if the “agent” is supposed to merge customers or adjust ATP. A join without named tools is a spreadsheet. A tool that accepts raw SQL is not a data agent.

What could go wrong if the data agent has unrestricted SQL?

PII, cost, and payment-adjacent columns land in Memory and Slack. Result sets exceed any hop budget. The model invents joins when the warehouse has three order ids. Detection: Gateway traces plus oversized payloads. Fix: reject tools that accept SQL; cap rows (example 25); require evidence_tool on every fact. This is how store-intelligence prototypes failed — do not repeat it here.

How is this different from the analytics agent (post 6)?

Post 6 is pull Q&A over a curated analytics catalog: salesByPeriod, refund clusters, risk segments — answer plus evidence for chart-shaped questions. This post is the cross-entity evidence agent: getOrder joined to getCustomer, getProduct, getInventory, listReturnsForOrder. Do not merge them in week one or the data agent becomes a second BI chatbot with write ambitions.

What could go wrong if getCustomer returns emails and addresses to the model?

Session Memory and HITL paste become a PII store. Shopper JWTs must not see associate tools. Gateway Policy and the tool implementation strip PII before the model sees the payload — a prompt that says “do not show PII” is not a control. See the security post in this series. secure agents.

Can the data agent merge duplicate customers or write inventory?

No in this sample. searchOrdersByCustomer may set duplicate_flag; a human merges. getInventory is ATP asOf, not updateQuantity. Writes belong on exception and inventory agents with Cedar and HITL. A data agent with mergeCustomer is an account-takeover tool you did not review.

Harness or Runtime for the data agent?

Harness (GA June 17, 2026) fits a short read catalog: getOrder, getCustomer, getProduct, getInventory, listReturnsForOrder, searchOrdersByCustomer. Runtime plus Strands 1.0 when you export and need hop caps across specialists. Strands is Agents-as-Tools / Graph / Swarm / Workflow — not Gateway, Identity, or microVMs. Bedrock is models, not the host. Next.js is HITL UI. No native Shopify AgentCore connector.

Need a cross-entity data agent with evidence fields and no SQL tool? Contact FactualMinds or start from Generative AI on AWS and AWS for retail / eCommerce.