Designing Data Architecture for AI-Integrated Supply Chains

One of the reasons why I love supply chain data science is because supply chain systems are complex and data science methods offer key ways to see the tradeoffs between different parts of the system. 

Here’s a common example. The sales team makes an aggressive deal and the fulfillment team has to pay for overtime and expedited shipping to honor the contract. The sales team has met their KPI of units sold and the fulfillment team has met their KPIs on OTIF, but the company as a whole has lost money on the deal. As a supply chain data scientist and consultant, I see these tradeoffs operating across many major companies, often without the company’s knowledge. 

Let’s consider another example. Procurement is sourcing the majority of a key component from Vendor A. Vendor A offers the best unit cost and the fastest lead times, but holds very little on-hand stock and is geographically limited (e.g., only has manufacturing in Vietnam). The procurement team gets the majority of their widget volume from Vendor A, with Vendor B and C only kept on as token backups. Simultaneously, in another far corner of the office, the supply chain risk assessment team is trying to avoid single-source dependencies and keeps its own dashboard with its own KPIs. Ideally, these two teams would work together on a vendor allocation strategy to balance cost and resilience. 

In a well-functioning company, teams agree on company-wide metrics and work together to balance those tradeoffs in line with overarching executive strategy.  For this thought piece, let's assume we’ve done the hard work of getting a company to agree on a comprehensive set of metrics and holistic guidelines on how to evaluate tradeoffs (e.g., using ASCM’s SCOR framework). This still leaves us with a key question… How do we design a data system that makes these trade-offs visible and actionable? And how do we integrate autonomous AI agents into that system in a safe and reliable way?

In this article, I propose a data architecture that is grounded in what can be built today using current best practices in ETL, ML Ops, and AI agent consumption. The architecture inherently reflects a separation of concerns between business teams and engineering teams. And most importantly, this architecture reflects the real need for both humans and AI agents to consume the same information identically and simultaneously.

Part One: One Source of Truth

Let's walk through the architectural diagram, starting at the bottom with the software layer. Data flows from the supply chain software to the data mart following traditional dbt best practices. Final metrics for the entire company are defined once in a metric calculation config file and exposed to all users in the semantic layer. 

Going back to our vendor allocation example, let’s say that the company has set up a data connection to its vendors, keeping track of their daily yields of an important subcomponent. The vendors also send a weekly email that shows their excess capacity. These two key data streams get fed into the central data warehouse. 

What the Ops Team Sees

For the operational teams, they see both the ops dashboard from the ops data mart’s semantic layer, as well as the data quality dashboard (DQ Dash) from the alert engine which focuses on anomaly detection. The alert engine watches the ops data mart for statistical signals. It is meant to catch things like a metric moving outside its normal range (e.g., the vendor yield is slowly declining over time), and is distinct from a threshold being crossed on a known metric (e.g., the vendor yield suddenly dropped 20%, day over day). 

The alert engine feeds into the data quality dashboard, surfacing data-trust and anomaly signals to a human, as opposed to ops dash, which shows supply chain health and performance. The alert engine doesn't only feed a human dashboard, it also feeds the AI agent directly via the API. The same anomaly signal has two consumers: 1) a human and 2) a machine. This same architecture is repeated in the ops data mart where the semantic layer feeds both the ops dash (human) and the API (AI agent). 

Where the Rules Come From: Simulation and Work Policy

Now let’s turn to the simulation piece of this diagram by going back to the single-source problem. Instead of guessing at the right vendor allocation policy, you can simulate it. Run scenarios where Vendor A's capacity drops by different amounts and see how various vendor-mix policies hold up. 

A couple of valuable artifacts result from the simulation. First, the simulation makes it very easy to see obvious and actionable trade-offs. Second, the results of the simulations provide business insights that aren’t always immediately obvious**. And finally, we get a work policy. 

The work policy is the business logic that guides the simulation on how to act. If after running a thousand likely scenarios we find that a mix of 50/25/25 across Vendors A, B, and C offers the best trade offs between cost and reliability, then that becomes the rule we implement in the business logic. In this way, the simulation policy can be used directly in the development of the rules engine that the AI agents will consume. 

Part Two: Keeping Humans in Control of the Rules

Let's talk about what's going on in the top left side of this diagram.

