The Engineering Harness Debate: Context Is Where Engineering AI Gets Specific

Last Friday, I published Everyone Wants to Build the Engineering Harness. But What Will It Run On?. My argument was simple. The quality of engineering AI will depend less on the model and more on the product context the agents can reach. Passing fragments of files to an agent does not solve the silo problem. It only speeds the silo problem up to machine speed.

The comments to the LinkedIn post turned out to be better than the article. I appreciate everyone who shared their perspective and ideas. Practitioners, architects, researchers, and a few friendly skeptics pushed the idea in directions I want to answer properly, not in a reply box. This article is that answer.

The comments showed something I did not expect. Almost everyone agreed on where product context should live. The real debate was about what that context must contain before an agent can trust it. That debate is the subject of this article.

The industry already agrees that context belongs above the systems of record

Brion Carroll argued that the context layer has to exist above individual applications, as a governed product knowledge graph connecting engineering, manufacturing, supply chain, quality, and service. Bernd Augustin made the same point from a systems architecture angle: collaboration across tools and agents needs shared semantics, and those semantics should live above any single tool. Martin Eigner framed it as the Extended Digital Thread, a semantic backbone across ALM, PLM, ERP, and other enterprise systems. Patrick Kübler added a practical observation from the machine builders he works with: hardly any of them run PLM end to end, so the context layer cannot assume the context already exists somewhere.

I agree with all of them. No single system owns the full product reality, and none will. So the question is not whether a context layer sits above the systems of record. The question is what it has to hold.

Configuration is part of the context, not a separate layer beneath it

Frédéric Zeller raised the sharpest challenge in the thread. A stored product structure, he wrote, is a superset. The valid structure for a specific serial number, date, option set, or revision rule is computed by applying effectivity, interchangeability, and lifecycle rules. If unresolved data reaches an agent, the agent will traverse relationships that are individually true but belong to different configurations. That is the RAG fragment problem again, one level up.

He is right about the risk. I disagree that it requires a different architecture. In principle, configuration does not change anything about how product memory works. Product memory preserves the context that exists in the product’s reality. When a company manages configurations, through effectivity rules, option logic, or revision rules, that configuration context is part of product memory. Every relationship an agent traverses has to carry the scope where it is valid. When a product has no managed configurations, there is nothing to resolve, and forcing a configuration layer onto it would add ceremony without adding meaning.

Frédéric also asked who arbitrates when the context graph and the system of record disagree. My answer follows the principle I have been writing about for months: distributed authority, connected context, governed action. Systems of record stay authoritative for what they own. A configuration solver that lives in an ERP or a variant engine keeps doing its job there. Product memory does not overrule it and does not try to replace it. When the two disagree, the disagreement itself is context worth preserving and surfacing, because a silent reconciliation is exactly how bad decisions get made at machine speed.

The most valuable relationships are often the ones nobody created

Patrick gave an example that I keep thinking about. There are two part numbers with exactly the same geometry. The only difference is the surface roughness called out on the drawings. No system knows the two parts belong together. You need a geometry comparison to see that they are the same part, and you need the drawing to understand why there are two. Only then can someone decide whether to consolidate on the tighter spec or deliberately choose one before creating a third.

This is an important extension of the idea. Preserving relationships assumes someone created them. In real engineering organizations, many of the most valuable relationships were never recorded by anyone. They live in geometry, in drawings, in purchasing history, and in the heads of engineers who have since moved on. Product memory has to do both jobs: discover relationships that exist in the data but were never made explicit, and then preserve them as a byproduct of daily work instead of a separate documentation project that nobody finishes.

Agents will be replaced; the memory beneath them must not be

Ilan Madjar pushed back on my stack diagram. In practical system design, he argued, the harness is the agent’s operational environment (tools, guardrails, context injection), so separating the two into layers feels artificial.

