Thinking About BOM in the AI Era: Why BOM Becomes Context Engineering in Modern PLM

A few weeks ago, I participated in a webcast about the future of BOM management with Michael Finocchiaro, Patrick Hillberg Ph.D., Brion Carroll, Rob Ferrone Jim Brown, and Jonathan Scott.. It was one of those discussions where everyone came from slightly different angles, but the underlying tension was the same.

The BOMversation That Stayed With Me

After decades of PLM implementations, integrations, and debates, the Bill of Materials is still not a settled topic. That alone is interesting.

If something survives this long in engineering and manufacturing, it usually means it sits at the center of a real problem. The BOM is not controversial because it failed. It is controversial because it continues to carry more responsibility than it was originally designed for.

Shortly after the webcast, Jos published his article “The BOM revisited – what are the challenges?”, arguing that the BOM is far from dead, but that expectations around it must evolve. Around the same time, I wrote my own reflections in “Thoughts and Questions Ahead of the BOMversation: To BOM or Not to BOM” on Beyond PLM, trying to frame why the discomfort around BOM discussions keeps resurfacing. The conclusion I arrived at was simple: the BOM debate is really about how organizations manage product context over time.

Since then, I’ve been asked the same two questions repeatedly. How will AI impact BOM? And, maybe more importantly, how can BOM help organizations adopt AI successfully? The answer, I believe, sits at the intersection of both.

This raises a broader question about the future of BOM management and AI in product lifecycle management (PLM).

AI Is Moving Faster Than Our Processes

AI is changing everything, but not in the way enterprise software usually changes. Most technology transitions in engineering took years to materialize. CAD moved from drawing boards gradually. PDM adoption took decades. Even cloud PLM evolved slowly because organizations needed time to adapt their processes.

AI feels different.

The “ChatGPT moment” made it clear that cognitive assistance could suddenly become accessible to everyone. Tasks that previously required expertise or time could be accelerated by simply asking a question. But what follows is even more important. The recent “OpenClaw moment” demonstrated something new — AI systems that don’t just answer questions, but operate tools, navigate applications, and execute multi-step workflows.

We quietly crossed a boundary from AI that explains work to AI that participates in work.

And that shift exposes a fundamental problem. AI systems can only be as good as the context they operate within. Fast intelligence without structured context produces fast mistakes.

This is where the BOM conversation unexpectedly becomes relevant again.

From Prompt Engineering to Context Engineering

Over the last year, much of the conversation around AI focused on prompt engineering — how to ask better questions to get better results. That phase was necessary, but it is already becoming insufficient.

The real challenge is not the prompt. It is the environment surrounding the prompt.

Context Engineering is the practice of assembling the right information, constraints, relationships, and history so that AI systems — and humans — can make correct decisions. Context includes structured product data, relationships between parts, revision history, supplier constraints, engineering intent, and the decisions that led to the current state.

In simple terms, prompts tell AI what to do. Context tells AI what is safe and correct to do.

Once you look at AI this way, the role of product data changes. The question is no longer how to generate answers, but how to ensure the system understands the product reality it is operating in.

Applications Are Slow APIs

If we step back, product development workflows have evolved through several stages.

Initially, organizations passed files between people. Drawings, spreadsheets, PDFs, and emails moved from engineering to manufacturing to procurement. Knowledge traveled with documents, and much of it was lost along the way.

Later, we replaced file exchange with integrations. Systems started calling APIs. CAD connected to PDM, PDM synchronized with ERP, and workflows became more automated. This was a major improvement, but integrations still assumed that applications themselves were the primary actors.

Today, something new is emerging. Applications increasingly look like slow APIs — interfaces designed for humans rather than machines. AI agents do not need screens or menus. They need structured access to information and the ability to understand relationships between data.

This shifts the focus again. Instead of moving files or calling isolated APIs, organizations need to provide rich context where people and agents can operate together.

The center of gravity moves from applications to context.

What This Means for Complex Product Development

In complex product development, the BOM was never just a list of parts. It was always a compromise between multiple viewpoints.

