Agentic AI Supply Chain: Building an Aerospace Ontology

Ask a supply chain assistant whether there are enough of a part to cover next week's build, and it will answer quickly. The answer is often wrong. In the agentic AI supply chain programs we see, the model is rarely the problem. The trouble sits in the data underneath it, where the ERP, the warehouse system and the shipping records each name the same part, place and shipment their own way.

That gap is about to matter more. Gartner expects 60% of enterprises using supply chain management software to have adopted agentic AI features by 2030, up from 5% in 2025. PwC's 2026 survey of 767 US operations and supply chain leaders found that 87% say poor data quality has hurt the value of their digital initiatives, and only 37% are comfortable letting AI agents run a whole process end to end.

For a global aerospace manufacturer, Mactores is building a supply chain ontology from three datasets: warehousing, shipping and materials. The goal is an AI that can say where stock sits, what's in transit and where shortages will bite.

The engagement is in progress, so we aren't quoting outcomes. The part numbers and quantities that follow are illustrative, chosen to show the kind of mismatch aerospace estates carry, and they aren't the client's data.

Why Does Supply Chain AI Struggle With Simple Questions About Stock, Transit and Shortages?

Because the systems it reads don't agree on what a part, a location or a shipment is. Take one titanium fitting, part number TF-4471-3, used four to a shipset on a wing assembly. A planner asks the assistant whether there are enough fittings for next week's 40 shipsets, which takes 160.

The ERP shows 240 on hand, so the assistant says yes. The warehouse system knows the same fitting as item 100458812, and it holds 90 of those 240 in quarantine pending a material review board decision.

Another 50 passed through receiving but are waiting for the supplier's certificate of conformance, and 30 are allocated to a spares order. Meanwhile, a shipment of 120 is on its way, but the advance ship notice carries the supplier's own number, AX-2210-T, which the assistant never connects to TF-4471-3.

None of those facts was hidden. Each sat in a system the assistant could query. What it lacked was the knowledge that three identifiers named one part, that a quarantine status and a missing certificate both mean "not usable," and that a -5 dash number may stand in for a -3. Better retrieval wouldn't have closed that gap, and neither would a larger model.

Aerospace supply chains carry more of these rules than most. Certification paperwork, export control, shelf-life materials and approved-supplier lists all decide whether a part on a shelf can go into an aircraft. The pressure on that supply chain is also unusually high. IATA puts the aircraft order backlog at over 18,000, and its June 2026 statement lists shortages of materials and spare parts among the problems disrupting airlines.

What Goes Into a Supply Chain Ontology: Materials, Parts, Warehouses, Shipments, Suppliers and Orders

A supply chain ontology is a shared model of the things the supply chain runs on, the relationships between them and the rules that decide what an answer means. It sits between the source systems and the agents that read them. Like any ontology in AI, it captures what a business means by its words, in a form software can read.

For the fitting, the model needs six kinds of things, each with the detail that tripped the assistant.

The relationships carry as much weight as the entities. A shipment carries a purchase order line, which is for a part, which a work order consumes, which feeds a shipset for a customer delivery. Rules sit on top. "Usable" in this model means on hand, released from quarantine, certified, within shelf life and not allocated elsewhere, and it has an owner, usually the materials manager, who signs that definition and answers for changes to it.

Which Aerospace Rules Does Ontology Have to Carry?

Aerospace supply chain management adds rules that most industries don't have, and each one changes whether stock counts. The ontology records them as rules with owners, so an agent applies them the same way every time.

How an Aerospace Manufacturer Is Turning Its Supply Chain Data Into an Ontology

The manufacturer's starting point looks a lot like the fitting. Parts, storage locations and shipments carried different identifiers in each of its systems, so its supply chain AI couldn't reliably say where a material was, what was still in transit or which orders a late part would hold up. The work follows the approach we use on every context ontology engagement, and the client's own supply chain specialists make the decisions at each step.

