Continue sharing my thoughts after AU 2026 a few weeks ago. If you missed my previous articles about Autodesk University, please check them here –
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
Assistant Builder brings external expertise into Autodesk workflows, while Fusion MCP lets external AI reach engineering tools. The larger question is how those interactions preserve product identity, source authority, and the reasoning behind decisions.
AU 2026 showed two useful directions for engineering AI. Autodesk Assistant Builder is intended to bring company and partner intelligence into Autodesk Assistant. The manufacturing keynote also described Claude working with Fusion through MCP, allowing an external AI system to perform actions in the engineering environment.
Together, these examples raise a platform question. If several assistants can reach the tools, where does the shared understanding of the product is stored?
I have been asking a version of this question in my writing about MCP and product memory. The keynote demonstrations made it more concrete. We can begin to see how intelligence might move between applications. The next challenge is preserving the meaning and authority of the information it uses.
Intelligence can enter and leave the platform
Assistant Builder describes one direction. A company can connect specialized expertise and data to an assistant inside an Autodesk workflow. In the Day 1 sustainability demonstration, the assistant combined a Revit model, a partner sustainability service, and the engineering firm’s own project cost history.
That combination was useful because each participant knew a different part of the problem. The model described the design. The partner service contributed environmental information. The firm’s history supplied a basis for evaluating costs. The engineer still needed to perform structural checks and coordinate the decision with the team.
The Fusion and Claude example points in the other direction. An external assistant can use engineering capabilities through a standard connection. The potential starting point for work becomes broader than a particular application window.
This is a good reason to pay attention to Autodesk’s openness direction. Autodesk’s developer announcement describes Assistant Builder connecting agents, MCP servers, tools, and data sources. There is room for partners to contribute specialized actions and expertise.
A connection still needs an alignment in meaning
MCP, the Model Context Protocol, provides a standard interaction mechanism through which AI applications can access exposed tools and resources. What those tools know and what their results mean depend on the systems behind them.
Imagine a substitute-component workflow crossing CAD, PLM, ERP, and a supplier service. CAD can identify geometry that fits. PLM can identify the released revision and applicable approvals. ERP can describe inventory and purchasing commitments. The supplier service may expose a lead time.
The workflow needs to establish that these facts concern the same item and the relevant configuration. A supplier identifier may differ from an internal part number. Inventory may contain an earlier revision. A released substitute may be approved for one customer application and excluded from another.
Calling each tool successfully does not resolve these distinctions. The integration needs relationships, identity mappings, and explicit rules about which source governs which fact.
I think that work will become more visible as agents begin to take actions. A person can sometimes recognize a mismatch from years of experience. An agent needs the distinction represented in information it can use.
Openness should be tested through a complete decision
A practical test would start with a product change and follow it across the systems involved. Can the workflow identify the affected revision, inspect the evidence, request the appropriate approval, and preserve the resulting decision where the next team can find it?
This is a more demanding test than counting available connectors. It also gives a customer something observable to evaluate.
The AU demonstrations showed a direction toward that kind of coordination. They did not settle questions about portability across every PLM platform or the reuse of Autodesk context by any external assistant. Those capabilities need to be evaluated through the specific interfaces, permissions, and supported workflows available to a customer.
I would also ask how the system behaves when sources are not aligned between platforms. If the supplier reports parts availability but ERP shows no inventory available, the conflict should remain visible. I’d expect the system to provide a combined answer with a clear summary of unresolved conflicts.
The coordinator gains influence
There is a business implication here. The assistant that starts a workflow can help to identify tools people discover, which partner services they use, and how they evaluate the resulting work.
That does not mean one assistant must own every system. It does mean the coordination experience can become an important part of platform competition. Partners may contribute through the capabilities they make accessible, the domain knowledge they provide, and the quality of the decisions they support (think of ChatGPT connecting multiple airline providers when you request to plan a trip)
My earlier APS article looked at the developer experience and what customers can use today. The keynote story adds another question: how will these capabilities share a product situation once they are participating in the same decision?
Model selection is a separate concern. Autodesk AI Orchestrator is intended to choose models suited to particular tasks. That can help with accuracy, speed, and cost. Selecting the right model still requires relevant and trustworthy business information underneath it.
Product memory should work across changing assistants
Agents and models will change. Product decisions often remain relevant for years. The reasoning behind a substitution should still be available when the team uses a different assistant or brings in a new supplier.
That is why I see product memory as something companies need to preserve across interactions. It should connect a decision to its evidence, responsible people, and lifecycle records, with clear attribution to the sources. It should also indicate when a conclusion was provisional or later superseded.
The authoritative record can remain in PLM, ERP, or another system responsible for it. Connecting the surrounding reasoning does not require transferring authority over every fact into the assistant.
For a smaller manufacturer, the immediate opportunity may be combining a few systems around a practical problem. For an enterprise, it may be adding coordination across platforms that are already deeply embedded. Both need clarity about identity and authority, even if their implementation paths differ.
Autodesk’s keynotes gave the industry useful examples of intelligence moving across tool boundaries. I will judge the next stage by what remains understandable after that movement: which product was affected, what evidence was considered, who decided, and how another team can use the result. That is where an accessible tool becomes part of a dependable engineering workflow.
Just my thoughts. YMMV.
Best, Oleg
Disclosure: I am co-founder and CEO of OpenBOM. My perspective on product data, collaboration, and AI is informed by that work.
