Why is AI in architecture harder to use than it should be?

AI in architectural design refers to software that handles design reasoning tasks, such as site analysis, program generation, or massing, from inside the design environment. When those systems connect to the model and the data it holds, their outputs carry forward into the project. When they don't, every suggestion is something you have to manually act on.

That gap is where most of the frustration lives right now.

Ask any architect how AI has changed their work in the last two years. A common answer: starting a project is faster, finishing it is harder. Getting to a first version is easier than it used to be. Getting from that first version to something you can take to a client is where the whole day goes.

The models aren't the bottleneck. They're getting better every year, and architects know it. The problem is structural. AI is probabilistic by nature, which is part of what makes it creative, but it means the output needs to be controlled, not just generated. It needs context, feedback loops that catch bad outputs early, and a place to land that connects to the rest of the project.

Software teams figured this out a few years ago. AI coding tools became genuinely useful once the engineering around the models got good, not just the models themselves. Version control, context tracking, error catching: the scaffolding around the model is what made it trustworthy. But AEC never built that scaffolding.

The industry's answer has been to attach an AI assistant to an existing tool and call it an AI-powered workflow. A chat panel here, a generative button there. But the outputs land outside the model. You read them, decide what to do with them, then go back to the model and do the work yourself. Two workflows with a manual step in between isn't one workflow.

What does architecture need before AI can work properly?

This is the question we kept coming back to when we started building Snaptrude six years ago. And answering it honestly meant going several layers down before writing any AI code.

BIM was supposed to be the connected platform AEC needed. Charles Eastman's original 1975 proposal described a single building model connecting geometry, data, and documentation. What the industry got instead was a collection of powerful tools that barely talk to each other - one for modeling, one for rendering, one for presentations - with people doing translation work between them. The data in the model doesn't know what's in the spec. The spec doesn't reflect what's in the drawings. Every step is a reconciliation.

You can't build AI that works reliably on that. It has no complete picture to reason from, and its outputs have nowhere connected to go.

The foundation we built instead has three properties working together. The geometry is precise and browser-native - not an approximation, not an export, but geometry the AI can read and write without losing information. The data spans the full lifecycle, so the program, the design intent, and the BIM detail all live in the same model rather than migrating between phases. And decisions propagate in real time: change a setback and the buildable envelope updates; adjust the FAR and the massing responds.

Those aren't three separate features. They're one substrate, and without all of them in place, the agents we built on top wouldn't be steerable.

We spent six years on that before the first agent was written. It's the part most users will never directly see. But it's why what comes next is possible.

Where should AI live in an architect's workflow?

The answer we kept landing on: where the model lives.

Before a project touches first design, there's a significant amount of work that happens outside the model. Reading the site. Understanding what the zoning allows. Translating a brief into a spatial program. Distributing departments across floors in a way that makes structural and adjacency sense. On a complex project, this can take days. And it has to be redone every time the brief changes or the client shifts direction.

That's the work the agents address. Not by removing the architect from it, but by making it fast enough to be genuinely iterative.

There are 14 agents now, organized across three phases: Feasibility, Concept, and Schematic. They run on the canvas, connected to the model the architect is already working in. Every output is reviewable before anything is committed.

Feasibility is where the agents are densest, because that's where the uncertainty is highest. Site Analysis reads an imported site and surfaces zoning rules, setbacks, FAR, and height limits. Buildable Envelope constructs the maximum 3D volume those constraints allow. Explore Massing generates feasible building masses within that envelope, with GFA, floor count, and efficiency metrics for each. Generate Program turns a brief into departments with area allocations and adjacency intent. Stack Program distributes those departments across floors. Place Cores handles elevator and egress positioning based on the massing. Pack Program spatially arranges the approved program into the floor plates, producing a layout directly on canvas.

At every step, the architect approves or reprompts before the next agent runs. Nothing moves forward automatically.

Concept goes a level deeper. Generate Spaces expands departments into individual rooms. Size Rooms assigns dimensions to every space. Stack Spaces handles floor assignment at the room level, with more granular adjacency logic than the program stack above it. Layout Spaces runs a solver on canvas-selected geometry, offering multiple arrangement options to review side by side.

Schematic is where the model becomes BIM. Apply Template takes selected spaces and a Snaptrude Group template, generating walls, doors, windows, furniture, and floors at LOD 300 inside each space. Sketch to BIM converts sketch geometry into a coordinated BIM model directly.

The whole chain can run from a blank site to a LOD 300 BIM model while the architect stays on the canvas, making decisions rather than executing them.

This is still a private beta. A limited number of firms are working through it on healthcare, civic, and education projects. The software is rough in places. But the most common thing we hear from people inside the beta isn't a bug report. It's the question of how this work was done before.

What does this change about how architecture gets practiced?

BIM changed the economics of documentation. Drawing sets that used to be 100 pages became thousands of pages with the same number of people. The productivity was real. Most of it went into documentation volume rather than design quality. Buildings didn't get ten times better.

Design exploration is the next thing to get cheap.

Owners who currently see three scheme options can, in principle, expect thirty, at the same cost. Every program iteration, every massing variation, every floor-plate efficiency tradeoff can be explored before a direction is locked. The cost of a wrong early decision falls. The cost of not exploring falls too.

The architect's job in that context is different, not smaller. Less time producing a single direction, more time steering across many. The judgment about what a building should be stays entirely with the architect. The question is how much of the upstream computational work still has to happen by hand.

We're early. The 14 agents cover the front end of the project. There's a lot of the design lifecycle still ahead. But the platform under them is built to support what comes next.

Where we are

The agents are live. The platform underneath them took six years to build. The firms in the beta are moving through early-phase work faster than they were before, not because the AI is doing the design, but because it's handling the computational parts that used to happen manually.

We're building more. If you want to follow it or get involved: snaptrude.com

‍

Frequently Asked Questions

‍

‍