I spent September 14 to 17 at Autodesk University in Las Vegas. In four days I went to 17 sessions, about 15 and a half hours of content. I also got to spend an hour on stage for one of them.

When I lined up my notes afterward, one theme stood out. Last year, the talk was about whether AI could do real work in AECO. This year, the talk was about how to let it do real work safely. The questions have moved from “can we?” to “who checks it, who owns it, and what’s it allowed to touch?”

Here’s what I saw, and what I think it means for BIM One and the firms we work with.

On Wednesday I joined Mostafa El Ayoubi, Michael Kilkelly and John Pierson on a panel moderated by Carl Storms: Feature, Add-In, or AI? Should You Buy, Build, or Hack in 2026? Carl put together an excellent summary of the discussion, and I’d point anyone there for the full recap. [https://thebimsider.com/speaking-engagements/speaking-engagement-handouts/]

I won’t retell it here. But the panel gave me a lens for the rest of the week. It’s never been easier to build something. So the real work has moved to deciding what deserves to be built, and then standing behind it. I went looking for that idea in every other session, and it was everywhere.

It started on Monday at the Platform Leadership Forum. One slide broke an AI agent into three parts:

•       Inputs: instructions, model, context, memory and skills.
•       Reach: how it connects to other systems through MCP, REST or GraphQL.
•       Guardrails: approval gates, with identity underneath everything.

Under the first two columns the slide said “Most teams build this” and “And this.” Under guardrails it said “Fewer build this.”

That hit home. It’s the easy part to skip when a prototype is working and everyone’s excited. The same session offered six questions to ask before building any AI workflow.:

1. Is this actually an AI problem, or would a rule or automation do it just as well?
2. Is the data accessible, clean and permissioned before it reaches a model?
3. What’s the right build tier: an off-the-shelf agent, low-code, or custom code?
4. How will we check the output before it touches real data?
5. Who owns it once it’s live, and is it registered so nobody quietly rebuilds it?
6. Are we ready to keep iterating?

Question 1 alone would save a lot of wasted AI usage.

The sessions I found most useful weren’t the ones promising AI would do everything, they were the ones that drew a clear line around what AI is allowed to do.

In Agentic AI for AEC, Autodesk showed a project mobilization workflow split into two layers. A planning layer that works out the intent, checks the project state and builds a plan. And a separate execution layer, that only carries out approved, bounded actions, like creating locations, assets and issues. Every planned action maps to one known capability. No arbitrary calls. The plan is even approved by an exact hash before it runs.

John’s Dynamo sessions came at the same idea from the tool side. In Unleashing Dynamo with Autodesk Assistant and MCP, he walked through Dynamo MCP. It’s a local server that exposes about 47 Dynamo operations, like creating nodes and running a workspace, to any AI client. Two lines from his slides stuck with me. The first: “The model reads the documentation you read. It is not recalling Dynamo from training data.” The second described the server’s instruction file as being pinned by unit tests, with behavior “treated as code, not vibes.”

That’s the pattern I want for anything BIM One builds with AI. Let the model help you work out what to do. Then make sure the part that actually changes the model is something you can test, repeat and explain. There was even a session title that summed it up: Don’t AI Everything: Hybrid Automation with APS and Revit.

John’s other session, Break the Desktop Barrier, was about Dynamo in the cloud. Dynamo Switchboard hands a graph off to Autodesk Platform Services compute. You can run Dynamo with no Revit at all, or run headless Revit across many models in parallel and get modified .rvt files back. One line from his slides: “The workstation should not be the unit of compute.”

For a firm like ours, this one is practical. We run standards and QA checks on a lot of client models. Doing that one model at a time on someone’s desktop is slow and ties up a person. Batch jobs in the cloud could change that.

Thursday afternoon’s openBIM session had my favorite line of the week. On why one giant IFC export doesn’t work: “Nobody wants one playlist with every song.”

The better approach is purpose-built exports for structure, cost, MEP, energy, handover and site, federated later as needed. For a massive IFC, you can bring it into Forma, pick only what you need, publish a Data Exchange and load that into Revit. Its lighter and the work is faster.

Add the AEC Data Model API roadmap, early work on the next version of IFC, and a session on building an AI-ready BIM data backbone, and the direction is clear. The future is data first, files second. That matters for AI too. An agent is only as good as the data it can reach, and clean, well-scoped data is a lot easier to trust than a huge model nobody fully understands.

On the last day, Don’t Wait, Non-Revit Developers! showed BIM specialists how to build their own Revit add-ins with AI. The lesson was simple. Learn the four moving parts (the manifest, the compiled DLL, the entry point and the Revit API), then let AI write the boilerplate. Every example started from public-domain code.

This is great news. The people who understand the work best can now build their own tools. But it ties right back to the panel and to that guardrails slide. When everyone can build, the hard part becomes knowing what already exists, keeping quality up, and making sure a useful tool reaches the whole firm instead of living on one laptop.

A few other things point the same way:

•       Remote MCP and sign-in. One session showed how an MCP server can live in the cloud and let Claude, ChatGPT or other clients sign in once through an OAuth proxy. You get single sign-on, but you own more of the auth logic. That’s the kind of setup we’d need before sharing a BIM One MCP server with clients.
•       The APS business model is changing. New usage caps let you set a hard limit per app with alerts. Pass-through billing is coming for partners in 2026, with customer onboarding in 2027. Anyone building apps on APS, us included, needs to understand who pays for what.
•       Autodesk’s own view. In Every Project Builds the Next, Autodesk described its role as bringing industry know-how and data models, while frontier model providers bring the LLMs. The overlap is tools, engines and user experience. That’s a useful map for where firms like ours can add value.

Here’s my short list for our next R&D cycle:

1. Pilot Dynamo MCP with Autodesk Assistant on a real project graph, and measure the time saved.
2. Batch QA in the cloud. Test Dynamo Switchboard for running standards checks across many client models at once.
3. Smarter deliverables. Offer purpose-built IFCs and Data Exchanges instead of one heavy model.
4. Guardrails first. Every agent we build gets approval gates, identity and a named owner from day one.
5. Watch APS billing. Understand how usage caps and pass-through billing affect our add-ins and client apps.

We won’t do all five at once. We’ll pick one or two, try them on real work, and share what we learn.