I’m continuing to share my thoughts following Autodesk AU 2026 last month. In this new series of articles I will share my thoughts about Autodesk Fusion and PLM.
Autodesk put Agentic PLM near the center of its Fusion strategy at AU 2026. The message was ambitious: redefine how companies work with PLM. Having listened to the Fusion strategy session and the PLM Summit keynote, I think the interesting part is the proposed change in where lifecycle work begins.
A supplier email becomes the starting point. A product manager brings the problem into a canvas, examines the affected product information, and invites an engineer. The team works through the consequences and can initiate a change request from the same environment. Autodesk Assistant helps assemble the information and prepare the next steps.
I have already written about Autodesk’s emphasis on context and the engineering controls behind invisible PLM. These two additional sessions gave me a more specific question. Can PLM become a useful place to work through a product problem before everyone knows what the formal process should be?
Starting with the product problem
In my experience, PLM projects often begin with a discussion about the system. What workspaces do we need? Which fields are mandatory? How should the approval workflow operate? These are legitimate questions. They can also consume considerable attention before a broader group of people experiences any value.
The approach presented at the Summit begins with something a team already needs to resolve. A supplier changes a price. An engineer identifies a component problem. A project manager needs to understand the consequences for a delivery. The work starts with that situation, and the participants bring structure to it as the investigation develops.
This could change the adoption conversation. A buyer can participate because a supplier problem needs an answer. An engineer can contribute because a proposed substitute affects the design. Their entry point is recognizable work. The lifecycle system has an opportunity to capture the relationship between those contributions as it helps the team proceed.
I would evaluate this idea through a small but consequential measure: how much useful work can a new participant complete before needing someone to explain the PLM implementation?
What the canvas adds
The canvas was central to the demonstration. It brought a supplier message, specifications, product information, and people into a shared working environment. The Summit also showed an explicit distinction between this collaborative space and the formal lifecycle records underneath it.
That distinction matters. Early investigation contains questions, incomplete evidence, and options that may never become an approved change. An engineer might suggest an alternative and later reject it because of a mounting constraint. Purchasing might clarify that an attractive lead time applies to a different quantity. Those exchanges help explain the eventual decision.
A canvas can give this developing work a place to start and explore. Its value depends on whether the relationships remain useful as the discussion grows. Can someone see which specification supports a proposal? Can a new colleague understand what has already been considered? Can the team return a month later and recover why it chose one option?
These are also product memory questions. The approved record tells us what the organization accepted. The surrounding evidence helps the next team understand the circumstances in which it was accepted. Connecting the two could make lifecycle history much more useful for future engineering work.
The Assistant and the governed record
Autodesk Assistant supplies a natural way to interact with the information and request work. Across the sessions, assistance extended from understanding product information to preparing changes and coordinating tasks. The canvas supplies the shared working context in which people can examine that assistance.
I would keep a clear distinction between an assistant’s suggestion, a person’s engineering decision, and a completed lifecycle action. A proposed replacement can remain under investigation. An accepted replacement can still require a controlled change and release. A useful experience should make these transitions understandable to the participants.
Autodesk’s Agentic PLM announcement describes the coming experience as an evolution of Fusion Manage. Product records, rules, and change history remain governed underneath it, with permissions and human approval where appropriate. The announcement labels these capabilities as in development. However, we need to understand deeper what does it mean for the data foundation (I will come to this in my next article)
Separately, Autodesk has made Assistant generally available in Fusion. These are different availability statements. The agentic lifecycle scenarios should be assessed as previews of the proposed direction.
Letting structure grow with the work
One of the more interesting ideas in the Summit was introducing process as a project’s needs mature. A team could start by investigating a problem together and later introduce the appropriate lifecycle structure.
That proposition is an interesting shift. A small manufacturer may need a practical way to begin managing changes consistently. An established organization may want to involve more people in a process it already governs. Both can benefit from an easier starting point, although the authority and approval requirements will differ.
The difficult part is preserving the work as that structure develops. When an informal investigation becomes a change request, I want the supporting evidence to remain connected. When a project adopts stricter governance, earlier decisions should retain their meaning. The cost of adoption can fall only if the team avoids having to reconstruct its work for the formal system later.
The foundation beneath the experience
The presentations made the working experience easier to visualize than the complete path connecting its engineering sources. Autodesk Fusion BOM, Fusion Manage, and Autodesk Vault bring three different data foundations into the strategy. Customers can also have engineering information outside these products.
A person investigating a supplier issue needs to know whether the assistant is examining the current design, a released configuration, or an imported representation. That distinction affects the decision regardless of how convenient the canvas becomes. The relationship to the engineering source therefore belongs in the experience itself.
This is where I see the next chapter of Autodesk’s strategy. The canvas offers a way to make lifecycle work easier to begin. The connected data foundation must make it dependable as the work progresses. This question is still to be answered.
What is my conclusion?
Autodesk’s proposed redefinition of PLM has substance in the starting point it offers: a team can begin with a product problem and develop the lifecycle action around it. That could change who participates in PLM and when they find it useful.
The evidence I want to see next is a team carrying its investigation into an approved change while preserving the source information and reasoning that made the decision possible. Where all data points are located? Where the related files? BOMs? How much of that journey can become easier without requiring the team to rebuild its context along the way?
Just my thoughts. YMMV.
Best, Oleg
Disclosure: I am CEO and co-founder of OpenBOM. My work on product data and collaboration informs this analysis.
Note my other articles about AU 2026
From Digital Thread to Product Memory in Operations
AU 2026: MCP Connects the Tools but Who Connects the Product Context
Invisible PLM and the Engineering Controls That Still Matter
AU 2026: The Platform Question Is No Longer APIs. It Is Context.
AU 2026 and the Autodesk Bet on Context for PLM
