Retail businesses run on SKUs. The data model underneath retail has to run on them too.
In our last piece, we introduced the Inventory Data Platform as the unified data layer that sits across a retailer’s existing systems and makes them coherent for the AI era. Unifying the data is step one. The harder question, the one every retailer is about to face, is what structure that unified data actually needs to have for AI agents to reason over it usefully.
This is where retail is genuinely different from almost every other industry, and where most horizontal data software falls short. Retail does not run on the same atomic unit as the rest of enterprise software. If the data layer underneath the agents deployed by retailers is not built for the way retail actually operates, AI agents will produce confident answers at machine speed, and those answers will frequently be wrong.
The Inventory Data Platform was designed to solve this. The part of the Inventory Data Platform that does the real heavy lifting is a specific piece of technical architecture: a retail-native ontology, a retail-native knowledge graph which can then service the agents and interfaces (e.g., dashboards, natural language query via Claude or Copilot) that will drive your business. This post explains, in plain language, what those key technical pieces are, why they have to be vertical by necessity and not by preference, and why they are the difference between retail AI that works and retail AI that doesn’t.
Retail runs on SKUs. Almost no software is built that way.
Every business has an atomic unit. It is the smallest thing the business plans, forecasts, measures, and manages by. For most of the enterprise software world, that atomic unit is the customer. SaaS companies, B2B services, consumer subscription businesses, and financial services firms all organize their P&L, their forecasts, their account teams, and their operational plans around customers. Sales are a roll-up of customer dollars. Retention is measured per customer. Pipeline is a roll-up of customer opportunities.
This is the world Silicon Valley builds for. When a horizontal data platform or an agent framework gets designed,the vast majority of the demand it is built to serve comes from customer-centric businesses. The data models, the KPIs, the default integrations, the product metaphors, and even the sample dashboards all assume the customer is the thing you are rolling up to.
Retail does not work this way. A retail P&L is a roll-up of styles and SKUs. Inventory is managed at the SKU level. Pricing is set at the SKU level. Allocation, replenishment, markdown, and assortment decisions all happen at the SKU level. Forecasting is a SKU-by-location problem. Planning is a SKU-by-season problem. Execution is a SKU-by-channel problem. Marketing loses efficiency without a SKU level focus. The Chief Merchant, the planning team, the store operations team, and the DC leaders do not plan customers. They plan the business in SKUs that sometimes belong to customers.
This is not a minor preference. It is a structural difference in how the business actually runs. A data model organized around customer records cannot represent the relationships between a style, its colorways, its sizes, the stores and DCs that hold its inventory, the vendor that produces it, the orders that move it, and the promotional windows that affect its demand curve, with enough fidelity to let an AI agent make a useful decision about any of it.
This is why you cannot get to reliable retail AI by retrofitting a horizontal platform for retail. You can configure the field names. You can add some retail-flavored connectors. You can put a dashboard template on top. None of it changes the underlying fact that the model was designed to roll up to a customer and the retail business rolls up to a SKU.
What AI agents actually need
An AI agent is only as reliable as the context it can reason over. When a merchant asks an agent “where do I have too much spring-break inventory, and where could I move it without creating a stockout,” the agent is not looking up a number in a table. It is working through the relationships between products, styles, SKUs, stores, DCs, lead times, demand signals, and promotional windows, and composing an answer that respects the constraints in all of those relationships at once.
For the agent to do that, the underlying data has to express those relationships in a form the agent can use. That does not mean “clean data.” It does not mean “all the data in one warehouse.” It means a structured representation of the retail business itself, in enough detail that an agent can reason across it and produce an answer the merchant can act on.
The retail industry has a loose catch-all phrase for “data that has enough structure for AI to use”: semantic layer. It is a real concept, but the phrase has gotten stretched across so many different vendor implementations that retailers are often genuinely unsure what they are being sold. What retail AI actually needs is more specific than a generic semantic layer. It is two things, working together: an ontology and a knowledge graph.
Ontology and knowledge graph, in plain language
An ontology is a formal map of the business. It describes, in a way machines can read, what the entities in the business are (products, styles, SKUs, stores, DCs, vendors, customers, orders, shipments, promotions), how those entities relate to each other (which SKUs belong to which styles, which inventory sits at which location, which orders move between which nodes), and the rules that govern how those relationships change over time (how inventory moves when a transfer is created, how a return becomes available again, how a markdown flows through margin attribution).
Think of the ontology as the operating manual for the retail business, written in a form an AI agent can actually read.
A knowledge graph is the live, always-current version of that operating manual, populated with the actual data and continuously updated as the business runs. An agent does not traverse a spreadsheet or a stack of tables. It traverses the knowledge graph, following the relationships encoded in the ontology, to reason about the business.
Together, the ontology and the knowledge graph are the specific technical architecture that makes an AI agent capable of reliable decision-making in retail. “Semantic layer” is the loose term. An ontology and a knowledge graph are the two specific things underneath it. If a retailer is told they need a semantic layer and the vendor cannot articulate the ontology and the knowledge graph inside it, the retailer has been sold a dictionary or a naming convention, not a foundation for AI.
Why Ekyam’s ontology and knowledge graph are retail-native
Ekyam’s Inventory Data Platform is built on a retail-native ontology. It encodes the atomic entities every retail business depends on: products, styles, SKUs, colorways, sizes, vendors, suppliers, stores, distribution centers, channels, customers, orders, shipments, receipts, returns, promotions, and pricing actions. It encodes the relationships that bind those entities: which SKUs belong to which styles, which inventory is held at which node, which orders move between which locations, which vendors supply which products at which cost, which promotions affect which assortments in which windows. And it encodes the business rules that govern how those relationships evolve over time: how a SKU moves through its lifecycle, how inventory transitions between physical and logical locations, how a return becomes available inventory again, how a markdown propagates across attribution and margin calculations.
None of these are foreign concepts to retail executives and operators. Every merchant, planner, and ops leader in a retail organization already knows this structure. What is novel is encoding it in a form that machines can reason about. That is what an ontology is for.
The knowledge graph is the live, populated instance of that ontology. It is what lets an agent answer a question like “which stores are overstocked on the mid-season jacket assortment, and where could we reallocate the excess without risking a stockout at any receiving node,” in one traversal, respecting the constraints of lead time, transfer cost, demand signal, and SKU-level availability, and return an answer any of those functions can actually act on.
A generic semantic layer cannot do this. A horizontal data platform’s ontology, if it has one at all, was built around the customer. A retail-native ontology, with a knowledge graph running on top of it, is the difference.
Why this matters now
Two things are changing simultaneously. First, AI agents are moving from experimental to operational inside retail. The frontier model providers have made the agents capable enough that the bottleneck is no longer the model. It is now the data the model has access to, and the structure of that data. Second, retail leaders are beginning to recognize that “deploy agents on top of our existing data stack” does not produce reliable outcomes. The models are confident. The answers are not. When a CEO asks why, the answer is almost always that the agent is reasoning over data that was never structured for reasoning, and was certainly never structured for the way retail runs.
The retailers who will pull ahead are the ones treating this as an infrastructure decision rather than a tooling decision. They are investing in a retail-native data foundation that includes both the ontology and the knowledge graph, and they are running their agents on top of that foundation rather than on top of a lightly governed warehouse. Their AI will work. Their competitors’ AI will not.
The strategic implication
When a vendor offers a retailer a “semantic layer,” the right follow-up question is concrete: what is the ontology, and what is the knowledge graph. If the answer is that it is just a metrics dictionary, a data dictionary, or a BI modeling layer, the gap between that answer and the semantic layer actually required for AI agents will result in wrong decisions at machine speed.
The Inventory Data Platform is not a branded wrapper around a generic semantic layer. It is a canonical model, a retail-native ontology, a populated knowledge graph, and the connectivity layer that keeps them current across the retailer’s existing systems. It is designed for the way retail actually rolls up. It is designed for the agents retail is about to run on top of it.
To explore how Ekyam’s Inventory Data Platform, retail-native ontology, and knowledge graph can serve as the foundation for agent-ready retail operations, schedule a conversation at ekyam.ai.