Engineering sees structure and function. Manufacturing sees process and sequencing. Procurement sees suppliers and cost. Service sees maintenance and replacement. Each view evolves at a different speed, and change continuously propagates between them.

Over time, organizations accumulate decisions. Why a component was selected. Why an alternate was approved. Why a change was postponed. These decisions rarely live in a single system. They are scattered across emails, spreadsheets, meeting notes, and disconnected revisions.

AI does not eliminate this complexity. In many ways, it amplifies it. Agents can propose optimizations, detect risks, or automate updates — but only if they understand the full decision context. Without that context, automation becomes dangerous.

This is why the BOM becomes important again. Not as a static artifact, but as the place where product decisions converge.

BOM as AI-Ready Context

If BOM is to serve as context in the AI era, it needs to evolve beyond structure alone. An AI-ready BOM context typically includes a few essential characteristics: clear provenance showing where data originated and who changed it, a visible change narrative explaining why decisions were made, semantic meaning attached to parts and attributes, links connecting items to files, documents, and external systems, and access control that allows collaboration without losing governance.

When these elements exist together, the BOM stops being a report and becomes a working context for decision-making.

This is not a new requirement created by AI. AI simply exposes how necessary this structure has always been.

OpenBOM and the Idea of Context Fabric

From my perspective, the interesting role for modern systems is not to replace existing tools, but to connect them into a coherent context.

The vision we are pursuing with OpenBOM fits into this direction. The goal is not to make BOM another isolated application, but to provide a context fabric where product information from multiple sources — Excel, CAD systems, ERP, supplier data, and documents — can be brought together into a consistent structure. At the same time, people must remain part of the loop. Engineering and manufacturing decisions still require collaboration, review, and judgment.

Equally important is exposing this context through structured APIs so organizations can safely build automation and AI agents on top of it. Agents should operate on trusted context rather than reconstructing reality from disconnected files.

In that sense, the BOM becomes less about managing parts and more about managing understanding.

The BOM as Context Graph

If I had to visualize this shift, the diagram would be simple. On the left side, files moving between people. In the middle, applications connected through APIs. On the right side, a context layer where data, relationships, and decisions form a graph that both people and agents can use.

The BOM sits naturally at the center of that graph because it already connects product structure, change, cost, and supply chain decisions. The difference is that now this structure must be alive, connected, and accessible.

Conclusion: A Conversation About Where to Start

Looking back at the webcast discussion, what strikes me most is that nobody argued the BOM should disappear. The disagreement was about what role it should play next.

In the AI era, the BOM is not becoming less important. It is becoming more foundational. As AI moves from answering questions to participating in workflows, organizations need a reliable context that reflects how products actually evolve over time.

The companies that succeed with AI in engineering will not necessarily be the ones with the most advanced models. They will be the ones that understand their product context best and make it accessible to both people and machines.

The BOM, in that sense, is not dead. It is becoming the context that allows AI-driven processes to use the right data, at the right time, for the right decisions. And perhaps that is the role it was always meant to play.

If there is one thing that became clear over the past year, it is that building software has become dramatically easier. In 2026, teams can experiment with AI tools, agents, and automation faster than ever before. Prototypes appear quickly. Integrations are easier to assemble. The barrier to writing software is lower than at any point in the history of engineering systems.

But this speed creates a new risk.

It is now possible to build AI-driven workflows on top of the wrong foundations. When product data is fragmented, when change history is unclear, or when BOM structures do not reflect how decisions are actually made, AI simply accelerates confusion instead of improving outcomes. The technology works — but the context underneath it is not ready.

This is where strategic thinking matters more than tools.

If your organization is exploring how AI fits into engineering, BOM management, or digital thread initiatives, it is worth stepping back and asking a more fundamental question: what role should BOM and product structure play in your AI architecture? Where should context live? How should people and agents collaborate safely over time?

These are not purely technical questions. They are architectural and organizational decisions that shape how AI will work for years to come.

