I’m slowly digesting AU 2026 and this week will be coming with a series of articles sharing what I learned from Autodesk a week before. Here is the first one about Platform Leadership Forum.
Most people who use Autodesk tools have never heard of the platform underneath them
Ask an engineer what Autodesk makes and you will hear Revit, AutoCAD, Fusion, Vault, maybe Autodesk Construction Cloud. Ask what connects them, and most people will shrug. That connecting layer has a name: Autodesk Platform Services, or APS.
I spent the day before Autodesk University 2026 at the Autodesk Platform Forum, a set of sessions dedicated entirely to APS. Autodesk summarized its direction in one sentence that I think is worth unpacking: APS is moving from a platform you build on to a platform that builds with you.
That sentence is easy to repeat and harder to evaluate. So in this article I want to do something simple. I want to explain what the Autodesk platform actually is, what this shift means, and what value you can get from it right now, as opposed to what is still on the roadmap.
My short answer: the vision is AI that assembles solutions for you. The value today is connected data you can build on, with AI help that is real but mostly still in beta.
APS is Autodesk’s plumbing, and it has been under construction for a decade
Autodesk Platform Services is Autodesk’s cloud platform of APIs and data models. It gives developers programmatic access to design and project data across Autodesk products, so they can connect workflows, automate work, and build their own applications.
If the name is unfamiliar, the history may not be. APS is the successor to Forge, which Autodesk renamed in 2022. The platform has been built piece by piece for years. Today it covers authentication, data management across Autodesk cloud storage, model translation and web viewing, and Design Automation, which runs engines like Revit and AutoCAD in the cloud without a desktop. More recently Autodesk added granular data models for AEC and manufacturing, which expose design data at the level of elements and properties rather than whole files.
The strategic idea behind all of it is connected data and connected workflows. Information created in one tool should be usable everywhere else, by people and by software.
The forum made this concrete. HDR, the design firm, built a model validation engine on APS that checks parameters such as fire ratings across hundreds of doors. An engineering firm designing electrical substations is moving to Design Automation to turn a web configurator layout into a coordinated Revit model and PDF in 5 to 10 minutes. JE Dunn, the construction company, uses APS to connect design and project data into its enterprise data platform. These are real customer systems, some in daily use and some rolling out now, built on plumbing most users never see.
Building on APS has always meant learning all of APS
The biggest barrier to the Autodesk platform was never capability. It was the expertise needed to use it.
One of the developer speakers put it plainly. Until now, to build with APS you had to learn all of APS, and you had to know the exact sequence of APIs to call. Autodesk described the typical path from its own side: you take a use case, spend weeks in conversation with APS experts, and still only get halfway to a working application. Authentication, data management, translation, viewing, and automation each have their own logic, and stitching them together is specialist work.
When Autodesk asked the room how many people already had solutions on APS, roughly half raised their hands. That is a room of developers who chose to attend a platform event. The other half had not yet crossed the barrier.
I recognize this problem because every engineering software platform has it, PLM included. The APIs exist. The documentation exists. But only a small group of specialists can actually assemble them into something useful, and that group becomes the bottleneck for everything a customer wants to automate.
A platform that builds with you moves the developer’s starting point
This is the central message of the forum, and I think it is the right one. The idea is not that AI replaces the platform. The idea is that AI changes where the developer’s work starts: from assembling APIs to refining a solution that already works.
Autodesk framed the shift across four stages of the developer journey.
Explore. The APS Assistant takes a problem statement in plain language and answers two questions at once. The technical one: which APIs should I use? The business one: how many hours will this save? It draws on API documentation, past use cases, and customer success stories. That combination matters. Developers rarely lack ideas; they lack confidence that an idea is worth the investment.
Build. The APS Workflow MCP works inside coding agents such as Claude Code or Cursor. It knows the APIs, their capabilities, which API fits which use case, and the dependencies between them. In the keynote demo, a single prompt produced a complete solution using six APIs. In a second demo, a prompt asking for a Revit model viewer app produced a working application, including an authentication workflow nobody explicitly asked for. Autodesk described this as work that used to take weeks, if not months.
Manage. Instead of clicking through dashboards, a developer or admin asks for the app portfolio sorted by usage and environment, sees which apps are unused, and acts on them by prompt, with human confirmation.
Distribute. The Design and Make Marketplace, where partners publish Autodesk-verified solutions, becomes searchable by an agent. A customer can ask for sustainability apps for Fusion rated three or higher and get an answer. Later, the same discovery moves inside Autodesk products, and partner solutions become callable directly from Autodesk Assistant.
Notice what Autodesk Assistant is becoming in this picture: the front door. It manages, discovers, and eventually invokes. APS sits underneath, and the Marketplace becomes its catalog.
Here is the implication I think matters most. When integration becomes cheap, integration stops being a moat. The value of the platform moves away from the APIs themselves toward two things: the data those APIs can reach, and the judgment of the people building on them.
What you can use today is smaller than the vision
To judge the value of APS right now, you need to separate what is shipping from what was demonstrated. Autodesk was clear about this on its roadmap slide, and I want to be equally clear here. Here is the roadmap slide I captured.
Live today. The APS Assistant on the Autodesk developer site, available since June. The Autodesk Product Help MCP server, free, covering documentation for more than 100 products, which brings Autodesk knowledge into coding environments. Agent-based discovery on the Design and Make Marketplace. And, of course, the existing APS APIs themselves, which is where all the customer results in this article come from.
Beta, targeted within 90 days. The APS Workflow MCP, with a private beta opened at AU. Prompt-driven usage insights for app portfolios. Enhancements to the Automation API.
General availability, targeted next quarter. The Workflow MCP and usage insights.
Later. App administration workflows that take action on your portfolio, Marketplace discovery inside products such as Fusion, partner agents invoked from Autodesk Assistant, and Autodesk Assistant connecting to Microsoft MCP servers, including Work IQ, which Autodesk announced as coming soon.
So the honest summary is this. The AI-native building experience, the part that best captures “builds with you,” is not yet generally available. What you can use today is the existing platform plus AI that helps you find your way through it. That is useful, and the direction is credible. But anyone planning a project in the next quarter should plan on today’s APIs, not on the demo.
Customers proved the value is in connected data, not in the model
The most convincing evidence of APS value did not come from Autodesk. It came from customers, and every one of them told the same story in different words: the hard part was the data, and that is where the platform earned its place.
An engineering consultancy described what it called “the work before the work.” At QC milestones, a senior engineer who was not on the project reviews it. Before applying any expertise, that engineer has to find drawings, calculations, review comments, and emails, then figure out which version of each is current. When the firm asked its people how they know which documents are most recent, every answer was different: personal spreadsheets, saved email folders, local file structures. Everyone could find their own information. Nobody could find each other’s.
The firm built specialized agents that gather project data across the Autodesk cloud, SharePoint, and Outlook, then compare and summarize it for the engineer. In a controlled validation test on a synthetic project with a real design conflict, the agent found that the calculations required a 750 kW emergency generator while the one-line diagram showed 500 kW. No comment, no open issue, nobody had flagged it. The system is live with 25 people across 10 projects and is now part of the firm’s standard quality review process. Their most memorable conclusion: the model was the easiest part. The hard part was project data sitting in silos that were never built to talk to each other.
An employee-owned engineering firm designing electrical substations followed the same logic. First a structured project database, then a rules-driven web configurator, then Design Automation to produce documentation. They report a conservative 25% improvement in initial design delivery and a projected 6.5x return over five years. Their stated strategy was to build the data layer first and add LLM reasoning later.
JE Dunn spent roughly a decade building a data foundation that connects Autodesk and enterprise data. Project changes that used to take 12 hours to update now take 5 minutes. Their CIO named the key to AI as ontology: a shared understanding of what terms mean across systems and teams.
Industry research presented the same day put a number on the gap. Only 18% of surveyed organizations have connected and centralized their data with an ontology layer on top. Another 46% have moved data to the cloud but still lack the context layer that ties design, operational, and asset data together.
This is the real value proposition of APS today. It delivers value when it connects data that was previously scattered. AI amplifies that value. It does not create it.
APS connects the data, but someone else may own the meaning
The JE Dunn story was the flagship example of the day, and it contains the most important open question about the Autodesk platform.
Look at where the pieces sit. APS connects design and project data. But the place where that data comes together with the rest of the business, and where the shared ontology lives, is Microsoft’s enterprise data platform. JE Dunn also centralized its AI governance on Microsoft, blocking other frontier models so that its 3,800 licensed Copilot users work from the same governed environment. Autodesk’s response is sensible: Autodesk Assistant will connect to Microsoft MCP servers, bringing Autodesk design data together with Microsoft 365 context.
JE Dunn’s request to vendors was just as telling. They asked Autodesk and Microsoft to proactively build scalable MCPs across schedule, project management, and multiformat data, so customers only handle the “surgical” high-value work. In other words, customers want the connections to be the vendor’s job and the meaning to be theirs.
This is good for customers. It also means APS is positioned as the best-connected source of design and project data, while the semantic layer where AI reasoning happens may live elsewhere. Assistant wants to own the conversation. The enterprise data platform owns the meaning. Partners supply the agents. It is not yet clear which of those positions will be the durable one.
I have been writing about this layer for a while under the name Product Memory: a context layer above systems of record like PLM, PDM, and ERP that captures relationships, decisions, and history, not just data. What I heard at the forum convinced me the industry is converging on the need for that layer, whatever we end up calling it. The ownership question is the part nobody has settled.
One technical note, because it gets blurred in a lot of AI discussion. MCP is a protocol for exposing tools and context to agents. It does not orchestrate anything by itself. The engineering consultancy above had to build its own orchestration layer to decide which agent handles which question. That layer is where a lot of real engineering still happens.
For manufacturing, the value of APS is still mostly implied
For readers who live in PLM, PDM, and manufacturing, I have to be direct: nearly all the evidence at the forum came from architecture, engineering, and construction.
Manufacturing appeared in two places. CoolOrange showed an MCP that acts as a translation layer between Autodesk Vault and ERP systems. It can update a bill of materials, but only after a human signs off. And Fusion was named as a future home for in-product Marketplace discovery.
The CoolOrange example is small, but it gets the design pattern right. Every mature deployment I saw that day worked the same way: agents gather, compare, and propose; humans decide and stay accountable. The engineering consultancy described its system as a person starting the process and a person finishing it, with automation only in between. Another partner talked about encoding skepticism into software, so an agent knows when to stop and ask a human. Nobody automated engineering judgment. They automated everything standing in front of it. For BOM changes, that is exactly how it should be.
Manufacturers will have to translate the AEC lessons themselves, and the translation is not hard. The same fragmentation exists across CAD, PDM, PLM, ERP, email, and spreadsheets. The same question applies: how do you know what is current? And the same answer holds: connect and structure the data first, then let agents reason over it, with humans at the decision points.
What is my conclusion?
A platform builds with you only as far as your data lets it
So, back to the two questions I started with.
What is the Autodesk platform? It is Autodesk’s connected-data layer: the APIs and data models that sit under Revit, AutoCAD, Fusion, and the Autodesk cloud, and let companies build their own workflows on top. It has been under construction for a decade, and it is now being reshaped so that AI can assemble solutions on it.
What is its value right now? Three things. Access to design and project data across Autodesk tools, which is where every real customer result came from. Proven automation patterns such as Design Automation, which can turn multi-day handoffs into minutes for firms willing to structure their data first. And early AI help that lowers the barrier to building, with the most ambitious part, the Workflow MCP, still in private beta.
What comes next depends on three things I will be watching: whether the Workflow MCP reaches general availability on schedule, whether customers do the unglamorous data work that every successful story required, and whether Autodesk or its partners end up owning the context layer where meaning lives.
The JE Dunn CIO closed his panel with a story from his son, a composer, who said AI can only write the average of the best music it has seen. The breakthroughs still come from people. I think that applies to platforms too. AI will write more of the integration code. Somebody still has to decide what the data means.
What do you think? Is your organization building the data layer first, or waiting for the agents to arrive? Let me know in the comments.
Just my thoughts…
Best, Oleg
