Over the past several months I have been writing about a question that increasingly matters to engineering and manufacturing companies: what happens when AI can connect to product information, but the information needed to make a good decision does not exist in any single system?
Earlier this week, I came across the article by Francois Lamy, How MCP Turns Product Memory into Enterprise Intelligence and it resonates a lot with my thinking. Francois explores how PLM, the digital thread, Product Memory, and the Model Context Protocol combine to make accumulated product knowledge usable by AI. His central point is simple and important:
MCP does not create Product Memory. It activates it.
I appreciate Francois referencing my earlier article, What Is Product Memory?, and I agree with his distinction. A protocol does not create engineering decisions. It does not recover missing design rationale. It does not explain why a component was approved for one customer and rejected for another.
But the distinction raises the next question. In the discussion that followed his article, Francois and I converged on the same point: this next question is the harder one. Product memory is not created by protocols. It is created by decisions, relationships, and context accumulated over time. The challenge is not how to access it, but how to continuously capture it as products, processes, and organizations evolve.
So if MCP activates Product Memory, who builds the memory in the first place? And how does it continue to grow as people make decisions across engineering, manufacturing, procurement, quality, and service? This article is my attempt to answer that.
Access to product data is not understanding of a product
Much of the current enterprise AI discussion is about connectivity. Can an agent connect to PLM? Retrieve a BOM? Query ERP? Read requirements, change orders, supplier records?
These are useful capabilities. But access does not create the context a sound decision requires.
Imagine an AI agent recommending an alternative component. The component is mechanically compatible. The supplier is approved. The price is attractive and the part is available. From the perspective of each individual system, the recommendation looks correct.
Several questions remain unanswered. Does the alternative affect a customer-specific certification? Was a similar component rejected in an earlier design review? Did a previous version create a field reliability issue? Does a manufacturing process impose a constraint that never appears in the CAD model?
Each answer may exist somewhere: in a formal system, in a review discussion, in a supplier exchange, in an engineer’s notes. Some were never captured in reusable form at all. The problem is not that AI lacks access to data. The problem is that the connections between the data and the decisions are missing. As Francois puts it, more data without context simply produces a more convincing wrong answer.
The most important knowledge is created between systems
Here is the structural reason why no system of record solves this on its own.
Enterprise systems are very good at recording transactions inside their own boundaries. A revision is released. A purchase order is created. A change is approved. A supplier is qualified. Each system has an important job, and each should remain authoritative for the information it owns.
But the decisions that matter most are made across those boundaries. An engineer notices a replacement part could create a manufacturing problem. Procurement explains the preferred supplier cannot support the production schedule. A quality manager remembers a field issue with a related component. A service team identifies a maintenance constraint invisible during design.
The final decision depends on all of those perspectives together. And precisely because it crosses system boundaries, no single system of record has a natural place to hold it. The reasoning fragments into emails, meetings, spreadsheets, and application-specific records, and the organization reconstructs the same reasoning again the next time.
Product Memory is the connected context that prevents this loss. It includes the formal records, but it also preserves the relationships, decisions, evidence, exceptions, and rationale that make those records meaningful. This is why Product Memory cannot be a byproduct of any one authoritative system, however capable. It has to be built as its own layer, across systems, through everyday work.
Distributed authority. Connected memory. Governed action.
A concern I often hear is that building Product Memory means replacing existing systems or creating one giant product database. I think that is the wrong architecture.
Systems of record should remain authoritative for what they own. PLM for governed product structures and release processes. ERP for operational and purchasing information. Requirements, quality, and service systems for their domains.
Product Memory does not override that authority. It connects identities, relationships, decisions, and evidence across it. The distinction matters: authority determines which system controls a fact or an action. Context explains how that fact relates to the rest of the product lifecycle. An agent can retrieve an approved component from an authoritative system, but knowing whether that component is appropriate for this decision requires evidence from several systems and from prior human judgment.
So the architecture I see has three ideas: distributed authority, connected memory, governed action. Systems remain responsible for their domains. Product Memory connects the broader understanding. Governed interfaces, and this is where MCP fits, let people and AI access and act on that context appropriately.
Ontology is not Product Memory
One more distinction is worth making, because the two are easily confused.
An ontology describes the structure of the domain: what a part is, how it relates to configurations, which suppliers can provide it, which requirements apply, who is entitled to approve a change. This semantic structure is genuinely valuable for AI. It helps an agent understand which questions matter, where evidence might live, and which tools or MCP calls to use in which order.
But ontology describes how the organization understands its domain. Product Memory preserves what actually happened inside it: the alternative that was rejected, the exception that was granted, the field failure that made a supplier decision risky, the person who made the call and why. An organization can have an excellent ontology and almost no memory. Both matter. They are different layers.
How Product Memory gets built: the flywheel
If memory is not created by a protocol and not owned by any single system, where does it come from? And how is it continuously captured, rather than captured once and left to go stale? My answer: it grows when actual work produces durable, connected context. Product reviews are a good example.
Consider a BOM review involving engineering, procurement, manufacturing, and quality. The review reveals a component missing a supplier, an assembly with inconsistent revisions, a proposed alternative that introduces a customer-specific risk. The immediate goal is to resolve the issues. The longer-term opportunity is to preserve the connected evidence and the decision: what was found, which configuration was affected, what evidence was considered, what alternatives were discussed, who decided, and why.
The formal result flows back to PLM or ERP. The cross-system rationale remains as Product Memory. I describe this cycle as Capture, Review, Flow. Capture relevant information from different systems and connect it around the product and the decision at hand. Review it with the right people and, increasingly, with AI: find gaps, compare alternatives, record reasoning. Flow the resulting action back to the authoritative system while the relationships and rationale stay connected.
The next cycle starts with more context than the last one. Over time this becomes a Product Memory Flywheel: better connected information supports better reviews, better reviews produce better decisions, preserved decisions create richer context, and richer context gives both people and AI agents a stronger foundation. The same logic applies to human accountability. Keeping a person in the loop is not an approval button after an AI recommendation. It is giving the accountable person a risk-appropriate evidence package, and then preserving the decision and its rationale as part of the memory.
My conclusion
Francois is right to connect MCP with Product Memory, governance, and enterprise intelligence, and right that the competitive advantage in engineering AI will come from context architecture rather than model selection. Access to leading models will keep broadening. Decades of accumulated, connected, governed product knowledge cannot be downloaded.
That is exactly why the construction question deserves as much attention as the activation question. I am glad this is becoming a shared understanding rather than a solo argument. Product Memory is not created by a protocol, and it does not appear when a repository is renamed. It is built slowly and captured continuously, through everyday product work, when information, human judgment, and lifecycle decisions remain connected across the systems where work actually happens. That is what makes it hard. And that is what makes it valuable.
MCP can activate Product Memory. But before anything can be activated, somebody has to build it, and keep building it, one decision at a time.
This is one of the central questions I am exploring in my upcoming book, From CAD Files to Product Memory.
Just my thoughts.
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
