Why Supply‑Chain Agents Need Knowledge Graphs

Executive Summary

• Supply‑chain product structures are deeply hierarchical, but relational tables flatten, compress, or denormalize that hierarchy, making it difficult for both humans and automated agents to interpret relationships and dependencies of the Bills of Materials (BOMs).
• Conventional AI agents struggle because they must reconstruct relationships from the tables using complex operations, leading to brittle and error‑prone reasoning as complexity grows.
• A Schema‑RAG agent using a knowledge graph makes all relationships for the agent explicit, enabling precise navigation of BOMs, components, and initiatives without reconstruction and resulting in more accurate decision‑support.

Introduction

In supply‑chain and manufacturing environments, product structures rarely live in one place. They are spread across many relational tables or squeezed into a single, extremely wide dataset. These tables typically represent Bills of Materials (BOMs): each BOM describes a product or sub‑assembly, and each entry references another BOM or a component. Together, they form a deeply nested hierarchy of parts.

When these structures are expressed as tables, the hierarchy becomes implicit.  Re‑assembling it requires interpreting identifiers, stitching datasets together, and coming up with a complex query that would return the necessary information.

These limitations surface sharply when organizations deploy AI agents to answer natural language questions by reasoning over the data with embedded hierarchy. Without explicit structure and context, even advanced agents struggle to understand nesting, dependencies, or how changes ripple through assemblies. Instead of navigating a clear hierarchy, the agent is forced to reconstruct one using complex SQL queries.

BOM Example: Electric‑Vehicle Batteries

Consider an electric car. It is built from hundreds of assemblies: doors, steering systems, seats, wheels, batteries, and countless sub‑assemblies. Every assembly has its own BOM. Each BOM references sub‑assemblies, which in turn reference smaller parts even down to screws. Combined, these BOMs form a multi‑level hierarchy with thousands of nodes.

On top of this structure, organizations apply ongoing initiatives such as engineering changes, safety updates, and model‑year revisions. These initiatives determine whether a BOM entry is active, newly introduced, or retired. To understand the current state of a product, a system must combine two pieces of logic:

• the nested hierarchy of BOMs
• the initiative‑driven rules that modify them over time

A simplified EV‑battery breakdown illustrates the complexity (see the diagram):

• Battery Pack: the full vehicle‑level assembly
• Battery Modules: groups of cells
• Battery Cells: electrochemical units storing energy
• Internal cell components: electrode stack, casing, terminals, tabs
• Mechanical fasteners: screws securing structural or electrical connections
• Pack‑level systems: cooling, high‑voltage contactors, battery‑management system

Even this simplified model produces a large, hierarchical structure. Product Lifecycle Management (PLM) systems like Dassault 3DEXPERIENCE manage this explicitly as a product‑structure tree. However, when stored in relational tables, this structure becomes difficult to see. This is where challenges for AI agents begin.

Why Conventional AI Agents Struggle

The multi‑level product structure dissolved into tables makes even simple questions unexpectedly difficult for an AI agent to answer. Take a straightforward example:

“Which vehicle models were affected by the 2025 safety update to cell tabs and what part did it replace?”

A domain expert might see a clear chain of dependencies. A conventional agent does not. Working only with relational data, the agent must:

• identify the relevant safety initiative
• determine which BOM entries it modifies
• locate the specific cell tabs
• identify what they replaced
• climb the hierarchy to find the affected vehicle models

The challenge is not the question, it’s the representation. As the number of components, BOMs, and initiatives grows, the amount of inference required multiplies. Retrieval becomes fragile. Reasoning becomes inconsistent.

Explicit Hierarchy, Clear Reasoning: Why Schema‑RAG Works

A Schema‑RAG agent takes a fundamentally different approach. Instead of inferring structure from relational patterns, it operates on a knowledge graph in which assemblies, parts, and usage relationships are represented explicitly.

In the graph:

• each BOM entry is a node
• each parent–child relationship is an explicit edge
• each initiative directly links to the elements it introduces, modifies, or retires.

This transforms the reasoning problem. Hierarchy is no longer hidden. Initiative logic is no longer spread across multiple tables. The structure becomes visible and navigable as a connected model.

Consider an RDF‑based knowledge‑graph approach. With the structure expressed explicitly, the agent can use the ontology to identify the relevant entities and then generate a SPARQL query that traverses relationships directly in the graph store. SPARQL offers built‑in path expressions for multi‑level navigation, and the RDF Schema and OWL ontology supply clear semantic context, reducing the agent’s reliance on guessing or interpreting metadata.

SQL, by contrast, requires:

• multiple joins across several tables
• recursive CTEs to climb hierarchies
• strict reliance on metadata and knowledge of naming conventions

Even small mistakes can break a SQL query, and variations across schemas make generation harder. SPARQL avoids these problems by matching how the agent already reasons: as entities connected by relationships.

To answer the earlier question, the agent simply walks the graph:

• Safety Update 2025 → modifies → Cell Tab
• Cell Tab → is part of → Cell → is part of → Module
• Module → is part of → Battery Pack
• Battery Pack → hasAssembly → Vehicle Models

A knowledge graph makes the hierarchy and domain semantics explicit, and a Schema‑RAG agent uses those semantics naturally much like a domain expert reading a clear technical diagram instead of deciphering a spreadsheet.

Conclusion

Relational tables remain essential for storage, but they hide the hierarchical and evolving nature of BOMs. As organizations turn to data agents to support supply‑chain decisions, this lack of explicit structure and context becomes a major obstacle.

A knowledge graph removes that obstacle by representing BOMs, components, and initiatives in the way products actually work. A Schema‑RAG agent can reason about products the way domain experts do by following explicit relationships rather than reconstructing them.

For organizations building data agents, adopting a knowledge graph is not just a technical improvement. It is a foundation for safer decisions, more reliable automation, and scalable reasoning across complex product ecosystems.

If you want your agents to deliver accurate insights on real supply‑chain data, start by giving them the structure and context they need and a knowledge graph is the most practical way to do it.