There is a version of the AI conversation happening right now in retail boardrooms that sounds very reasonable: connect Claude, ChatGPT, Copilot, Gemini, or another agent to the systems where the data already lives. Shopify has an MCP. NetSuite has APIs. Snowflake, Databricks, and Fabric unify and store data. Why not connect the model and let the business start asking questions?
The vision is right. The assumption underneath it is faulty.
Access to systems is not the same as operational intelligence. Connectivity lets an AI model reach data. It does not tell the model which data is right, which system to trust, how records relate, what definitions apply, what already happened, or what action is best to take next.
In practice, putting an LLM on top of Shopify, NetSuite, SAP, an OMS, a WMS, a POS, a PIM, a 3PL, a data lake, or a warehouse often creates three problems: confident wrong answers, inconsistent results, and a cost curve that gets worse as usage grows.
1. The correctness problem
A merchant asks: “How many units of this style do we have available to sell?” The model can access multiple systems or tables that appear to answer that question. That sounds like progress, but each system may represent a different version of inventory.
The ERP may show inventory by financial ownership or book balance. The WMS may show what is physically on hand. The e-commerce platform may show what is sellable online. The OMS may reflect reservations, holds, open orders, cancellations, and channel rules. Each number may be technically correct in its own context. None may be the answer the merchant actually needs.
If the model pulls from the wrong system or field, combines numbers without the governing business logic, or applies the wrong definition of “available,” the answer is still wrong, even if it is delivered with confidence. When an agent uses that same logic to flag reorder risk, recommend allocation, reroute fulfillment, or prioritize late orders, the company is making flawed decisions faster.
2. The consistency problem
Even when AI gets the right answer once, there is no guarantee it gets the same answer next time.
A planner, merchant, and customer service lead may ask the same question in slightly different ways. The model may choose a different table, call a different tool, query a different system, apply a different filter, or interpret a business term differently. Without governed definitions and resolved entities, each question becomes a fresh interpretation of raw operational data.
That is the fastest way to erode trust. Once teams see two AI-generated answers to the same question that do not match, they usually do not debate model architecture. They go back to their prior way of working, often marrying data across Excel, BI, and other tools.
3. The cost problem
The third problem is less visible at first, but it becomes very visible at scale. Every AI answer consumes tokens. When the data layer is not organized for AI consumption, the model has to do more work before it can answer: find the right data, understand the fields, match records across systems, interpret business terms, and decide which relationships matter.
That work shows up as token cost, latency, retries, warehouse compute, and human review. In one representative supplier-lateness query, the business question was simple: “Which suppliers are most often late vs. their PO promised dates?”
That question cost about one cent through Ekyam because the relevant business context was already organized before the model answered. Asking that question through a strong governed database approach, with metric definitions and a business glossary, cost about nine cents because the model still had to generate the query and work through cross-system relationships at runtime. A raw file-dump approach cost about $33 because the model was effectively being asked to sift through raw data.
This is not a universal benchmark of every architecture. As shown, a well-designed warehouse implementation, semantic layer, or schema-routing approach can work well for single-domain metrics. The point is narrower: when cross-system relationships, joins, and operational context still have to be worked out at query time, every answer pays for work the data layer could have already resolved.
AI cost does not scale with ambition. It scales with usage. The more successful the rollout, the more expensive unresolved operational context becomes.
Connectivity is necessary. It is not sufficient.
An MCP server is useful. So are APIs, data warehouses, and lakes. They make data easier to reach. But they do not, by themselves, create operational truth.
MCP is an access layer, not a reconciliation layer. It does not resolve product identity across systems, create one definition of available-to-sell, decide whether NetSuite, Shopify, SAP, the WMS, the OMS, or the planning system should be trusted for a specific question, or preserve the business history of what changed and why.
The same is true of the warehouse. Putting ERP, WMS, OMS, POS, e-commerce, and planning data in one place is necessary, but it does not automatically resolve different product identifiers, supplier records, inventory definitions, timestamps, or exception rules. The data may be co-located while the business meaning remains fragmented.
Once an AI agent is connected to several systems, the agent can effectively become the reconciliation layer at runtime. It has to decide which system to query, how to match records, which definition applies, which timestamp matters, and what action is permissible. That is a high-variance and high-cost way to run an operating business.
What AI actually needs
AI needs resolved entities, so the same product, supplier, order, customer, store, shipment, and location mean the same thing across systems.
It needs governed definitions, so terms like available-to-sell, on hand, committed, reserved, late, fulfilled, cancelled, margin, and demand mean one thing in a given business context.
It needs source-of-truth rules, so the agent knows which system to trust for which data point and under which conditions. It needs permissioning and auditability, so the business can control what the agent can see, recommend, and do, and trace why it gave a particular answer.
And it needs time-based context, so the agent understands not just what is true right now, but what changed, when it changed, what was promised, what was revised, and what has already happened.
This time dimension matters more than most leaders realize. Retail is not just a current-state business. A PO was placed, revised, delayed, split, received, short-shipped, cancelled, escalated, re-promised, or substituted. A customer was contacted, refunded, appeased, or not. A merchant already rejected the reorder recommendation last week. A supplier already missed the same promised date twice.
Without that history, AI mostly reports on snapshots. With it, AI can start to support operating decisions.
What to ask your team
When our AI tools answer a question about inventory, which system are they using, and why?
If Shopify, NetSuite, SAP, the WMS, the OMS, and the warehouse disagree, which source does the AI trust?
Do we have one governed definition of available-to-sell, or does the answer change by system, channel, or team?
Can the AI resolve that two supplier, product, order, or customer records in different systems refer to the same real-world entity?
Can we trace why the AI answered the way it did, including the source, rule, timestamp, and logic applied?
Do we know what our AI tools cost per query and how that cost scales as usage grows?
Can our AI agents see what changed over time, or only what is true right now?
The real AI readiness gap
The next wave of retail AI lessons and perhaps disappointment will not come from a lack of model capability. It will come from confusing system access with business context.
Retailers do not need AI that can simply reach more data. They need AI that can reason from data the business already trusts.
At Ekyam, this is the problem we solve. We create a configurable governed operational context layer across the systems retailers already run, so AI agents, applications, and operating teams work from the same trusted answers across products, inventory, orders, suppliers, stores, customers, and channels.
The AI strategy conversation matters. But the data foundation conversation is what determines whether the strategy actually delivers.