If you would like to discuss how to position BOM strategically in your AI implementation — where to start, what to avoid, and how to build the right foundation — we would be happy to have that conversation. You can schedule a call with our team to walk through your current setup and explore practical next steps.

AI makes it easy to build software. Getting the foundation right is what makes it sustainable.

Quick FAQ: BOM and AI

How does AI change BOM management?

AI shifts BOM from a static list of parts to a structured context used for decision-making. AI systems require accurate relationships, revision history, and product structure to automate engineering and supply chain workflows safely.

What is context engineering in PLM?

Context engineering is the practice of organizing product data, relationships, and change history so AI systems and people can make correct decisions. It goes beyond prompts and focuses on providing reliable product understanding.

Why is BOM important for AI-driven engineering?

BOM connects engineering, manufacturing, procurement, and service perspectives. This structured connection allows AI systems to operate on trusted data instead of disconnected files or assumptions.

Can AI replace BOM or PLM systems?

No. AI depends on structured product data. BOM and PLM systems provide governance, traceability, and context that AI needs to function correctly in engineering environments.

What makes a BOM AI-ready?

An AI-ready BOM includes clear relationships between parts, traceable changes, connected documents and systems, semantic attributes, and controlled access for collaboration.

What is the future role of BOM in digital thread initiatives?

The BOM increasingly acts as a central context layer within the digital thread, connecting product information across lifecycle stages and enabling both human and AI-driven processes.

More Frequently Asked Questions

Is BOM becoming less important because of AI?

No. The opposite is happening. AI increases the importance of structured product context. AI systems can generate answers quickly, but without reliable product structure, relationships, and history, those answers can easily become incorrect or unsafe. The BOM becomes more valuable because it provides a shared reference point for decisions across engineering, manufacturing, and supply chain workflows. AI does not replace the BOM — it increases the need for a trustworthy one.

Does AI eliminate the need for PLM or BOM management systems?

AI changes how systems are used, but it does not remove the need for them. Product development still requires traceability, governance, and collaboration between people. AI can assist with analysis, suggestions, or automation, but it still needs structured data and controlled processes underneath. In practice, AI shifts the role of PLM and BOM systems from document management toward context management.

What is the difference between prompt engineering and context engineering in product development?

Prompt engineering focuses on how instructions are written for AI. Context engineering focuses on what information surrounds those instructions. In engineering environments, the correctness of an outcome depends less on the wording of a prompt and more on whether the AI has access to the right product structure, revisions, constraints, and relationships. Context engineering ensures AI operates within the reality of the product, not just within language.

Why can’t AI simply read files and figure everything out?

In theory, AI can interpret unstructured data. In practice, product development decisions depend on relationships that are rarely explicit in files alone. A drawing does not explain why a part was replaced. A spreadsheet does not capture effectivity or approved alternates. Email discussions rarely contain final decisions. Without structured context, AI must guess — and guessing is risky in engineering and manufacturing environments.

Does this mean BOM becomes a database for AI?

Not exactly. The BOM is not valuable because it stores data, but because it organizes relationships between data. The value comes from connecting parts, revisions, suppliers, documents, and decisions into a coherent structure. AI systems benefit from this structure because it reduces ambiguity and allows automation to happen safely.

How should organizations prepare their BOM for AI-driven workflows?

The first step is not adopting AI tools. It is improving the quality of context. That usually means connecting data sources, making changes traceable, clarifying ownership of product information, and ensuring that different product views remain aligned. Organizations that already struggle with disconnected spreadsheets and unclear change history will see those problems amplified by AI rather than solved by it.

Will AI eventually replace engineers or product decision-making?

AI is more likely to change how decisions are made than who makes them. Engineering decisions involve trade-offs, responsibility, and experience that go beyond optimization. AI can help analyze options, detect inconsistencies, or automate repetitive tasks, but human judgment remains central. The goal is not autonomous product development, but better-informed collaboration between people and intelligent tools.

CONTACT OPENBOM TODAY to discuss your AI planning and how BOM context can help. 

Best, Oleg