In the top left corner, we have a few elements, most important of which is the business logic. As we noted earlier, the simulation’s work policy informs the rules engine, but doesn’t feed it directly. 

Here, we have a straight line from a UI into the rules. This simple user interface allows non-technical operations teams to change the rules directly***. This can be for small tweaks, but it is also a kill switch. Most importantly, it means that immediate operational changes do not end up in a software engineering backlog. 

This is a key design piece and reflects a clear separation of concerns. The software engineering team designing and maintaining the AI agents should not be maintaining the rules; the AI agents should simply consume the business rules. 

For the vendor allocation strategy, the ops teams might set up business rules that if the primary vendor’s yield starts to consistently decline, volume must be shifted to alternate vendors. The rule could be something simple like, “fill the gap by using the vendor with the most capacity and only when that capacity is completely utilized, add in the next vendor.” Or alternatively, the rule could be something like, “fill in the gap by utilizing the next cheapest vendor, adding in vendors ranked by price until the capacity gap is met”. 

What the AI Agent Sees

Now we get to the API layer****. The AI agent is consuming the metrics and the metadata sidecar from the semantic layer in the centralized data warehouse*****. It also consumes the alerts propagated from the anomaly detection layer. Separately, it's consuming the business rules and pricing information from vendor contracts. The AI agent sees an alert, reads the business rules from the ops team, takes a specific action, then records that action in a log.

Let’s say yield from Vendor A has slowly declined week over week, until a predefined ML alert is triggered. The company has a predetermined rule that when these types of alerts are triggered, the procurement team needs to shift volume from Vendor A to Vendors B or C. The AI agent surfaces the alert to the sourcing team alongside a suggestion on which alternate vendor to use and why. 

This means the AI agent needs to 1) see the alert from the alert engine, 2) reference the relevant business logic, 3) reference the capacity metrics from the other vendors in the metric semantic layer, 4) make a suggestion on where to shift capacity (referencing back to the business logic and possibly the pricing contracts), and 5) log all of these actions for the procurement team to review. 

Part Three: Logging and Oversight

This is where the right hand side of the diagram comes in. 

The AI engineers maintain the observability and reasoning logs, but the ops team maintains the action logs to run sanity checks. For the vendor allocation strategy, the ops team may want certain guardrails in place, such as verifying the AI checked with 3 vendors and not 300 vendors. Also, the rule that the AI agent cites should match its suggestion (e.g., Vendor A’s yield dropped by 15%, but the AI agent recommends a 60% reallocation). 

Most critically, this separation of concerns allows the AI engineers to focus on agent health. How long did it take from the agent to go from alert to recommendation? Did the agent get stuck in a loop or spam the API a hundred times? How many tokens are the agents consuming?

Conclusion

The architecture here is built around making trade-offs visible, but it also gives operational teams a fast, direct way to change the rules the moment those trade-offs shift. This is because the business rules live outside the code and are owned by the ops teams. The architecture reflects a clear separation of concerns, but also allows everyone to consume the same rules and the same metrics at the same time. 

Footnotes

* It is surprising how often I have to say this to clients, but when deciding your KPIs, you need to make sure that there is a clear ladder from executive strategy down to daily tactical decisions. The metrics chosen should define that layered strategy from the top down to the bottom. 

** Simulations at the level of mechanical processes, such as a specific manufacturing factory, are often very accurate, even down to the second. Simulations at the level of human workers in a store are still decent. Simulations at the level of global supply chains will, unfortunately, be significantly less accurate. However, the simulation will still be of value in two ways. First, it'll indicate the direction and magnitude of proposed business changes. Second, it often reveals counterintuitive results that even long-term business practitioners have a hard time believing until they see the simulation run. This is a pretty standard occurrence in complex systems. 

*** DMN is a standard way to represent these rules that often feeds into commercial rule engines, but any similar style will work. More on this in a separate article.

**** This diagram assumes the simplest possible architecture, so we can stay focused on the key points, but I'll have a later article comparing REST vs. MCP vs. Kafka and how those things can be alternatives to one another or work side-by-side in sequence.

***** In dbt-style architecture the metadata about a semantic layer, such as its timestamp, gets stored in a separate file called a sidecar. This separate element must be fed into the AI agents alongside the metrics. More on this in the next article.