Over the past few months, the conversation about AI in engineering has shifted. A year ago, the question was which copilot to embed in which tool. Today the question is who will build the complete AI engineering environment: the layer around the model that decides what an agent knows, what it can touch, and what it is allowed to do.
Dr. Dirk Alexander Molitor put it sharply in a recent LinkedIn post: the biggest race in engineering is only just starting, and the prize is the Engineering Harness. He picked up the question from Andreas Haselsteiner, and the software analogy behind it matters. Claude Code, Codex, and Cursor showed that a model on its own is not a product. What made these tools useful is everything wrapped around the model: context, memory, skills, workflows, tools, MCP connections, guardrails, and evaluation. Dirk’s observation is that engineering does not have this layer yet, and that most of the knowledge such a layer would need still lives in engineers’ heads, in process documents, and in tool configurations.
Michael Finocchiaro asked a complementary question in his post: who actually buys the different kinds of AI? His framing separates Engineering AI, Physics AI, Industrial AI, and Physical AI, and his cleanest discriminator is where the feedback loop closes. Behind each label sit different users, budgets, feedback loops, and business outcomes.
So we have two questions on the table. Who will build the Engineering Harness? And who will buy the different forms of engineering and industrial AI? I want to add a third, because I think it sits underneath both: what data foundation will all of these AI systems actually operate on?
Before an AI can design, simulate, source, manufacture, validate, or change a product, it needs to know what product it is working with. That sounds obvious. In most engineering organizations today it is not solved.
The Harness Is What Turns a Model Into an Engineering Worker
Earlier this year I wrote on Beyond PLM about AI harnesses for PLM and manufacturing and why the harness often matters more than the model. The example that stuck with me was a benchmark in which the same model, same weights, produced very different results depending on the environment it ran in. Models are converging in capability. The systems around them are diverging, and that divergence is where the value is being created.
The progression is easy to describe. A model provides intelligence. A copilot puts that intelligence next to a person inside a tool. An agent adds goals and the ability to act. A harness surrounds the agent with everything it needs to act well: context about the task, memory across sessions, tools it can operate, permissions that bound what it may do, workflows it participates in, policies it must respect, evaluation that checks its work, and connections to the systems where engineering actually happens.
In engineering and manufacturing, this progression matters more than in most domains, because a plausible answer is not enough. An agent that proposes a substitute part needs to know which revision is released, which supplier is approved, which requirement constrains the choice, and which manufacturing BOM will be affected. Get one of those wrong and the plausible answer becomes a wrong purchase order, a scrapped batch, or a field failure.
The harness supplies that context to the agent. Which raises the question the rest of this article is about: where does the context come from?
Software Has a Repository. Engineering Has a Pile of Files
Coding agents have an advantage that is easy to overlook. Software already has a coherent, machine-readable representation of the product it works on. Code lives in a repository. Dependencies are declared. Tests describe expected behavior. Commits and branches record history and intent. Documentation sits next to the code it describes. An agent dropped into a repository can traverse this environment and reconstruct most of what it needs to know before it changes a single line.
Physical products do not have that. The definition of a product is spread across MCAD and ECAD systems, BOMs in several tools, requirements in another, drawings and specifications as PDFs, spreadsheets everywhere, PLM or PDM for some of it, ERP for another part, simulation models, supplier data, procurement records, quality records, and a great deal of email.
So what is the engineering equivalent of the software repository? It is not CAD; CAD describes geometry, not the product. It is not PLM; PLM typically holds a subset of the definition and a set of documents. It is not ERP; ERP knows what was bought and built, not why. And it is certainly not a folder containing all the files. The product exists across all of these systems and in the relationships between them, and those relationships are exactly what none of them captures.
This is why I think the first challenge of the Engineering Harness is not orchestrating agents. It is establishing the product context those agents need in order to understand what they are working on.
Four Types of AI Still Reason About One Physical Product
Michael’s taxonomy is useful because it separates markets that are usually lumped together. Engineering AI creates and changes products. Physics AI predicts and evaluates physical behavior. Industrial AI helps manufacture, operate, maintain, and optimize products and processes. Physical AI interacts with the physical world through machines and autonomous systems. Each has different users, different economic buyers, different applications, and often a different technology stack, and Michael’s point about where the feedback loop closes explains why the buying motions differ so much.
Underneath the four, though, there is a common denominator that gets too little attention. They all reason about different aspects of the same physical product.
Follow one change through the chain. An engineer modifies a bracket to fix a clearance problem. Simulation needs the new geometry and the configuration it belongs to. Manufacturing engineering needs to know whether the fixture, the routing, and the work instructions still apply. Procurement needs to know whether the supplier can make the revised part and at what price. Costing needs updated quantities and prices. Later, service and operations need to know which units in the field carry the old bracket and which carry the new one.
If Engineering AI, Physics AI, Industrial AI, and Physical AI each hold their own private picture of that bracket, none of them can answer the questions that cross the boundary between them. Shared product context is what makes the chain work. And we have seen this movie before.
We Are About to Recreate the File-Based Engineering World, Only Faster
Think about how engineering organizations traditionally operated. Design created CAD files and drawings. Simulation received geometry and built its own models. Manufacturing engineering received drawings and BOM spreadsheets. Planning created another representation. Procurement received spreadsheets and specifications. Suppliers received packages of PDFs, CAD exports, spreadsheets, and emails.
Every discipline needed specialized tools, and that was never the problem. The problem was the handoff. Every handoff introduced uncertainty. Which version is this? Has engineering changed it since? Does the simulation correspond to the current geometry? Is manufacturing building the configuration engineering released? Is purchasing sourcing the part engineering actually specified? Much of the history of PDM, PLM, configuration management, BOM management, and digital thread initiatives is a thirty-year attempt to answer those questions reliably.
Now look at the emerging AI architecture. Engineering AI, Physics AI, Industrial AI, Supply Chain AI, Physical AI. Each is developing its own specialized models, its own agents, its own representations, and its own context. Read that list again and it describes the old engineering world exactly, except that instead of disconnected applications exchanging files, we have disconnected AI systems exchanging incomplete context.
The consequences are amplified because AI operates at machine speed. An agent can analyze thousands of components, generate alternatives, modify configurations, identify suppliers, or draft a manufacturing plan far faster than people ever exchanged spreadsheets. If the context it received was stale or partial, the error propagates at the same speed. Reliable shared context becomes more important as agents get faster, not less.
This leads me to a principle I keep coming back to: don’t pass context, preserve it. The answer is not to make every AI reconstruct product context from whatever files it happens to receive. The answer is to preserve product context independently of the AI systems consuming it. Models can be specialized. Agents can be specialized. Applications can be specialized. Product identity, structure, configuration, relationships, revisions, and history must persist across all of them.
The Missing Layer Sits Between Product Data and the Harness
It helps to separate four things that are usually blurred together.
Product data is the raw material: items, BOMs, CAD files, drawings, requirements, suppliers, documents, costs. Every company has this, usually in abundance and usually scattered.
Product context is the set of relationships between those objects. Which CAD file describes this item? Which requirement applies to this subsystem? Where is this component used? Which supplier provides it, and under which part number? Which BOM represents the manufacturing configuration, and how does it derive from the engineering structure? Context is what turns a collection of data into a description of a product.
Product memory adds history and time. What changed? Why? Which revision was released, and when? What decisions were made, and by whom? What was approved, what was rejected, and what was tried before? This is the layer I have been writing about all year: Product Memory is a persistent, connected, and explainable layer of product context that captures not only the data but the relationships, decisions, rationale, and history that explain how a product evolved. It is not another database and it is not a new name for PLM. It is the part of the product record that PLM never modeled.
The Engineering Harness then uses product context and product memory together with models, agents, tools, skills, workflows, policies, and external applications to perform work.
Written as a stack it reads: Product Data, then Product Context, then Product Memory, then Engineering Harness. The labels matter less than the point behind them. AI does not merely need engineering data. It needs engineering data with identity, relationships, state, and history attached. Take any one of those away and the agent is back to guessing.
RAG Reads the Files. It Does Not Understand the Product
The obvious first move for most organizations is to connect an LLM to engineering files and enterprise documents using retrieval-augmented generation. Point the model at the CAD vault, the shared drive, the PLM document store, and the email archive, and let it retrieve whatever looks relevant. I have watched several companies do exactly this, and it is useful. Engineers find things faster. Summaries of long specifications appear in seconds. Nobody should dismiss it.
But useful is not the same as sufficient. Consider what each retrieved artifact actually knows. The CAD file describes geometry. The spreadsheet contains cost. ERP knows a supplier. PLM holds a revision. The drawing carries manufacturing information. An email might explain why an engineer made a decision. Retrieving all six puts six fragments in front of the model. It does not tell the model that they describe the same part, that the drawing is one revision behind the CAD, or that the supplier in ERP was replaced after the email was written.
The distinction is simple to state. Document retrieval asks: what information can I find? Product context asks: how does this information relate to this product? The first question is answered by search. The second is answered only by relationships that somebody, or something, has already established and maintained.
Engineering agents ultimately need to traverse relationships, not merely retrieve documents. Retrieval gets them to the neighborhood. Context tells them which house they are in.
An Engineering Agent Has to Answer Thirteen Questions Before It Can Act
Let me make the problem concrete. Give an agent a modest task: evaluate whether a proposed change to a subassembly can be released this week. Before it can offer an opinion worth reading, it has to establish a set of facts.
It starts with identity and structure. What exactly is this product? What is its current configuration? Which components belong to this assembly? Which CAD files describe them? Which revision is currently released, and what changed since the previous one?
Then it needs the relationships around the part. Where else is this component used? What requirements apply to it? Who supplies it? What alternatives and substitutes exist, and are any of them approved? What does it cost, and at which quantity?
Finally it needs the downstream picture. Which manufacturing BOM derives from this engineering BOM? What downstream processes, orders, fixtures, or work instructions are affected by the proposed change?
An LLM can read files that contain pieces of these answers, and with enough retrieval it may assemble a plausible reconstruction. But every one of those thirteen questions is a question about a relationship, and reconstruction is expensive, slow, and unreliable when the underlying files disagree. An Engineering Harness needs a foundation that explicitly maintains those relationships so the agent can look them up rather than infer them each time. That is the difference between an assistant that talks about the product and an agent that can be trusted to act on it.
The Foundation Is a Product Context Graph, Not Another Vault
If the harness needs relationships, the data foundation underneath it cannot be another document repository or file vault. Vaults store artifacts. They are good at versioning a file and bad at explaining what the file is connected to. A modern engineering data foundation needs to represent the product as a connected network of objects and relationships.
Picture a requirement linked to the item that satisfies it, the item sitting in one or more BOMs, each BOM position linked to the CAD that defines the geometry, the item carrying revisions, each revision tied to the change that produced it, the item linked to the suppliers who can make it, the supplier linked to purchase orders, and the engineering BOM linked to the manufacturing BOM derived from it. Requirement, item, BOM, CAD, revision, change, supplier, purchase order, manufacturing BOM: every one of these is a node, and the edges between them are the product context.
The graph grows as engineering and manufacturing activity generates new information. A design review adds decisions. A quality escape adds a link between a lot, a supplier, and a revision. A cost roll-up adds prices at quantities. Nothing has to be re-entered because the connections are created as a byproduct of the work itself.
This gives AI something fundamentally different from a pile of files: a navigable, machine-readable context model of the product. And this is where reasoning becomes interesting. Instead of asking an agent to repeatedly reconstruct relationships from documents, the relationships themselves become part of the context available for reasoning. The agent traverses the graph, reads the history attached to each node, and spends its intelligence on the judgment call rather than on figuring out which revision it is looking at.
OpenBOM’s Job Is the Foundation Under the Harness, Not the Harness Itself
This is where I want to be precise about where OpenBOM fits, because it would be easy to overclaim. We are not trying to own the Engineering Harness. Models will come from multiple providers and will keep changing. Engineering agents will be specialized, and many of them will be built by companies that know simulation, or procurement, or shop-floor operations far better than we do. CAD, CAE, requirements, ERP, MES, QMS, and the rest of the engineering stack will continue to exist and will continue to be authoritative for what they own.
What we see as OpenBOM’s role is narrower and, I think, more durable: to provide the persistent product-data and context foundation underneath the harness.
That role maps directly onto what OpenBOM already does today. Items carry persistent identity across every BOM they appear in. Multi-level and multi-view product structures connect engineering, manufacturing, and purchasing views of the same product. CAD integrations keep the link between an item and the design that defines it. Documents, revisions, and lifecycle states are attached to the objects they describe rather than filed beside them. Change management records what changed and why. Suppliers, sourcing, inventory, and procurement connect the product structure to what is actually bought and built, and ERP integrations carry that across the enterprise boundary. All of it runs on a graph data model we chose from the beginning because the relationships were always the point. And the REST API and the MCP support we introduced for AI agents expose that graph to whatever harness a company chooses to run on top of it.
On the AI side, the first two products of our Product Memory Platform are in customers’ hands: CAD File Agent captures product structure from SOLIDWORKS files as engineers work, and BOM Review reasons over a BOM to find what is missing, inconsistent, or risky before release. The Product Memory layer that preserves decisions and rationale on top of the graph is the direction we are building toward, and I want to be honest that parts of it are roadmap rather than shipped.
The important point is not that OpenBOM stores all the information. It does not, and it should not. It is that OpenBOM connects the information and preserves the relationships, so that every agent above it starts from the same understanding of the product.
Nobody Has to Own the Whole Harness, but Somebody Has to Own the Context
This brings me back to Dirk’s question: who will own the Engineering Harness? Dirk lays out the contenders well. The AI labs have deep experience building agent environments and shallow product-development depth. The engineering software vendors have the domain depth and are only beginning to build agent environments. Both are racing.
I want to offer a slightly different hypothesis. Perhaps nobody needs to own the entire thing. Engineering environments are too heterogeneous for a single vendor to supply the models, the agents, the harness, the context, and the systems of record all at once, and every attempt in PLM history to own the whole stack has ended with customers routing around it.
The architecture I expect to emerge is layered, and different companies will supply different layers.