I continue to share my thoughts about AU 2026 I attended a few weeks ago in Las Vegas. In my earlier post, I talked about Platform Forum speaking about APS and today I’m moving forward to keynotes.
At Autodesk University 2026, a supplier email about a motor shortage became the starting point for a PLM demonstration. The email was brought into a shared workspace. An assistant identified the product impact, proposed substitutes, and helped the team work through a BOM update and a draft change order.
The interesting part was how much information had to come together for that sequence to make sense. A supply chain problem became an engineering problem, which became a product change, which needed people to act. The demonstration gave me a useful way to evaluate the larger story Autodesk told across its two keynotes.
Autodesk is betting that AI becomes more valuable when software can connect the situation around the work. For the PLM industry, that raises a question about the foundation we have built: how much of a product decision can our systems actually explain?
Before AU, I wrote about the platform question moving from APIs to product context. The keynotes gave that question a concrete response. We saw tools doing useful work, but we also saw an attempt to connect the information and decisions that make the work meaningful.
A supplier email needs a product situation
The motor shortage scenario was familiar. There were 2,400 motors at risk in the demonstration and no approved alternatives. Finding a replacement required more than locating something with similar geometry. The team needed to understand the affected product, its requirements, available supply, and the consequences of the substitution.
An engineer might find a technically attractive alternative that purchasing cannot obtain in time. A buyer might find an available alternative that requires a different mounting arrangement. Even a small component change can introduce additional hardware and affect a production plan.
The assistant brought these questions into one working environment. The engineering manager retained the ability to inspect and refine the proposed BOM. That matters because the value of an engineering assistant depends on the quality of the situation it presents for a person to evaluate.
The keynote showed a prepared scenario. It did not establish how reliably every supplier email can be connected to every manufacturer’s product data. Still, it made the dependency visible: useful action requires relationships between facts that usually live in different places.
Remembering why a decision happened
Autodesk CTO Raji Arasu introduced Autodesk Context with an emphasis on the reasons behind decisions and the workflow conditions in which those decisions were made. Autodesk’s published description of its context graph connects project information with people, decisions, and activities.
This is a meaningful direction for lifecycle software. Revision history tells us that a component changed. A change record may tell us who approved it. The surrounding reasoning can be harder to reconstruct. Was the replacement selected because it performed better, because the original supplier missed a commitment, or because the team accepted a temporary compromise to meet a delivery date?
Those explanations change how the next engineer should interpret the same data. A temporary exception can become an apparently normal design choice once the original circumstances disappear.
That is the problem I have been exploring through product memory (check my upcoming book- From CAD Files to Product Memory). Product memory connects the evidence and reasoning around lifecycle records while preserving attribution to the people and systems that produced them. It does not need to become the authority over every engineering or business fact.
Autodesk Context and product memory are not interchangeable terms. Autodesk is describing a particular platform capability. Product memory is a broader architectural idea. The connection is the recognition that the reasons surrounding a record are valuable information in their own right.
The same problem appears outside manufacturing
One of the clearest examples came from construction. An assistant traced an RFI through affected building elements and schedule activities. The issue mattered because of what was about to happen on the project, including work on the exterior facade. A document became useful when connected to its downstream consequences.
On Day 2, a curtain wall installation scenario brought together an unresolved anchoring approval, an open RFI, and the installation schedule. The information existed. The challenge was identifying which combination of facts could block the work.
Manufacturers encounter a similar pattern when an unapproved substitute, an incomplete drawing, and an approaching purchase date converge. The domains differ, but the reasoning problem is recognizable. Teams need to know which dependencies matter in the current situation.
The media demonstrations added another dimension. Faster character generation and animation can reduce the cost of trying an idea. Engineering teams can also benefit from cheaper iteration, but generating more options increases the need to preserve why particular options were accepted or rejected.
More capacity depends on the surrounding process
Autodesk framed the keynotes around unlocking capacity. I think that is a useful business objective, provided we examine where the constraint moves.
If an assistant prepares alternatives in minutes, a team can still spend days waiting for supplier qualification or engineering approval. More rapid design generation can create a larger review queue. The useful measure is whether the whole process improves, including the decisions and handoffs that follow the automated task.
Clara Shih’s discussion on Day 1 made this point from an organizational perspective. Adding AI to individual steps produces gains, but larger improvements require reconsidering how the work is organized. The repeatable inspection workflows shown on Day 2 offered a practical example of addressing the handoffs around a task.
Context and application boundary
The strongest unresolved question is how far the connected context can travel. A manufacturer may use several CAD systems, an established PLM platform, an ERP system, supplier portals, and spreadsheets. An engineering decision can depend on facts owned by all of them.
Assistant Builder and external connections are encouraging because Autodesk acknowledges this reality. The harder test is whether identity, approval state, and decision history remain understandable as information crosses those boundaries.
I would also separate capture from inference. If software infers a reason for a past decision, that explanation should remain distinguishable from a reason recorded by the engineer who made it. An elegant account of the past is useful only if we know what evidence supports it.
My reading of AU 2026 is that Autodesk is expanding its ambition from connected engineering tools to software that helps coordinate decisions across the lifecycle. That direction deserves attention. The evidence I want to see next is whether a team can revisit a decision months later, understand its circumstances, and act on that understanding across the systems it actually uses.
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.