The reconciliation step takes the most judgment. A model can propose that AX-2210-T and TF-4471-3 are the same fitting from descriptions, dimensions and purchase history, but a materials specialist confirms it. Proposals that look right and aren't, such as two dash numbers with different finishes, are exactly the ones an agent would otherwise get wrong with confidence.

The questions decide the order of work. Identifiers that the specialists' questions touch get reconciled first, and the ontology grows outward from there rather than from a model of the whole enterprise. Units and statuses need the same care as identifiers. The problem is familiar from supply chain analytics on AWS, where two warehouses that count stock differently can quietly corrupt every number built on top of them.

From Ontology to Graph: How Correlations Help AI Answer Better

The ontology says what kinds of things exist and how they can relate. The graph holds the actual records, linked the way the ontology allows. That linked data is the supply chain knowledge graph, and it's what an agent walks through when a question spans more than one system.

Suppose the carrier reports that the shipment of 120 fittings will arrive six days late. The question the planner needs answered is which deliveries move. In the graph, the shipment points to the purchase order line it carries, the line points to TF-4471-3, the part points to the work orders that consume it, and the work orders point to the shipsets and customer deliveries they feed. The agent follows those links, checks usable stock and the -5 alternative along the way, and returns a short list of affected deliveries with the reason for each.

Correlation here means two things. It means linking records that name the same thing, such as the three identifiers for one fitting. It also means linking things that affect each other, such as a shipment and the work orders waiting on it. Without the first, the agent can't count. Without the second, it can count but can't trace consequences.

Not every question needs a graph. "How many TF-4471-3 are in bin 14C?" is a lookup. The graph earns its place on questions that cross systems and hops, which is most of what planners ask during a shortage.

Where the ontology and graph live is a separate choice. On AWS, we build on the Context Ontology Accelerator in the customer's own account, on Amazon Neptune, Amazon OpenSearch Serverless and models in Amazon Bedrock, and the same model can later move to AWS Context. Teams already standardized elsewhere can hold the same model in a Databricks ontology, Palantir or Microsoft Fabric IQ, and the modeling work doesn't change.

Which Questions Agents Can Answer Once the Context Exists

Once the ontology and graph are in place, the same model serves several agents, each answering the questions its users ask most. The questions below are the kind an aerospace supply chain team asks every week, and each one depends on links the fitting example needed.

Agents answer and propose. People still decide. An agent that finds the -5 alternative should put it in front of the planner with its constraints rather than reassign stock on its own, at least until the business has agreed what the agent may do without asking. Getting those limits right is most of what separates AI agents in production from pilots, and in aerospace the limits also cover who may see export-controlled and supplier-confidential data.

This is where AI for supply chain stops being a reporting layer and starts acting on exceptions. One manufacturer moved its supply chain from reactive to anticipating in a single engagement that shipped the data foundation, the models and the agents together, rather than as three separate projects.

Where to Start: One Product Line, One Set of Questions

Start narrow. Pick one product line or program, and write down 10 to 20 questions the team asks during shortages, each with an answer someone has already worked out by hand. "Do we have enough TF-4471-3 for next week's build?" is a good one, because the right answer depends on quarantine, certificates, allocations, transit and interchangeability all at once.

Bring in the warehousing, shipping and materials data for that product line, and name an owner for each definition the questions use, such as "usable," "in transit" and "interchangeable." Reconcile the identifiers those questions touch, model the ontology, link the graph and test. When the agent gets every question right, it's ready for production. The second product line goes faster, because most parts, locations and suppliers are shared.

That's how our context ontology services run. Forward-deployed engineers work alongside your supply chain specialists on the reconciliation and the definitions, while agents handle the repeatable profiling and matching.

A first release of 10 to 20 questions typically takes 8 to 12 weeks, and the production date goes into the statement of work. For manufacturers, we run it as context ontology for manufacturing, built for the places where shortages, certification and export control meet.