Internal AI hackathon in a BIM team: what we learned connecting Claude to Revit and Blender

Since August our BIM production team has run a weekly internal AI hackathon. Sixty to ninety minutes, one live problem from a real project, one person driving, the rest asking awkward questions. We have covered Speckle, cut-and-fill in Revit, a readable BIM execution plan, Dynamo for data work and a pyRevit tool that draws charts. The session this article is built on was the first where the whole agenda was artificial intelligence: connecting Claude Code to Revit through a Model Context Protocol server, trying the same in Blender, and working out which plugins, skills and permissions a team needs before an AI agent touches a model.

This is written for BIM managers and digital leads who are being asked to "do something with AI" and would rather see what breaks before they adopt AI on a live project. AI adoption in construction is slower than the headlines, for reasons this article takes seriously. We cover the format, the setup, what the agent did well, where it failed, and the rules we now apply.

Most companies run a hackathon once, with pizza and a jury, and nothing changes afterwards. A weekly hackathon for engineering teams is less a coding contest and more a rapid business-value discovery programme. The theme is always a current pain point from a live project, so the prototype is used the following week or dropped. Whoever had the problem presents, regardless of title, so the expertise stays in the team instead of with a consultant.

Four rules keep it useful:

• One real problem, one owner. A modeller brings the tedious workflow that cost them an afternoon and the group tries to solve it live. Impact over perfection.
• Keep the stack accessible. Claude Desktop and a plugin, not a development environment. The barrier to entry decides who joins, and the mix matters: modellers, the information manager and the person who writes our marketing all take part. That is where the cross-functional ideas and the stronger internal network come from.
• Every session leaves a trace. A written note, a script in the repository, or an article like this one. Hands-on experience that is not written down disappears in a month. A senior colleague stays on call during the week for anyone finishing what the session started.
• Measure what reaches production. We count prototypes that made it onto a live project, not demos. Without that funnel the ideas stay unused.

That format is the right vehicle for AI upskilling: people learn a technology when it fixes their problem, not when a training slide tells them the future is agentic. It also shows who your AI champions are, and because knowledge is shared in the form of notes and scripts, more people in the team use automation instead of one developer holding it.

Large language models know a great deal about the Revit API from their training data, and nothing about the model open on your screen. Traditional AI models answered from what they were trained on. Until recently the only bridge to your unique data was copy-paste: ask the AI assistant for a script, paste it into pyRevit or Dynamo, read the error, repeat. Most AI applications in construction are still that chat window.

The Model Context Protocol (MCP) is an open-source framework published by Anthropic that replaces that loop. An MCP client such as Claude Desktop, Claude Code or Cursor connects to one or more MCP servers. Each server describes its tools as JSON objects: list the selected elements, create a level, read a parameter, query a database. The model decides which tool to call and in what order, the server executes it against external systems, and the result comes back as context for the next step. That is what turns a chatbot into an AI agent: real-time access to your data and the ability to complete multistep tasks on it.

MCP does not replace the Revit API; it sits on top of it, as it does on databases, file storage and other external tools and services, so one integration serves every compatible client, and the same solutions carry over from one tool to the next.

MCP servers for Revit and Blender

The open-source server we used has three parts: a TypeScript MCP server that talks to the AI client, a C# add-in inside Revit, and a command set that executes Revit API calls over a local WebSocket. It lists around 25 tools: create grids, levels, rooms, dimensions and structural framing; colour, select, hide and tag elements; export room data, material quantities and project statistics; and send C# code straight into Revit. It supports Revit 2020 to 2026 under an MIT licence. Commercial connector platforms advertise several hundred Revit API tools behind one Claude Desktop connection, running locally on the user's machine.

Blender MCP is the community equivalent, not a Blender Foundation product. It opens a socket server inside Blender and lets the model create and modify objects, assign materials, pull free assets from Poly Haven, export GLB or FBX, and execute arbitrary Python. Its README warns that arbitrary Python can be dangerous and tells you to save your work first. The same applies to Revit, where the equivalent tool sends C# into a live session.

The honest account of our first all-AI session is that installation ate half of it: Node.js, the add-in, allowing it on Revit start-up, enabling the right commands in the plugin settings, and moving the whole team onto one Claude Team plan so that organisation settings and permissions were the same for everyone. Budget the first session for setup and treat that as the lesson.

Then the test. The brief, in plain language: an empty project with grids and levels; model a simple reinforced-concrete frame, columns and beams, with the parameters we use for coordination; plan first and do not ask whether to proceed at each step. Ten minutes later we reviewed the result.

