I am back at The Venetian for Autodesk University 2026. After Nashville and San Diego, AU returns to Las Vegas, and the week opens the way most enterprise software weeks now open: with a platform conversation.
Before the main conference starts tomorrow, I am spending the afternoon at the Platform Leadership Forum, a pre-conference program built around Autodesk Platform Services (APS), APIs, Model Context Protocol (MCP), and AI-powered workflows. The opening session is called “Make Your AI Strategy Real.” After that, attendees choose one of three tracks: business lightning talks, technical lightning talks, or a hands-on MCP workshop.
Look at the sequence of the week. The conference starts with the platform. Tuesday morning moves to a keynote about building AI for the real world, with Andrew Anagnost, Raji Arasu, and Clara Shih. Tuesday afternoon brings manufacturing leaders into a dedicated PLM Summit built around customer-led sessions. Platform. AI. PLM. These used to be three separate rooms with three separate audiences. They are becoming one conversation.
Autodesk frames the week around three learning pillars: AI in Action, Intelligent Data, and Integrated Workflows. The Platform Leadership Forum goes one step further by putting APS, APIs, and MCP into the same program. That makes sense to me. Connecting AI to tools is quickly becoming a basic platform capability rather than a differentiator.
But I think the harder question has already moved somewhere else.
An AI agent can call a tool. Can it understand the product consequences of what it is about to do?
MCP Solves Access. It Does Not Create Understanding.
At AU 2025 I wrote about Autodesk AaaS, Agent as a Service, and asked whether MCP and agents could move beyond impressive demonstrations. A year later the question feels more precise.
MCP gives an AI system a standard way to discover and use tools. An agent can retrieve a model, query product information, invoke an automation, update a property. This is genuinely important. Our industry spent decades building point-to-point integrations, and a consistent interaction layer removes a lot of friction.
But MCP does not create product understanding.
It does not know why a component was selected, which alternative was rejected, whether a supplier commitment changed yesterday, or whether a customer-specific certification makes an apparently valid substitution unacceptable. MCP provides access. The quality of the decision still depends on the context behind that access.
This is not a criticism of MCP. It is a clarification of its job.
Here are the five things I am testing this week.
1. An Agent That Retrieves Files Cannot Assess Change Impact
Engineering information begins with files, but a product is not a collection of files. It is a network of items, revisions, structures, requirements, changes, configurations, suppliers, and decisions.
The distinction is practical, not philosophical. An agent that retrieves the latest drawing can answer a document question. An agent that has to assess change impact must know where the part is used, which configuration is affected, which revision is released, and which downstream commitments depend on it. One of those is search. The other is reasoning over a graph.
Autodesk has been moving toward more granular, connected data. The Fusion Roadmap 2026 describes revision controls, lifecycle readiness, Manage integrations, prompt-based BOM and property updates, and extensibility through MCP tools and APIs, all framed as a consistent and trusted data foundation.
I want to see whether those pieces are becoming one usable product context, or a larger set of individually accessible fragments.
2. Every Application Will Have an Assistant. That Is Not the Same as Shared Understanding.
CAD knows design intent. PDM knows file state. PLM knows released structures and changes. ERP knows purchasing transactions. Procurement knows supplier commitments. The shop floor knows what is actually happening. The most consequential product decisions cross every one of those boundaries.
If each assistant is grounded only in its own application, AI will make fragmentation easier to query without making it less fragmented. That is a real risk, and it is the most likely outcome if nobody designs against it.
The platform opportunity is larger. Connect the identities and the relationships, and let each system stay authoritative for the facts it owns. Distributed authority and connected context are not opposites. They are the architecture an engineering agent actually needs.
3. Openness Is Not an API. It Is Crossing the Vendor Boundary Without Losing Meaning.
No manufacturing company lives inside one vendor stack. Even a company standardized on Autodesk works with suppliers, contract manufacturers, ERP systems, quality applications, spreadsheets, databases, and equipment from a dozen providers.
So openness cannot mean only that an external developer can call an Autodesk API. The practical test is whether a workflow can combine Autodesk and non-Autodesk information without losing identity, permissions, traceability, or meaning.
This will matter most at the PLM Summit. Last year I saw APS emerging as a possible data plane for product structures and workflows while the application reality stayed divided across Vault, Fusion, and Fusion Manage. I want to see what changed in twelve months.
4. An Agent That Cannot Write the Decision Back Leaves the Loop Open
A useful engineering agent cannot just produce an answer. It has to show which records it used, separate released information from work in progress, respect permissions, expose uncertainty, and preserve who made the final call.
Then something else has to happen. The result needs to become part of the product history.
If an agent finds a BOM inconsistency, people review the evidence, a decision gets made, and the conclusion disappears into a chat transcript, nothing was preserved. The next person, or the next agent, reconstructs the same situation from scratch six months later.
The important loop is not prompt and response. It is context, recommendation, human decision, governed action, and memory.
5. Speed Is a Weak Test. The Real Test Is Which Decision Got Better.
AI demos naturally emphasize speed. A prompt creates geometry. An assistant finds a command. An automation updates properties. All useful, but speed alone is a weak test for engineering intelligence.
I am looking for decisions that improve. Change impact identified before release. An obsolete component caught before purchasing. BOM completeness verified before handoff. A supplier risk surfaced before a launch milestone. An explanation of why a prior design decision should not be repeated.
This is the problem we have been working on at OpenBOM through what we call a product context graph. Review builds context, agents use it, and decisions write new context back. I am here partly to compare that experience against Autodesk’s platform direction.
Digital Thread Creates Continuity of Data. Product Memory Creates Continuity of Understanding.
The phrase I keep returning to is Product Memory.
Product Memory is not another database and it is not a new name for PLM. It is the connected layer that preserves why a product became what it is: the evidence considered, the alternatives rejected, the exceptions granted, the decisions made, and the consequences discovered later.
We kept the files. We usually lost the reasons.
This is the subject of my upcoming book, From CAD Files to Product Memory. AU 2026 is a good place to test the idea, because Autodesk sits at an unusual intersection: design tools, cloud data, manufacturing workflows, PLM, a large developer ecosystem, and now AI agents.
My Test This Week Is What Holds Up After the Room Empties
Over the next three days I will be in the AU Product Leadership Forum (former DevCon with APS Team), AU keynotes, the PLM Summit, and sessions on PLM beyond the BOM, AI-supported engineering decisions, Fusion with MCP, and prompt-to-production workflows. For each one I am writing down the same six things: the speaker claim, the demonstrated workflow, whether it is available or preview or roadmap, one customer outcome, what changed since AU 2025, and one unresolved question.
Then four questions. What did the system connect? What does the team understand that it could not understand before? Which decision became safer or faster? And what context will still exist when the people in the room are gone?
The Platform Connects. PLM Governs. Product Memory Explains.
If AU 2025 was about proving that agents could reach engineering tools, AU 2026 should be about proving that they can understand the product.
The conference sequence offers a useful architecture. The platform connects. PLM governs. Product Memory explains.
The first two are becoming visible in software this week. I will spend the rest of the week looking for the third.
Just my thoughts. YMMV.
Best, Oleg
Disclosure: I am co-founder and CEO of OpenBOM, which develops cloud product data management and collaboration software and integrates with Autodesk Fusion and APS. My perspective is inevitably informed by that work.
