The final product of our work is always the building. It is what the client sees, what gets handed over, and the only thing that remains once the project ends. But whether that building comes out right, on time and within the agreed budget, depends largely on two blocks of work that happen outside it — and that rarely get the attention they deserve.
The first is everything that happens before the first crew shows up. The takeoff, the estimate, the scope definition, the initial schedule, the subcontractor buyout. It is the stage where the most expensive decisions to reverse are made, and where mistakes do not show up right away. A miscounted quantity in the takeoff, an ambiguous scope, or a badly sequenced schedule activity produces no symptom in the first month. It surfaces later, once contracts are signed and material is bought — and by then fixing it costs several times what catching it early would have.
The second block runs alongside the build: daily logs, the photo record, change orders, the information the client receives week to week. It is easy to read as administrative work, but its real function is different. That flow of information is what lets you compare what is happening in the field against the schedule and budget you built before starting. Without it, it is not that there are no problems — it is that you find out about them late.
It is worth being precise here, because the nuance matters. Of course there are overruns and delays that originate on site: an unforeseen condition during demo, a subcontractor who does not deliver, a change the client asks for halfway through. That is part of the trade and always will be. What determines the outcome is not that they happen, but the ability to spot them early, size them with data and absorb them in an orderly way. And that ability depends directly on how well built those two layers are: preconstruction and tracking.
That is where artificial intelligence is adding real value today. Not in building, but in holding up the information infrastructure everything else rests on.
What we learned using commercial platforms
I work as a Project Administrator at Drake Construction, a high-end residential builder in Southern California, coordinating between the office, the field, subcontractors and clients.
Like almost every company in the sector, we run on commercial construction management platforms. They are mature, well-built products, and for most companies they handle the day to day without trouble. I have no complaint about that, and I do not think that is the debate.
What we kept running into is something else. Software built for thousands of companies has to assume an average way of working: the order in which a change order gets approved, how an estimate is structured, what the client sees and when. When your operation matches those assumptions, the tool performs very well. When it does not, you are left with a set of processes the platform neither covers nor lets you add. And it almost never matches completely, because every company built its way of working over years and for valid reasons. It is not that the platform is bad — it is that it is not built to your measure, and it will not let you adjust it either.
That gap always existed, and was always solved the same way: by hand, with duplicated work, with files living outside the system. It was accepted as part of the trade.
What changed is that today, with the AI tools available, a small company can build its own solutions for the processes no platform covers. That used to require a development team and a budget no builder our size was ever going to spend on software.
We took that road and ended up building our own platform, today Drake Hub. I do not tell this as a recommendation. For most companies it is not one, because it requires someone to sustain it over time. I tell it for what we learned doing it, which is the part I think actually transfers.
And that lesson is not technical. These tools made it very easy to start building, and building for its own sake is worth nothing. The starting point is not what the technology can do, but what hurts: where information gets lost, where work gets repeated, at what point someone finds out late about something that was already known. Everything we added came from a pain point we had already identified, not from a feature that looked good in a demo.
The interesting part is that, having been born from our particular problems, it ended up solving things common to the whole industry. Your own problems are rarely as unique as they feel.
How the market is responding
What is notable is that the large platforms are arriving at similar conclusions right now.
In late July it made generally available a set of agents operating on exactly those two layers: drafting RFIs from plan analysis, generating daily reports from the superintendent’s photos and voice notes, and reviewing the schedule for incorrect sequencing and delays. In August it releases Skills, whose stated purpose is for the AI to absorb each company’s particular processes and standards rather than operating on generic criteria. It is an explicit acknowledgment that fit, not functionality, was the problem to solve.
In late July it acquired an artificial intelligence company. The announcement suggests what was acquired was mostly the team rather than a product in operation: two profiles with Amazon and Google backgrounds joining in product and engineering roles. It signals they are building the capability in-house, and also that they are at an earlier stage.
One detail of Procore’s implementation is more informative than the whole announcement: according to their own documentation, the agents can create items, but not modify or delete them. That restriction says quite clearly what level of autonomy the industry considers prudent today.
What the data says about where it is being applied
The available figures confirm where the value comes from, and they are fairly consistent with one another. When the AGC asked contractors which areas they are applying artificial intelligence to, the most frequent answer was not estimating or design, but administration and office work.
The layer that looks secondary is where adoption concentrates, because that is where the return shows up fast and with low operational risk. Scheduling is the opposite case: only 16% of contractors use AI or automation in their schedules, and 60% state they have no intention of doing so. It is the function most present in sales demos and the least adopted in practice.
On overall progress, the Dodge Construction Network study published late last year offers the most revealing contrast.
The rest are not idle: 40% have already allocated budget and slightly more than half are actively evaluating. But the distance between recognising the potential and changing the operation remains considerable.
One last figure, from a small sample but very illustrative of this article’s central point: barely 3.7% of project management professionals use the AI features built into their own platform, while close to two thirds reach for general-purpose tools outside the system. The demand exists. What people prefer is a tool they can explain their own context to, over a feature whose behaviour was already decided for them.
What I have come to understand
When Procore announces that its AI will absorb each company’s processes and standards, it is saying exactly what we learned the long way: the tool has to understand you. What worries me as a contractor is not what worries the one next door. We can run the same software, be the same size, and need different things from it. For a long time the industry’s answer to that was to ask each company to adapt to the program. What is changing is that now it can go the other way.
The technology is within almost anyone’s reach; what is scarce is the judgment to aim it.
That is why I think the question to start from is not which tool to buy, but what you want to solve. It is an uncomfortable question, because it forces you to look at your own operation honestly and admit where time or information is being lost. But it is the only one that avoids ending up with impeccable features nobody uses.
In the time we have been applying it the results have been good, and what surprised me most was not how much time is saved, but understanding what problem we were actually solving. Almost everything we improved was, underneath, a communication problem. Construction has gaps there everywhere: information that exists but does not arrive, decisions made verbally and never written down, clients who find out late about something the field knew a week ago. When that layer works, the subcontractor knows when they start, the client knows where their house stands without having to call and ask, and we catch a delay while there is still room to fix it.
That, for me, is what makes all of this worthwhile: not the technology itself, but the fact that the information reaches everyone involved in a project at the same time, without anyone having to chase it. Artificial intelligence is today the most practical way to get there, and that is why I think it has to be understood properly: not as one more feature of software you already pay for, but as the chance for tools to finally fit how each of us actually works.
None of this is spectacular. That quantities are right from the first estimate, that a change is documented the day it is agreed, that real progress can be checked against the schedule at any moment. These are things you cannot see in the finished building, but they separate a project delivered as promised from one that is not. And they make the work better for everyone inside it: for us, for the subcontractors and for the client.
We are only getting started, and I think that is good news. If you are working on this inside your own company, I would genuinely like to hear about it.