What worked: the agent produced a plan before touching the model, created levels and grids correctly, placed structural framing and gave real-time updates on each tool call, so we could follow what it had done. That transparency mattered more than the speed. What did not: wherever the brief left a gap, the model guessed. Family types, naming, which parameter carries the mark, how to coordinate dimensions with the architectural model. Even the most advanced AI models fill those gaps confidently, and confidently wrong is the expensive kind of wrong in a BIM project. The verdict in the room: a fast junior who needs a complete brief and a reviewer, which is how we treat a new modeller too.

Blender was faster and more forgiving, because a mesh has no parameters to get wrong. That is exactly why it matters less to us: the information we are paid for lives in Revit.

Plugins, skills and memory for the AI assistant

Claude Code packages instructions and scripts as plugins and skills that an organisation publishes and makes available for install across the team. We published an internal skill set: our naming convention, the parameters every structural element must carry, the review checklist. It is a small knowledge base of our standards that the AI assistant reads before it acts, and with it in place the agent made fewer guesses. The agent's memory, which carries project conventions between sessions, helped in the same way and raised the first governance question: who decides what the agent remembers about a client's project, and where that memory lives.

Multi-agent setups, where one model plans and several execute, already exist in the Blender community. We kept to one agent per task: orchestration adds AI capabilities and halves accountability, because when two models disagree nobody can say why the beam is in the wrong place.

An earlier session surfaced two concerns that shaped everything afterwards. A coding agent with broad permissions can misread a prompt and send client data to the wrong recipient. With the right tool connected it can also drop a database or overwrite a model because it took "clean this up" literally. Neither risk is hypothetical in a team that connects AI tools to Google Drive, a project database and Revit on the same machine. Ethics and governance belong in the first session, not after the first incident.

Data security for AI agents in a BIM team comes down to rules we now enforce:

• No MCP server with write access to a live client model. Agents work on a detached copy. Prove it there first. Publishing back is a human step.
• Permissions set to ask before any write or script execution. "Do not ask" is for a sandbox, not a project folder.
• Appropriately licensed tools only. MIT-licensed open source is fine; an educational licence is not, on commercial work; a free commercial connector still needs a read of its terms on where data goes.
• Backups, monitoring and a log. Save before every session. Keep the agent's action log with the model, the way a transmittal records who sent what and when.
• A named reviewer signs off. Accountability does not transfer to the software.

AI governance in simple terms is that list: a framework for who may use which AI systems, on which data, with which permissions, and who checks. Healthcare and finance treat patient and account data this way by default. Construction holds structural safety data and, more often than people admit, personal data in shared parameters and issue logs. GDPR applies to a Revit model as much as to a CRM. None of this blocks innovation; it is what lets businesses deploy agents on real projects instead of demos.

The question our team keeps returning to is whether Dynamo is dying. Our answer after eight weeks: no, it is changing jobs. A Dynamo graph or a pyRevit script costs nothing to run the fiftieth time and does the same thing every time, which is what BIM automation needs on repetitive production processes. Its price is maintenance: the Revit API changes every year, old packages stop loading, and somebody has to keep the scripts up to date.

An AI agent is the opposite. It is excellent at one-off, complex tasks with a complete brief, and at writing or updating the scripts themselves. Connected through MCP to the Revit documentation, it makes fewer API mistakes than a model working from memory, because it can research the current method instead of guessing. It is expensive to run repeatedly and non-deterministic. So the division of labour is simple: AI develops and maintains the automation; the automation runs the production. The benefit: scarce resources, senior modellers and developers, focus on the specific needs of the project rather than on boilerplate.

Pick defined problems with a measurable outcome, the ones that already cost you time:

1. Model QA through an MCP server. Ask the agent to list every element missing a required parameter and report before fixing anything.
2. A pyRevit tool written with Claude Code. Something small: a schedule export, a view-naming check.
3. Translating family parameters. A good test of where general-purpose AI models fail on domain vocabulary.
4. Cut-and-fill or quantity take-off in Revit, with the agent explaining the API calls as it goes.
5. A readable BIM execution plan. Restructure a 60-page document so that modellers only read the chapters that concern them.
6. Data to Excel and back with Dynamo, then the same task with an agent, and compare cost and repeatability.

Run each for ninety minutes, write down what happened, and decide the following week whether it goes into production. The challenge is not finding ideas; it is finishing the write-up.

FAQ