In my yesterday article, PLM 2026: Re-examining Engineering and Manufacturing Workflows for AI, I argued that AI forces us to revisit workflows themselves, not just add new features. But what exactly needs to change was still somewhat implicit.
When I wrote about rethinking workflows in engineering and manufacturing, I realized afterward that the phrase itself sounded both correct and incomplete at the same time. It pointed in the right direction, but it left too much room for interpretation. Some readers assumed I was talking about automation. Others thought I meant better tools, better interfaces, or faster approvals.
What I actually meant in “rethinking workflows” required more precision, and the reason became clear only after reflecting on why, despite all the recent progress in AI, everyday engineering and manufacturing work still feels surprisingly disconnected.
I wrote about AI features presented by PLM vendors – they are nice, but mostly focusing on two features – (1) natural language search; (2) data and document summary. Both are important, but doesn’t provide an answer how to change engineering and manufacturing processes to be empowered by new AI tech.
For decades, what we have called PLM workflows were designed for a very specific purpose: approval. Approval of documents, approval of structures, approval of releases. These workflows emerged in a document- and file-centric era, when PLM and PDM systems were built primarily as Systems of Record, enforcing a Single Source of Truth. Their main objectives were control, compliance, and clearly defined release gates.
And to be fair, they worked. They worked extremely well for the type of data those systems were designed to manage. Modern PDM and PLM platforms are mature, stable, and very good at what they were built for: managing controlled data, revisions, configurations, and formal releases. For that world, approval-centric workflows were not a mistake. They were the right solution to the right problem.
For those who use PLM for a long time, a workflow (or a process) such as Design approval, ECO, MCO, etc, is a sequence of steps, often presented as a data routing process. While they are absolutely needed, those approval workflows solved yesterday’s problem – approve the release.
The issue is that we are now asking those same workflows to support a very different kind of work.
Approval Was Never the Same Thing as Decision Making
The fundamental mismatch becomes obvious once we separate two concepts that are often treated as interchangeable: approvals and decisions.
An approval is an outcome. It confirms that something is acceptable, compliant, and ready to move forward. It is binary by nature. A decision, on the other hand, is a process. It involves exploration, discussion, comparison, argument, trade-offs, and uncertainty. Decisions are rarely clean or linear, and they are often revisited as conditions change.
Engineering and manufacturing are full of decisions that never fit neatly into approval workflows. Teams choose alternates when supply chains break. They balance cost against lead time under pressure. They accept temporary workarounds that quietly become permanent. These decisions are not captured as part of formal workflows because the workflows were never designed to host that kind of activity.
As a result, much of the real work happens outside PLM. Sourcing decisions are made in spreadsheets. Alternatives are debated in calls. Assumptions live in emails, chat messages, or someone’s memory. The approval workflow eventually validates the result, but it never sees the reasoning that led to it.
I wrote about this leakage before in Why Does PLM Leak to Excel?
The core issue hasn’t changed: PLM workflows validate outcomes, but they don’t allow participants to actually do the work of deciding inside the system. As a result, a significant amount of meaningful information remains invisible.
This limitation becomes critical once AI enters the picture.
Large language models and probabilistic AI systems cannot meaningfully participate in approval-only workflows. They don’t operate in a world of static snapshots and binary gates. They reason, compare, infer, and explore alternatives. When forced into approval-centric structures, AI can only summarize or suggest, because the workflow itself provides no place for reasoning to live.
That’s why workflows must be re-imagined.
From Moving Artifacts to Sharing Decisions
When people talk about agentic workflows, the conversation often jumps straight to autonomy, as if the goal were to replace humans with machines. That framing misses the point and creates unnecessary resistance.
What actually matters is much simpler and much more practical. Agentic workflows are about moving from linear approval pipelines to shared decision spaces where humans and tools participate together.
We are living in a moment where ideas about agents and agentic workflows are emerging rapidly, and they are not all the same. But they share a few important characteristics. Humans and tools work alongside each other. Agents propose, check, simulate, and compare. Humans accept, reject, adjust, and take responsibility. Decisions happen continuously rather than waiting for a single release gate at the end.
In this environment, workflows are no longer just about routing tasks for approval. They become active environments where work is actually done. Tools observe what is happening, participate in it, and help surface implications earlier. Humans remain in control, but they are no longer forced to carry all the context in their heads.
This shift does not reduce human responsibility. It increases it. But it also exposes a new problem that traditional PLM architectures were never designed to handle.
Agents Can Participate – But they Can’t Remember
Large language models are, by design, stateless. You send a request, you receive a response. Without an external memory layer, the system has no awareness of what happened before, what was decided, or why certain choices were made.
Agentic workflows dramatically increase the volume and frequency of decisions. Without memory, context disappears even faster than in traditional workflows. What looks like AI hallucination is often nothing more than missing decision context.
AI does not hallucinate because it is creative. It hallucinates because it fills gaps. When it doesn’t know why a part was chosen, which alternative was rejected, or whether a constraint was temporary or permanent, it guesses. Humans do the same thing, but we call it intuition.
The difference is not intelligence. The difference is access to memory.
This is the point where Product Memory stops being a nice idea and becomes a necessity.
Product Memory: Remembering Decisions
When I use the term Product Memory, I am not describing a new system or a new category of software. I am describing a missing capability.
Product Memory is the accumulated, connected record of product decisions and their associated data: what was chosen, why it was chosen, what alternatives existed, under which constraints, who accepted the decision, and when. It captures reasoning, not just results, and it connects decisions to the product structures they affect.
At the same time, Product Memory is intentionally selective. It does not try to store everything. It does not predict the future. It does not automate responsibility. Its role is to preserve enough context so that future work—human or AI—does not have to guess.
In this sense, Product Memory becomes the stabilizer of agentic workflows. It is what allows AI to reason instead of hallucinate, and what allows humans to build on past decisions instead of repeatedly verifying the same ground.
PLM Needs a Contextual Decision Layer
Seen through this lens, PLM’s strengths and limitations become clearer.
PLM remains essential. It manages structures, revisions, configurations, and control. None of that goes away. But agentic workflows require something that PLM was never designed to provide: continuous decision context rather than episodic approvals.
Product Memory becomes the connective tissue between human judgment and machine reasoning. It sits alongside traditional PLM artifacts, preserving the logic that led to them and allowing that logic to be reused, questioned, or revised over time.
This is not an attack on PLM. It is an evolution of how we think about it.
What is my conclusion?
In my view, the Product Memory becomes the missing element of PLM. PLM has always been good at remembering what happened. It knows which revision was released, which structure was approved, and which document is current. That capability is not going away, and it shouldn’t. Control, traceability, and compliance still matter.
What PLM was never designed to remember is why something happened. The changes, variants, discussions, tasks, comments, proposals, reviews, and many other data elements that captured during meetings, BOM variants, suppliers replacements, cost analysis, and many other activities.
As long as engineering and manufacturing workflows were dominated by approvals, this gap was tolerable. Decisions could live in conversations, meetings, and emails, because the system’s job started after the hard thinking was already done. The approval marked the end of reasoning, not the continuation of it.
AI and agentic workflows change that balance. When humans and AI agents are expected to participate together in day-to-day decision-making, the number of decisions increases, the pace accelerates, and the tolerance for ambiguity shrinks. In that environment, losing decision context is no longer just inefficient and it becomes dangerous. AI fills gaps aggressively. Humans compensate by rechecking everything. Trust erodes quietly.
Product Memory emerges here not as a feature, a module, or a new system of record, but as a foundational element of how modern PLM must evolve. It provides a place where decisions can be captured as they happen, connected to product structures, BOMs, and carried forward without freezing them in time. It allows reasoning to survive change instead of being erased by it.
In this sense, Product Memory does not replace workflows, but it gives them continuity. It does not automate responsibility—it preserves it. And it does not make AI autonomous—it makes AI accountable to past decisions and current constraints.
Approval workflows helped us control documents.
Agentic workflows help us create decisions.
Product Memory is what supports decision making and allows those decisions to remain useful tomorrow.
If PLM is going to support AI in real engineering and manufacturing work, it will not be by adding more intelligence on top of existing workflows. It will be by learning how to remember the entire decision process and use it as a context for future decision making and agent work.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative digital thread platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
