Myers & Chapman

Ryan Turner is Construction Technology Manager at Myers & Chapman, a commercial general contractor based in Charlotte, North Carolina. Before entering construction, he spent roughly 15 years helping organizations translate business needs into technology products and solutions across banking, healthcare, and insurance. Today, he leads technology strategy, systems integration, AI governance, and digital process improvement for the company.

Learning the Economics of AI

The first AI economics problem I saw up close surfaced before I entered construction.

Before construction, I spent roughly 15 years working in software product roles across banking, healthcare, and insurance. At my last company, a small team of product-minded employees began using AI-assisted development tools to rapidly prototype replacements for aging internal platforms. These were not traditional developers, yet the amount of software they could produce changed dramatically.

It did not take long for the economics to get leadership's attention. As experimentation expanded, so did questions about what we were spending, which initiatives were driving it, and how that cost should be understood.

“Construction has spent generations learning where work happens and what it costs. We should not lose that discipline just because the next worker happens to be software.”

I moved into commercial construction nine months ago, first as an assistant project manager before transitioning into construction technology leadership. That gave me an early look at project delivery before I started evaluating technology from the enterprise side. Our AI use today is still more assistive than agentic. I have tested AI against real project information, including using Procore’s AI-powered Submittal Builder against a 642-page project manual. Today, that kind of activity is occasional and easy to absorb inside the broader cost of the platform.

The economics become more interesting when that activity stops being occasional.

Imagine an agent checking every incoming submittal against that manual. Another monitors RFIs. Another reviews schedule movement. Another examines contract language, drawing revisions, or potential change exposure. None of those actions need to cost much individually. But agents do not work once. They can work every time the project changes.

The Job Costing Logic of AI

Construction already has a discipline for understanding this kind of activity: job costing.

Two projects I am close to have similar submittal counts, 110 on one and 127 on another. One is new construction. The other is a multi-story historic renovation. Anyone in construction knows why those jobs can create very different workloads.

AI consumption will too.

If agents take on a meaningful share of project-specific work, a complicated project could consume several times the digital resources of a simpler one. If that usage disappears into a companywide subscription or pooled credit balance, technology leadership may know what the company spent without knowing which jobs generated the work.

How a contractor accounts for those costs is a separate decision. The management principle is simpler: project-triggered digital work should remain attributable to the project that triggered it.

Otherwise, the cost of production starts separating from the work that created it.

That matters beyond the technology budget. Contractors use project history to price future work, compare performance, understand margins, and allocate resources. If meaningful production shifts from people to AI while the associated consumption remains pooled elsewhere, job-level economics can become less representative of the work actually performed. A simple project can effectively subsidize a complex one in management reporting, even if nobody intended it.

Measuring the Work Behind AI

Vendor credits and token counts do not solve that problem. They measure technology consumption, not construction production.

I want to know what it cost to screen 100 RFIs, what automated submittal review cost on this project, and what contract analysis consumed. Did that activity replace meaningful project effort, identify risk sooner, or just create more material for someone else to review?

There is also a counterintuitive dynamic here: as AI gets cheaper to use, companies may spend more because they find more work for it to do. Gartner recently gave this dynamic a name, the Inference Paradox, and predicts inference costs per agentic workflow will rise more than fivefold through 2028.

Construction should pay attention because project workloads are anything but uniform.

Consumption-based AI is already entering construction software. Procore’s Digital Coworker offerings, for example, use a credit-based model for AI activity, and its Control Tower reports consumption by agent, project, or team member. That is not a criticism of the model. It is evidence that construction technology economics are changing, and that the tools for attribution may arrive before the management discipline around them does.

The discipline should start early. Project-facing AI usage should be attributable to a project. Technology procurement should require enough usage detail to make that possible. Any automation we scale should have a meaningful unit of work attached to it, not just a vendor credit balance.

Within a few years, I expect project teams to carry a budget for digital production much like other project resources. Not because AI is literally labor, but because it will increasingly perform work that once required project labor.

Construction has spent generations learning where work happens and what it costs. We should not lose that discipline just because the next worker happens to be software.