I’m at AU2025 in Nashville, TN. Autodesk had moved the AU from a traditional Las Vegas to a rock-center of the U.S. (at least this year), so as usual, I’m coming to learn about Autodesk directions, strategy, and PLM development. At OpenBOM, we are partnering with Autodesk and the Autodesk Leadership Forum was a pre-AU event to attend and learn about platform directions Autodesk is taking.
It was the first Platform Leadership Forum, which is to me, a successor to DevCon. The format may have changed, but so has the intent. What was once a technical developer conference has become a broader strategic stage for Autodesk Platform Services (APS) with two tracks – business and technical. I attended the technical (developers) track.
MCP (and agents) was the “topic of the year”. The recurring emphasis on agents and MCPs (model context protocols) was in every presentation and I found it very interesting and important.
Although it was not presented in such a way, I call it Autodesk AaaS (Agent as a Service). If there was a headline takeaway, it is this: Autodesk is pointing toward a future where AaaS could stand for Agent as a Service. But what does that mean in practice? And how realistic is it?
From DevCon to Leadership Forum
The move from DevCon to a Leadership Forum tells us something. Autodesk is no longer speaking just to developers. APS is now being positioned as central to Autodesk’s strategy. The discussion was not about how to call an API, but about how APIs, data models, and orchestration services could redefine what Autodesk actually delivers.
This raises a bigger question: if APS is no longer “plumbing,” but the foundation of workflows, does Autodesk become less of an application vendor and more of a platform operator? And if so, how will customers and partners adjust?
MCPs and Agents: Orchestration or Buzzword?
One of the most repeated themes was MCPs — Model Context Protocols. Autodesk showed slides comparing “before MCP” and “after MCP.” The idea is simple: without MCPs, large language models (LLMs) are brittle and connect directly to apps. With MCPs, there is orchestration, structure, and context.
This naturally leads to agents. In Autodesk’s framing, agents will interact with MCPs, which in turn connect to data, apps, and tools. It is a neat architecture, but the open question is whether these agents will become more than demos.
Tools and connection to data is a second (very important) element of AI agent strategy.
Using MCP to access data was an important message from Autodesk, which I believe is closely aligned with the vision we are pursuing at OpenBOM—connecting product data to engineering workflows through MCP. [We recently released MCP availability in the OpenBOM AI Agent ].
Autodesk’s AI Hierarchy
Autodesk also shared a layered “hierarchy of AI models.” At the base sit general-purpose LLMs. On top of them, Autodesk envisions spatial and physical reasoning grounded in 3D data. The next level is industry-specific reasoning tuned to AEC and manufacturing domains. At the very top lies company-specific reasoning, where models are fine-tuned to a customer’s own data.
On paper, the logic is sound. Generic LLMs alone are not enough for engineering tasks. But the question is execution. Can Autodesk truly move from experiments in generative geometry to AI agents that solve real-world engineering problems at scale? Or is this still aspirational?
Can they grow into the building blocks of real engineering workflows, or will they remain experiments like Project Bernini?
Structured Data and Extensible Models
Another strong theme was data. Autodesk emphasized that the “future is structured” and shared roadmaps for extensible Manufacturing and AEC data models, including custom property support, geometry extraction, and more.
This is a significant direction: opening data models and making them more accessible. But will Autodesk really follow through on openness, or will it remain tied to Autodesk-only contexts?
And how will this affect the balance between Autodesk tools and the broader ecosystem?
Analytics and Connected Workflows
Examples of dashboards built from model and construction data into Power BI made the point tangible. Issues around coordination, clashes, quality problems, or constructability were shown not as abstract concepts but as live metrics and lists. It is a reminder that the value is not just in models themselves but in how data connects into decision-making systems.
The challenge is whether Autodesk will allow customers to use these capabilities freely across the tools of their choice, or whether analytics will remain locked inside the Autodesk stack.
Ecosystem and Openness
Autodesk also emphasized the idea of an “open ecosystem.” Slides highlighted industry standards such as buildingSMART, ISO, ODA, and DEXPI, alongside collaboration agreements with Esri, Bentley, Nemetschek, Trimble, Schneider Electric, Epic Games, and others.
On the surface, this looks promising. But how open will APS really be? Will it support deep interoperability across ecosystems, or will it remain more of a controlled integration program? Partnerships and logos are easy to show. The harder test is whether competitors and partners alike can depend on APS without lock-in.
MCP Servers: Infrastructure for Agents
The introduction of MCP servers was meant to underline Autodesk’s seriousness. The message was that they would be enterprise-grade, resilient, context-aware, and “smart by default.” This makes MCPs sound like more than a prototype. Autodesk clearly wants to make them into core infrastructure.
Still, the same question remains: what problems will MCP-powered agents actually solve that current software workflows cannot? The vision is clear; the path to practical adoption needs to be discovered – how MCP exposed data and workflow will solve customer problems.
Reflection: Autodesk AaaS – Agent as a Service
The most thought-provoking theme of the Forum is the idea of agents as a service layer. If agents orchestrated by MCPs become the new interface between users, apps, and data, Autodesk could shift how design and make workflows are executed.
But many uncertainties remain. Will Autodesk agents be open enough for customers and partners to extend, or will they be confined within Autodesk’s ecosystem? How will customers pay for agent-driven services — by API calls, by tokens, or by outcomes? Can Autodesk balance being both a software provider and a service orchestrator without creating conflicts of interest?
Agent as a Service might sound like the future, but its shape is not fixed yet. Autodesk is making a big bet on it, and AU2025 may reveal more. For now, the Leadership Forum raises more questions than it answers. And perhaps that’s exactly what makes it interesting.
Demo and Thoughts about Problem Solving
Autodesk demonstrated a demo where a conversation is used for data search in an APS / Viewer environment. This is where it starts to be very interesting. It connects a specific problem “file search” connected to the data stored in APS.
Another (more sophisticated demo) of APS demonstrated building a task tracking AEC application using AEC data model.
Both examples are clear indications that only by connecting MCP tech to specific problem solving, the APS vision will transform into a powerful layer taking Autodesk business forward.
What is my conclusion?
Back 30 years ago, I started my business experience from writing applications in AutoLISP helping to organize customer files. AutoCAD (back in those days running on MS-DOS) was a platform, but searching for files was a problem. We made another tech circle coming to AI, MCP, and agents. Still many problems of engineers are unsolved.
I’m looking forward to AU2025. As Autodesk prepares for AU2025, the questions are bigger than the announcements. How far will Autodesk go in turning MCPs and agents into real, usable products? Will APS consumption pricing accelerate or slow adoption? And will the promise of an open ecosystem translate into real interoperability, or remain a curated set of selective partnerships?
These are not marketing slogans but strategic choices Autodesk must make. If Autodesk succeeds, it could redefine how engineering and manufacturing software operates in the age of AI and platforms. If not, AaaS might remain just another acronym.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I advocate for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased.
