OK Computer

I've spent a lot of time around the people who design and build things, and one thing has always been obvious: the constraint was never talent. This field has judgment in abundance. The architect's sense of what a space wants to be. The engineer's feel for where to pay attention. The GC's instinct for what will actually happen on site.

What they never seem to have enough of is time. Or hands.

Think about how the work goes. The concept, the structural approach, the sequencing call: the real decision often takes a week. Then come months of coordination, code checking, validation, redrawing, chasing answers that live somewhere with no fast way to reach them. The judgment took a week. Everything after took the quarter.

Change who carries the work

For thirty years, the promised fix was Building Information Modeling. And BIM was a real leap: a shared model of the thing being built. But BIM is narrow and runs on a short leash. You direct all of it; when it can't do what you need, you build the workaround. The model records decisions. The running around and the labor stay with the human.

The industry keeps looking for relief in faster, smoother versions of that arrangement. But the fix isn't a better version of the old model. It's changing who carries the work. That's what agent-native BIM means: agents living inside the model, taking on the toil, while judgment stays exactly where it belongs, with you.

Picture it. The client calls Monday morning: the ground floor program changed, retail is now a clinic. That one sentence used to mean three weeks of rework. Instead, you start sketching the new plan, because that's where your judgment lives, while an agent pulls what a clinic demands: occupancy, plumbing loads, accessibility clearances, parking ratios. You set the priorities; an agent lays out a dozen clinic plans against them overnight, and the drawings, schedules, and sheets update with whichever direction you pick. By Thursday you're presenting options, not apologizing for delays. You made every decision that mattered. You just didn't have to carry every consequence by hand.

Why not Revit + MCP + Claude

The natural question, and a fair one: why a new platform? Why not Revit, plus MCP, plus Claude? The most technical firms are already trying it, and I'd encourage the experiment: you'll get something impressive in an afternoon. But an impressive afternoon is not a dependable teammate, and the gap between the two is the whole job. Let me be specific, because "you need a new platform" is exactly what a founder says when he wants to sell you one.

Every legacy application in architecture is built on one assumption: one person, in one model, executing one command at a time. It's baked into how the data is stored, how the software performs, what it costs, and who it expects at the keyboard. Right for its era. But agents break it in four places at once:

• Context: An agent is only as good as what it can see, and it needs the whole project in view: model, drawings, specs, constraints, intent. A legacy tool exposed through MCP shows it a few functions through a straw. You can't hand an agent a keyhole and ask it to reason about the room.
• Performance: A person clicks a few times a minute. A system of agents works continuously, in parallel, many things at once. Software paced for one set of hands can't be rescued by a faster chip.
• Cost and scale: Continuous intelligence has a real price, and every inefficiency gets multiplied by every agent, every hour. Get it wrong and the cost per project lands where no firm would pay: that's how promising technology ends up living permanently in a demo.
• Collaboration: The whole point is humans and agents in the same model at the same time, and single-operator software can't grow into that. Old tools assume one driver. Motif Design assumes a team, some of whom aren't human.

Bolt an agent onto software built on that old assumption and the intelligence stays at the edge, with the human still connecting everything in the middle. The same arrangement with a nicer sidebar.

What we had to build underneath

So what does a platform built for this look like? It starts with data. Agents need a database that doesn't fight them. AEC has too many disciplines, tools, and geographies for one rigid schema, and agents need flexibility even more than people do, because an agent reasoning about a building invents as it goes: new objects, extended ones, properties nobody anticipated. If the data model only accepts categories defined years ago, an agent spends its day being told no.

Flexibility counts for little, though, if the agent sees only a piece of the building. A real building is enormous, and a browser gets a sliver of the machine's memory, so the old workaround was to cut the building into parts: sub-models, worksets, linked files. That fragmentation has taxed the industry for years, and it's worse for agents, which must reassemble the building before they can think. So we don't split the building to fit the browser. The full model stays intact, relationships and all, on machines that can handle it, with distributed compute doing the heavy lifting. Your browser gets a fast window onto that model, and the agent reasons across the whole building because the whole building is there.

That's what agent-native BIM requires underneath: a data model agents can work in, intelligence at the core, humans and agents in one shared space, the common base already laid. You shouldn't have to build any of that. What goes on top is where your firm differs: your standards encoded, your expertise packaged into skills your agents can use, the workflows nobody else has, because nobody else does the work quite the way you do.

It's already happening. One of the world's leading engineering firms built its own open-source object model, refined over years of real practice, and it runs in Motif today with agents working on it. We didn't make them convert it to our data model. You shouldn't have to convert yours either.

We did the hard work to get this right, for the people who are going to build the world with it.

‍