My last article about PLM topics presented at AU 2026. If you missed the first two articles check these links:
The Data Foundation Behind Autodesk Agentic PLM
Autodesk Agentic PLM: What Exactly Is Being Redefined?
One example in the Fusion strategy session at AU 2026 captured a familiar manufacturing problem. A fifty-cent electronic component can have a thirty-week lead time. Its small contribution to product cost tells us very little about its ability to delay the entire product.
The session used this example to introduce sourcing information earlier in design. The PLM Summit approached the same issue through a preview of supplier-risk analysis using Resilinc and an MCP connection. Together, the two presentations showed why Autodesk’s Agentic PLM strategy depends on the information around the engineering definition.
I think this is where the ecosystem becomes a substantive part of the proposition. An assistant helping resolve a product problem needs to connect engineering suitability with the business conditions under which the company can actually build and deliver the product.
A sourcing problem changes an engineering decision
The Fusion electronics presentation showed a direction toward component libraries enriched with price and lead-time information. The intent was to make sourcing constraints visible while an engineer can still act on them. The session presented supply chain intelligence as a developing capability, with the slide marked beta.
This is a useful change in timing. An unavailable component can force a redesign after the team believes its work is complete. Earlier visibility creates an opportunity to consider an alternative before the design becomes expensive to change.
However, a catalog signal is only one part of the decision. The manufacturer may have existing inventory, an allocation agreement, or purchase orders already in place. The component’s qualification for a particular product can also matter. An attractive alternative needs to be assessed against the company’s actual situation.
That makes the canvas an interesting place to bring people together. Engineering can evaluate suitability while purchasing clarifies commercial conditions. Quality can contribute qualification information. The Assistant can help identify the facts they need and prepare the resulting work.
The business value would be visible in the decision the team can complete: whether to retain the component, qualify an alternative, or change the production plan.
Supplier risk belongs in the investigation
At the PLM Summit, Autodesk previewed a Resilinc connection for bringing supplier-risk information into the Fusion experience through MCP. The presentation discussed financial stability, disruption exposure, lead time, and compliance-related assessments. This was a preview of a partnership direction, rather than evidence that every described workflow is available today.
The interesting point is where that information enters. A risk signal can affect an engineering choice before release, when alternatives are still practical to evaluate. The team can relate the signal to the affected parts and investigate the consequences for its products.
For that to work, the connection must be precise. A supplier-level risk signal does not automatically identify which manufacturer’s part or production plan is affected. The assistant needs relationships among the supplier, the purchasable component, the internal item, and the relevant product configuration.
A team also needs to know how current the information is and what it describes. A market lead time and a committed delivery date answer different questions. Bringing them into the same investigation should preserve those distinctions.
The engineering sources are part of the ecosystem
The ecosystem begins upstream of the supplier-risk service. A product can combine engineering information from several CAD systems, electronics tools, software repositories, and suppliers. The component being evaluated may be represented differently in each environment.
In the Fusion session, the reuse demonstrations connected candidate parts to product development work. That is useful because a part’s suitability depends on its engineering context. Geometry can help find a candidate, while the applicable requirements and approved state determine whether the team can reasonably use it.
Now extend that investigation to a supplier’s subassembly maintained outside Autodesk’s authoring environment. The team may have a translated model, a drawing, and a released specification. It needs to know which of those representations supports the substitution and how it will learn about the next source change.
This is why heterogeneous engineering sources belong in the ecosystem discussion. They supply the product meaning to which commercial and risk information must be connected. The value of the shared canvas depends on how well these relationships survive the boundaries between organizations and tools.
Connecting the decision to operations
The Summit described a gap between product development and the operational information managed around ERP. I would approach that gap through shared decisions. Engineering defines a suitable alternative. Purchasing needs to know whether it can obtain the alternative. Manufacturing needs to know which version it should build.
Consider a hypothetical response to a motor shortage. The team selects an alternative after reviewing the design impact and supplier conditions. It then needs to establish which production orders the change affects, whether existing stock can still be consumed, and when the approved alternative becomes applicable.
Those questions involve operational records as well as the engineering definition. A supplier substitution can be technically sound and still arrive too late to solve the immediate delivery problem. The agentic workflow should make that limitation visible while the decision remains open.
The useful outcome is a traceable relationship between the decision and the operational actions that follow it. The selected alternative, its applicable revision, and its conditions of use should remain understandable to the people who buy and build the product.
What openness needs to deliver
The PLM Summit identified APIs, MCP connections, Tandem Connect, and Data Exchange as approaches to extending the experience across systems. These mechanisms offer different ways to move information or invoke work. Their value becomes clearer when we follow a particular product decision through them.
I would ask whether a partner can connect a source while preserving its authority over the information it supplies. Can the assistant distinguish a supplier’s published data from a manufacturer’s approved alternative? Can a customer inspect where a conclusion came from and carry that explanation into the resulting change?
These are practical measures of openness. They allow a customer to keep useful engineering and business systems while gaining a more connected way to work. They also create a meaningful role for partners with domain information or capabilities that improve the decision.
For Autodesk, the opportunity is to make the agentic experience useful across a broader set of customer environments. The heterogeneous engineering sources discussed in the data-foundation article are part of that opportunity, alongside ERP and specialist supplier services.
What is my conclusion?
The two sessions connected a low-cost component’s lead time with a much larger question about product development. Useful Agentic PLM must relate engineering choices to the conditions under which a company can manufacture and deliver.
Autodesk’s ecosystem direction deserves attention because suppliers, engineering tools, and operational systems contribute different parts of that answer. I would make an assessment of the strategy by how reliably a team can connect those contributions to a decision and carry the decision into execution. Can it preserve the product context as the work crosses each system boundary?
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