At runtime, he is correct. Harness and agent operate as one system. But the reason I draw the context layer separately has nothing to do with runtime. It has to do with lifespan. The agents and harnesses we build in 2026 will likely be replaced within two or three years. Models change, frameworks change, vendors change. The product knowledge beneath them has to survive every one of those replacements. A company that fuses its product context into a specific agent runtime will rebuild that context every time the runtime changes. So the separation is about ownership and lifecycle, not about how the software executes.

A semantic layer you cannot take with you is just another silo

Martin Eigner made two points I want to highlight. First, product identity, configurations, revisions, and change history have been core PLM concerns for decades. What remains unsolved is preserving their meaning across system boundaries and capturing the reasoning behind decisions. I fully agree. Product memory is not a claim that PLM got the fundamentals wrong. It is a claim that the fundamentals stop at the boundary of each system, and meaning is lost at every crossing.

Second, he wrote that the manufacturing company must keep sovereignty over its product knowledge, and that openness must extend to the semantic layer, or we will build a new form of vendor lock-in. This is the most important governance question in the whole discussion. A context graph that only one vendor can read is simply a bigger silo. Bernd’s call for a shared, explicit ontology points the same way: the knowledge engineers carry implicitly has to become explicit, agreed upon, and portable.

Dirk Alexander Molitor added a forward-looking twist. He expects product data to become code, compilable and machine-readable, and many of today’s engineering files to disappear within a decade. If he is right, and I think he is partly right, the need for preserved context only grows. Machine-readable fragments without context are still fragments. They are just easier to misread quickly.

Memory becomes engineering-specific exactly where generic tools break

Benedict Smith took the skeptical side. Memory, he argued, is not engineering-specific, and software as a category is disappearing. His analogy was the supermarket: you never see a promotional stand for milk or flour, because commodities do not need them.

I like that analogy, and here is my answer. One of our customers designs and manufactures shelves for supermarkets. People buying milk never think about the shelves. But someone still has to design those shelves, manufacture them, maintain them, and replace them, with the right variant for the right store and the right revision for the right order.

This is where generic memory falls short. Generic memory can remember a conversation. It cannot tell you that two parts are interchangeable in one configuration and not in another. It cannot tell you that a relationship is valid only after a certain effectivity date, or that two part numbers are the same geometry separated by a surface finish. Martijn Dullaart has written an entire book on part re-identification and interchangeability because those rules are hard, consequential, and specific to engineering. Frédéric’s configuration challenge and Patrick’s geometry example make the same point. The engineering specificity of product memory is not a marketing position. It sits exactly at the places where generic tools produce confident wrong answers.

Nobody will buy an Engineering Harness

Martijn made the point that should end every AI discussion in our industry. You do not buy engineering AI. You buy efficiency, quality, and shorter cycle times. Berkant Aydemir described the same idea from the business side, with work focused on connecting context to the KPIs that measure outcomes.

That is the test I want to apply to everything in this debate. The harness is judged by what it changes in engineering and manufacturing results. Models will improve on their own schedule. Agents will be rebuilt. The part that compounds over time is the product memory underneath them: the preserved context, the discovered relationships, the configuration scope, and the reasoning behind decisions. A company that starts building that memory now will get better results from every agent generation that follows. A company that waits will keep feeding fragments to increasingly capable models and wonder why the answers do not improve.

This is how we approach harness development at OpenBOM. In a recent article on launch readiness and build blockers, I introduced Launch Master, which we are currently delivering as a service to our first customers. The agent is not the interesting part. The interesting part is the Launch Master delivery model it reasons over: the connected context of everything a product launch depends on. Without that context, a launch agent is a checklist with a chat interface. With it, the agent can explain why a build is at risk and what decision would unblock it. That is the difference between an agent and a harness running on product memory, and it is why we start with the context model before we build the agent.

What is next?

Thank you to everyone who commented. This thread did what good industry discussions should do: it found the hard parts. I will keep writing about product memory as the context foundation for engineering AI, and I would like to hear where you think this vision is still missing something.

If you want to see how product data and relationships can be captured and connected in a modern cloud platform, register for free to OpenBOM.

Best, Oleg