Poor data and miscommunication were on track to cause $31.3 billion in US construction rework in 2018, according to the Construction Disconnected study FMI ran with PlanGrid, which Autodesk later acquired. The same research pinned 48% of all US rework on those two causes. AI agents can win back a real share of that money. Only the boring share, though: the errors a rule, a schedule or a spreadsheet comparison would have caught. And they do it best when you point them at one project stage at a time, not at the whole building.
I’ve spent most of the last decade building software for AEC teams. Revit add-ins, document pipelines for spec writers, coordination dashboards that BIM managers ignore until the week before a deadline. The pattern repeats on almost every job I’ve seen. The expensive mistake rarely involves a bad design idea. It involves a door schedule that says one thing and a hardware spec that says another, and nobody holding both open at the same time.
Agents pay off on checkable errors, not on taste
I call the target checkable errors: mistakes where the correct answer already exists somewhere in the project record, and a person simply didn’t compare two documents in time. Room area against the program. Corridor width against the code. A spec section against the submittal that claims to meet it. Taste, intent and the hundred small judgment calls behind a good building aren’t on that list.
An AI agent, in plain terms, is software that reads your project files, runs a defined check, and then reports back or takes a small action within limits you set. That’s narrower than the conference keynotes suggest. It’s also more useful than it sounds, because the volume of checkable errors on a typical project is huge and mostly invisible until the field finds it.
The research on design-side error is old, but nothing better has replaced it. In a 2014 McGraw Hill Construction SmartMarket Report, respondents said design omissions occur on about half of all projects (54%), and only 1% of owners said they had ever seen a perfect set of drawings. The Navigant Construction Forum’s April 2013 study of 1,362 projects counted an average of 796 RFIs per project, at about $1,080 each to review and answer. Multiply those two figures. That’s roughly $860,000 of RFI handling on an average project, before anyone pays to fix the thing the RFI was about.
Navigant didn’t sort those RFIs by whether a machine could have caught the underlying problem. My own guess, from reading RFI logs on projects I’ve supported, is that a sizable slice were plain document conflicts, the kind a patient reviewer finds in minutes. Treat that as a practitioner’s estimate, not a finding from the study.
So the tooling question is real. Some firms buy point products. Some build in-house with a BIM manager who codes on weekends. Others bring in outside AI agent development services to wire a checker into the exact folder structures, naming conventions and model standards they already use. Whichever route you take, the stage-by-stage ledger below is the scoping document I’d start from.
Programming breaks quietly, and the bill arrives in design development
The typical costly error at this stage is program drift. The client signs off on a brief with a fixed list of rooms, areas, and adjacencies. Over schematic design, rooms merge, net areas shrink, and an adjacency requirement buried on page 38 of a PDF stops being anyone’s concern. Then a user group meeting in design development reveals the clean utility room is on the wrong floor, and the fix means redrawing, not resketching.
What an agent can check: room counts and net areas against the approved program, every time the model changes. Room data tools have done a version of this for years, and the Area panel in dRofus, for example, compares programmed room areas and counts against the designed spaces in an IFC model. The agent adds the part people skip. It runs the comparison weekly without being asked, flags drift beyond a tolerance you set, and posts a two-line note to the project channel. It can also read the written brief and pull out explicit requirements like ceiling heights, adjacencies, and equipment lists, each tagged with its source page, so they stop living only in a PDF.
What it can’t: tell you whether the program is right. If the owner’s facilities team underestimated storage by a third, the agent will faithfully hold you to the wrong number. Programming is a conversation with people who don’t yet know what they need. That conversation still belongs to the architect.
Schematic design is where the big promises show up
Schematic design attracts the boldest claims about AI. The loudest one goes like this.
AI will design the building. Give it two years.
That’s the line you hear at every conference panel, usually from someone selling a massing generator. It won’t, at least not in any sense that matters for liability. Producing fifty massing options is easy now, and plenty of tools do it. Choosing the one that fits a neighborhood, a budget, a structural grid and a client’s internal politics is a different job. And when it goes wrong, the consequences land on a licensed professional’s stamp, not on a model’s training data.
The typical costly error in schematic design is quieter than a bad massing study. It’s a scheme the client loves that busts the floor area ratio, a height limit, a setback, or the egress math for the occupant load. Found after client approval, that error costs a redesign cycle and some trust.
What an agent can check: zoning arithmetic and early code questions. From the massing model, it can compute gross floor area per level, FAR, height to the defined datum, and a first-pass occupant load, then compare them with the zoning summary your team approved. For code lookups, UpCodes Copilot links each answer to the exact adopted code section it references and remembers the project’s jurisdiction and code year, which is the behavior you want from any agent in this role. Jurisdictions are moving too. In July 2025 the International Code Council announced a collaboration with Archistar, whose eCheck tool automates code compliance checks and was piloted with 11 US cities.
What it can’t: interpret an ambiguous code section, predict how a planning director reads a zoning overlay, or argue a variance. It also can’t judge whether the scheme is any good. That part was never checkable.
Design development is where two models disagree and nobody notices
The typical costly error here is coordination. A duct runs through a beam. A door swing eats into the maneuvering clearance on the pull side. A ceiling height that worked in section fails once the sprinkler mains go in. Found in the field, each of these becomes a change order, and somebody argues about who pays.
What an agent can check: clashes and clearances, which already have good rule engines behind them. In Autodesk Construction Cloud, Model Coordination detects clashes automatically when RVT, DWG, NWC or IFC models are added to a coordination space with clash detection turned on. Solibri runs rule-based checks on accessible routes, door maneuvering space, ramp slopes and landings.
The agent’s real value sits on top of those engines. Raw clash runs produce thousands of hits, and most of them are noise, like insulation grazing a hanger. An agent can group the hits, drop the ones under tolerance, route the rest to the discipline that owns them, and draft the issue with a screenshot. On one coordination tool I helped build, that triage step was the feature BIM managers asked about first and used the most.
What it can’t: decide who moves. Dropping the ceiling three inches or rerouting the duct is a cost, schedule and design decision. Neither can it tell you whether a technically compliant restroom actually works for a person in a wheelchair. Rule engines check dimensions. People check experience.
Construction documents hide the error between the drawings and the spec
The typical costly error at this stage is a conflict between documents that are each correct on their own. A wall type on A-501 calls for a gypsum board the spec section doesn’t list. A keynote points to a detail that was deleted two revisions ago. A door hardware set references a product the manufacturer dropped last year. None of these looks wrong on a single sheet, but each one, multiplied across a large set, feeds the RFI count from the Navigant study.
What an agent can check: cross-reference integrity. Every callout should point to a detail that exists. Every keynote should match a spec section that’s in the book. Every tag on a plan should match a row in its schedule.
On the spec side, Autodesk’s AutoSpecs can generate a submittal log from a project spec book in minutes, compare spec book versions to show what was added, deleted or modified, and flag potentially missing submittals based on historical project data. An agent that reads both the drawing set and the spec book, then hands the project architect a conflict list two weeks before issue, is the single most valuable thing in this whole ledger. Not glamorous. Valuable.
What it can’t: decide which document governs when the two disagree, approve a product direction, or understand design intent that was never written down. The contract’s order of precedence may say the specs win, but whether that’s the right outcome for the building is still a human call. And it can’t sign the set.
Construction administration is the agent’s home turf
The typical costly error in CA is slow or careless paperwork. An RFI sits for two weeks while the contractor works around it. A submittal gets stamped without anyone checking the fire rating against the spec. Small misses here turn directly into delay claims and change orders, because the building is going up while the question waits.
What an agent can check: quite a lot. On the contractor side, Procore announced an RFI Creation Agent on October 15, 2025 that drafts RFI content and searches project documents for answers.
On the architect’s side, an agent can pre-review a submittal against its spec section. Does the product data name a listed manufacturer? Does the STC rating, fire rating or wind load meet the specified minimum? Are the required items in the package at all? It can also spot an incoming RFI that’s already been answered in a previous response or an ASI, which happens far more than anyone admits.
What it can’t: approve anything. Submittal review carries professional responsibility, and an “or equal” substitution is a judgment about performance, warranty and risk that no checker should make alone. It also can’t read a tense site meeting, or know that this particular superintendent writes vague RFIs when he’s behind schedule. Experienced CA staff know that. Software doesn’t.
Pilot one agent on one stage
Here’s the whole ledger on one page. Use it to pick a starting row, not to buy five tools.
| Stage | Costly error | Agent check | Human judgment still needed
|
|---|---|---|---|
| Programming and brief | Program drift: rooms, areas and adjacencies wander from the approved brief | Weekly room count and net area comparison against the program, requirements pulled from the brief | Whether the program itself is right |
| Schematic design | Scheme busts FAR, height, setbacks or egress | Zoning arithmetic from massing, code lookups tied to adopted sections | Code interpretation, variances, design quality |
| Design development | Clashes and clearance violations found in the field | Clash triage, accessibility clearance rules, issue drafting | Which discipline moves, whether a space works for people |
| Construction documents | Drawing and spec conflicts, dead references | Callout, keynote and schedule cross-checks, spec version comparison | Which document governs, design intent |
| Construction administration | Slow RFIs, submittals that don’t meet spec | Submittal pre-review against spec values, duplicate RFI detection | Approvals, substitutions, field relationships |
Most firms I’ve worked with try to start everywhere at once and end up with a pilot nobody trusts. Start small instead.
- Pick the stage that already hurts. Tag the last two years of RFIs and change orders by the stage where the error started, and begin where the pile is tallest.
- Write the check as a rule before you buy anything. If you can’t state it as “this must match that within this tolerance,” an agent can’t run it either.
- Run it in shadow mode for one full phase. The agent reports, people act as usual, and at the end you compare what it caught with what your QA review caught.
- Count false alarms as carefully as catches. A checker that raises forty flags a week gets muted by the second Friday.
- Put a named person on every flag. The agent drafts and the licensed professional decides, and the log shows who did which.
Let the software compare the documents, and keep the architects for the decisions that can’t be compared to anything.
