I came across two articles this week (thank you my industry collegues that shared). In my view, read both articles together, say something important about where enterprise software for engineering and manufacturing is heading. Neither of them mentions PLM. However, in my view, both these articles describe its future and are directly related to the most important decisions about how to integrate AI and human user experience .
The first is a piece on Modern Data 101 by Darpan Vyas about controlling AI agents with the data platform you already have. His core equation is simple: an agent is a model plus the harness around it. The model reasons. The harness decides whether that reasoning becomes a reliable outcome. Instructions, bounded tools, policy gates, sandboxes, evaluators, audit trails. His argument is that mature data platforms already own most of these controls, built originally for governance and compliance, and the open question is whether those controls sit inside the agent’s execution path or beside it as documentation nobody consults.
The second is Dave Yuan of Tidemark writing about what he calls the SaaSpocalypse – The Race to Own the Agentic Future. Public markets believe AI will kill vertical SaaS. Yuan argues the opposite: vertical SaaS control points with data, workflow, and account gravity have a head start in the race to become the System of Action, but only if they move at AI speed. His warning is blunt. Foundation models are moving up the stack, and tools like Claude Cowork are bidding to become the interface for all knowledge workers.
One article is about machine-side controls. The other is about who owns the customer. And between them sits a question neither one answers: when an agent does the work and a human must approve it, where does that human sit, and what do they see?
I think this question defines the next decade of PLM. Let me explain why.
The AI agent harness has a missing component: the human review surface
Vyas walks through a detailed example of an agent investigating refund requests. Eight steps: bind identity, resolve semantics, plan with bounded tools, evaluate policy before execution, meter the work, verify the result, gate the action, record the chain. It is a genuinely good piece of systems thinking, and I recommend reading it in full.
But look closely at step seven, gating the action. Issuing a credit requires human approval. And that is where the article stops. Approval happens, somehow, somewhere, and the pipeline continues.
The top comment on the article goes straight at this weakness. A reader asks whether the approval is bound to the exact payload, the specific customer list, the amounts, the policy version, or whether everything is just logged under the same correlation ID after the fact. In other words: what does the human actually approve, and how do we know they saw what they were approving?
This is a straightforward user experience question. Every list of agent harness components I have seen is machine-facing: prompts, tools, policies, evaluators. What about the surface where bounded machine autonomy meets human judgment? What the human sees, what evidence is attached, how the decision is structured, and what happens to that decision afterward.
For consumer refunds, maybe this is a Slack message with two buttons. For releasing an engineering change that affects a flight-critical assembly, it is a much more complex user experience.
Reviewing AI agent work becomes the engineer’s dominant work mode
Here is the shift I believe most PLM strategy discussions are missing. When agents take over the mechanical work, finding affected items, checking supplier status, validating structures, drafting change documentation, the engineer’s job does not disappear. It changes shape. The engineer stops living in authoring tools and starts living in a review layer.
The daily experience becomes: here is what the agents found, here is what they propose, here is the evidence, and here is the decision waiting for you. Approve, reject, or modify. The quality of engineering work becomes the quality of these decisions, and the quality of these decisions depends entirely on what the review surface shows.
We have seen this movie before in software development. Code review went from an occasional formality to the central act of programming. The pull request became the unit of work. Here is the evidence – “Github activity is surging. There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year.” — GitHub COO Kyle Daigle quote.
Entire platforms won or lost based on the quality of their review experience. Now, with coding agents, developers spend more time reviewing generated code than writing it, and the tools that own the review surface own the developer.
Engineering data and decisions are heading the same way.
The interesting question is what the pull request for product data looks like? Is it a BOM change? ECO? CAD design approval?
No engineering change decision lives in a single system
And here the analogy to code review breaks, in a way that matters.
A pull request lives in one repository. An engineering change does not live in one system. A decision about an ECO touches CAD geometry, the engineering BOM, the manufacturing BOM, the ERP item master, supplier commitments, compliance records, cost models, and inventory positions. This has always been the reality of product development, and it is precisely why the industry spent twenty years talking about digital thread.
Now apply that reality to the review surface. If the human approval gate is bound to a single system, the human is approving with a partial picture. They see the CAD change but not the supplier impact. They see the BOM delta but not the open purchase orders. An approval made on incomplete context is not a control. It is a rubber stamp with an audit trail.
So the control layer has a structural requirement that follows directly from the nature of engineering decisions: it must present context assembled across multiple systems, while policy enforcement stays wired into each system underneath. The review experience sits above the systems of record. It cannot belong to any one of them.
This is the point where both articles, read from my PLM twisted mind, become very interesting and inspiring to discuss.
The PLM workflow inbox cannot supervise AI agents
Traditional PLM software vendors will say they have had humans in the loop for decades. It is called workflows. And they are right, in the same way that a fax machine is a document sharing solution.
The PLM workflow inbox is a twenty-five-year-old pattern designed for routing documents between humans (3D Part, Change Order, etc). A task arrives, a human opens it, reads attached files, scans the form with attributes, clicks approve, and the task moves to the next human. It was built for a world where humans did the work and the system tracked the handoffs.
Agent supervision inverts this. The work arrives already done, with an evidence chain, and the human’s job is to evaluate whether the evidence supports the conclusion. That calls for a fundamentally different experience: the proposed change decomposed into discrete, checkable claims, each bound to the specific data that supports it, each verifiable independently. Not one monolithic approve button on a stack of attachments, but a structured verification of identity, properties, quantities, and structure, with the reasoning visible.
The workflow inbox also fails the cross-system test. It is scoped to the vault it lives in. The moment the decision context extends into ERP, supplier systems, or a second CAD environment, the inbox shows you a fraction of the truth and asks for your signature on all of it.
Data platforms have no user experience, and foundation model interfaces have no engineering semantics
The data platform community has the opposite problem. Everything Vyas describes, semantic layers, contracts, lineage, policy decision points, is real and valuable, and it is all headless. A data platform is infrastructure. It can enforce a policy, but it cannot present a decision. When the policy outcome is “require approval,” the platform has nothing to show the approver. Someone else has to build that surface, and whoever builds it will define how the human experiences the entire system.
Then there are the foundation model interfaces. Yuan is right that they are bidding to become the UI for knowledge work, and for horizontal tasks they may win. But an engineering change decision is not a horizontal task. It requires knowing what a revision is, what effectivity means, why a quantity mismatch between engineering and manufacturing BOMs might be intentional, and which of the forty fields on an item master actually matter for this decision. A general-purpose chat interface presenting an ECO for approval, without domain semantics underneath, is the rubber stamp problem again with better typography.
So we have three candidates for the most important surface in the agentic enterprise, and each is missing a piece. Legacy PLM has the process hooks but a document-era “forms” UX and single-system scope. Data platforms have the governance machinery and no user experience at all. Foundation models have the interface and the reach but no engineering semantics. Nobody owns the control layer yet.
Five requirements for an AI agent control layer
The control layer for AI agents is the user experience surface where humans review, approve, or reject agent-proposed work, assembling evidence across multiple systems, decomposing decisions into verifiable checks, and recording every decision with its reasoning.
If I try to write the requirements list for this layer, treating it as a product problem rather than a philosophy problem, I get to five things.
1. Evidence binding.
Every claim the agent makes must be attached to the specific data that supports it, at the version that was consulted. The approval must be bound to the exact payload, exactly as that commenter on Modern Data 101 demanded. If the affected item list changes between review and execution, the approval dies.
2. Structured decomposition.
A complex decision must be broken into discrete checks a human can actually evaluate. Is this the right part number? Are these properties complete? Does the quantity roll up correctly? Is the structure consistent across views? Each check independently answerable, with its own evidence, so the human applies judgment where judgment is needed instead of skimming a fifty-page packet.
3. Cross-system context assembly.
The layer must reach into CAD, BOM, ERP, and supplier data to compose the full picture of a decision, without requiring those systems to be replaced or migrated. Read deeply, act narrowly.
4. Graduated autonomy.
Not every decision needs a human. The layer must encode which classes of change proceed automatically, which need review, and which need multi-party approval, and this boundary must be adjustable as trust in the agents grows. The gate is a dial, not a wall.
5. Decision recording (I care about this one the most).
Every approval and rejection, with its full context, evidence, and stated reasoning, must be captured as a permanent record. Not for compliance, or not only for compliance. Because the accumulated history of decisions and their reasoning is what makes the next agent proposal better and the next human review faster. The control layer is not just where decisions happen. It is where the organization’s decision memory forms.
Readers of this blog will recognize where that last point goes – Product Memory. I have argued for the last year that the gap in enterprise systems is between data records and decision reasoning. We store what was decided and lose why. Digital thread connects the data. Something else has to explain it. In a world where agents propose and humans dispose, the “why” stops being a nice-to-have and becomes the operating system of the loop: capture what happened, review it with full context, and let the validated result flow onward, carrying its reasoning with it.
Will AI agents finally kill a single source of truth in PLM?
There is a deeper irony here for the PLM industry. We spent two decades pursuing a single source of truth, one system that holds everything, and the pursuit dramatically failed on both architecture and adoption for the last 20 years.
The agentic control layer is the final argument against SSOT. The whole design assumes multiple systems of record continue to exist, each governing its own domain, with agents working across them and humans supervising above them. The value does not come from consolidating the data into one database. It comes from assembling trusted context across databases at the moment of decision, and from remembering the decision afterward. Truth in this architecture is not a place. It is a process with evidence attached.
That reframing changes what PLM vendors should be building, what buyers should be evaluating, and honestly, what analysts should be asking about in briefings. The question is no longer “where does the data live and who controls this data.” It is “where do the decisions live, what do they see, and how do we preserve it so as not to repeat the same mistake twice.”
The System of Action for product development will be decided at the review layer
Come back to the SaaSpocalypse. Yuan’s advice to SaaS CEOs is to win the strategic product surfaces before native AI competitors integrate around your control point and become the System of Action themselves. He quotes a CEO saying every product surface must be the best micro harness for its job.
For engineering software, I am now convinced the strategic surface is the review layer. Whoever owns the place where humans supervise agent work on product data owns the trust relationship, the daily habit, and the accumulating decision memory that makes everything else smarter. CAD authoring is already commoditizing. Data storage certainly is. Model access is rented by everyone from the same three providers. The surface where judgment is exercised and recorded is the one thing in the stack that compounds.
Here is my main point in this article and it goes to all CAD and PLM developers – this surface does not exist as a product category yet. It will be assembled from pieces that do: governed data interfaces, semantic definitions of product structures, structured review mechanics, and memory of what was decided and why. Some vendors will try to bolt it onto a workflow engine. Some data platforms will try to grow a face. Some foundation models will try to fake the semantics. My bet is that it gets built by whoever takes the “engineering review” experience seriously as the product, rather than as a feature at the end of a pipeline.
Open questions on agent review for PLM practitioners and vendors
So here is what I want to know from people running engineering organizations and PLM programs. When you imagine agents doing real work on your CAD design, Bill of Materials, ECOs, procurement requests and other processes next year, where do you want to review that work? Will it go to your email? Spreadsheet? Workflow inbox? In a chat window? In something that does not exist yet? What would it need to show you before you would trust an approval enough to sign it?
And for PLM software colleagues and analyst friends: is anyone actually building the cross-system review layer, or are we all still demoing chatbots that do the work and send it to users in a way the Unix terminal command shell worked in the 1990s?
The harness engineering crowd figured out that the system around the model matters more than the model. I think the PLM world needs to figure out that the surface around humans matters just as much.
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.
