Continue sharing my thoughts after AU 2026 a few weeks ago. If you missed my previous articles about Autodesk University, please check them here –
AU 2026: The Platform Question Is No Longer APIs. It Is Context.
AU 2026 and the Autodesk Bet on Context for PLM
Autodesk used the idea of invisible PLM in its AU 2026 keynotes. I think it is worth taking seriously because it addresses a familiar problem: much of the organization needs the value of lifecycle management without becoming expert at navigating a PLM system.
A buyer needs to understand a shortage. An engineer needs to evaluate a substitute. A manager needs to know which change is waiting for attention. These people share a product situation, even when they enter it through different applications.
The agentic PLM demonstrations offered a different starting point for their work. An assistant assembled relevant information and helped prepare the next actions. That changes the experience of using PLM. It also makes the underlying controls more consequential.
A business problem becomes a shared workspace
On Day 1, the scenario began with a supplier warning about a motor shortage. The supply chain user brought the email into a workspace and invited an engineering manager to help resolve the issue. The assistant presented impact information and candidate alternatives.
The exchange between the two roles was an important part of the demonstration. Availability and lead time helped the buyer compare options, but an engineering judgment was still required. The engineer reviewed the proposed BOM, including additional hardware, and asked the assistant to draft a change order and assign tasks.
I recognize this pattern from years of PLM discussions. The information is usually spread across systems, while the actual coordination happens through email and meetings. Teams then spend additional time making the formal records reflect the decision they already made.
Bringing the situation, evidence, and proposed actions together can reduce that separation. It gives PLM a more direct role in the work people are trying to complete.
AU Keynote Day 2 made the reuse question more specific
The second keynote showed a new engineer working through tasks on another lawnmower design. The assistant identified an active change involving an end-of-life charging socket. The replacement search considered geometry and metadata, with a requirement to find an already released part. A candidate from another division was used to update the CAD model and BOM.
The scenario also connected a water-protection requirement with engineering work on the camera assembly. The engineering manager reviewed the related information, including gasket and sealant entries and the vendor.
Those details matter more than the convenience of a conversational interface. A similar-looking part is a candidate. Its release status, requirements, and suitability for the application determine whether it is a reasonable choice.
The demonstration showed how an assistant can help people reach that information quickly. It did not prove that the resulting assembly had passed physical validation. Reviewing a BOM and verifying product performance remain different activities.
The governed foundation remains
Autodesk’s Fusion Manage announcement is explicit about the scope. The agentic experience is an evolution of Fusion Manage, with capabilities still in development. The question about fragmented platform is still there too. How much of this data is Fusion (Datastay) database and how much of this is Manufacturing Data Model at APS is not clear.
Autodesk also says that product data, rules, and change history remain governed underneath the experience, with permissions, traceable workflows, and human approval where appropriate. That is a useful clarification. The assistant can make the system easier to use while the organization retains responsibilities for engineering decisions.
I would evaluate this direction through a practical question: can someone see exactly what an agent proposes to change, why it proposes the change, and what authority is needed to proceed?
Consider a replacement component. A review should make the affected revision and assemblies understandable. It should also make clear whether the change applies to future production, existing inventory, particular customer configurations, or products already in service. A convenient interface cannot resolve those distinctions by hiding them.
Human review has to fit the action
The phrase human in the loop can cover very different experiences. Approving a search result is different from approving a BOM change. Releasing an engineering change has another level of consequence.
An effective interface should let a reviewer inspect the relevant evidence at the moment it matters. If a person must reopen five systems to understand an assistant’s proposal, much of the coordination benefit disappears. If the interface compresses everything into a confident summary, the person may approve without seeing a significant exception.
This is why I have been writing about human review as a PLM interface problem. The design of the review determines whether a person can exercise the responsibility the organization assigns to them.
A useful assistant should also stop when the evidence is incomplete. An unverified supplier commitment or a missing qualification record belongs in the decision, rather than disappearing during summarization.
Invisible administration can expose more decisions
There is an organizational opportunity here. When it becomes easier to bring people into a product situation, purchasing, quality, and service can contribute earlier. Their knowledge can affect an engineering decision before it becomes a released record.
That participation can help preserve why the decision happened. A substitution accepted for a temporary shortage should remain identifiable as a temporary response. Otherwise, a future team may reuse it as if it were a permanent design preference.
At the same time, faster preparation can move the bottleneck. If an agent drafts ten changes while the approval process can handle two, the review queue grows. Teams should examine the time to reach a sound decision, the time to release it, and the amount of downstream rework. Those measures reveal whether the new experience improves the whole process.
Companies will start from different places
A smaller manufacturer may use this kind of experience to establish consistent lifecycle practices without a large administrative project. An enterprise with an existing PLM platform will have a different question: can the assistant work across its established systems while respecting their authority?
The same conversational experience can conceal very different integration and governance requirements. I would resist treating all of these companies as one PLM market.
The AU demonstrations made a credible case for bringing lifecycle work closer to the problem people need to solve. The next test is whether that convenience holds up during exceptions, conflicting data, and changes that affect delivered products. Invisible PLM will earn its value when people spend less effort operating the software and can still see enough to make an accountable engineering decision.
Just my thoughts…
Best, Oleg
Disclosure: I am co-founder and CEO of OpenBOM. My perspective on product data, collaboration, and AI is informed by that work.
