☰
Every leadership team in this industry is under pressure to show an AI agenda. Boards ask where agents are being deployed. Competitors announce pilots. Vendors promise transformation within a quarter. That pressure is legitimate — AI is now consequential enough that no company can afford to leave its adoption to chance or to individual employees experimenting on their own.
But a growing number of organizations are answering the wrong first question. They are asking where can we deploy an agent before asking what business problem are we trying to solve. They are compiling lists of use cases before agreeing on which outcomes matter most. And in some cases, they are treating the number of AI initiatives launched as evidence that transformation is underway.
It isn't.
Adoption and impact have decoupled. In McKinsey's 2025 global AI survey — fielded across nearly 2,000 organizations in 105 countries — 88 percent of respondents said their organizations were regularly using AI in at least one business function, up from 78 percent a year earlier. Enthusiasm for agents is climbing too: 62 percent of respondents said their organizations were at least experimenting with AI agents. Yet only 39 percent reported any enterprise-level EBIT impact from AI, and most of those attributed less than five percent of EBIT to it. By McKinsey's own definition of a high performer — meaningful EBIT impact plus self-reported significant value — only about 6 percent of organizations qualify.
That gap is not primarily a technology problem. It is a sequencing problem. Companies do need an AI strategy — a point of view on governance, talent, architecture, and investment. But that strategy has to sit inside a larger system for deciding which business problems deserve investment, what capabilities those problems require, when AI is the right tool for the job, and who should build, buy, or co-develop the solution.
Every major technology cycle produces a version of the same mistake. A new capability becomes visible. Vendors and internal innovation teams start discussing its potential. Leaders worry about falling behind. The company then organizes itself around the technology rather than the problem — cloud strategies, blockchain strategies, digital-twin strategies, and now AI and agent strategies.
The mistake isn't building expertise in the technology. It's letting the technology category set the transformation agenda. When a company issues a mandate to "identify fifty agent opportunities," the shape of the answer is already determined. The resulting list tends to favor work that is visible, repetitive, text-based, technically accessible, and easy to demonstrate inside a short pilot.
Those qualities make an opportunity feasible. They don't make it important.
An assistant that summarizes project meetings is useful. An agent that drafts a first pass at an RFI saves time. A chatbot that retrieves internal standards improves access to knowledge. None of that is wrong. But none of it is automatically among the decisions with the greatest influence on a project's or a portfolio's economics.
For a developer, the higher-consequence questions look more like: Should we acquire this site? Can the proposed program hit its return targets? Is the design commercially efficient, or are we carrying risk that surfaces only after capital is committed? Should the project advance to the next capital gate?
For a contractor: Is the design resolved enough to price and build? Where is constructability risk accumulating? Which scope packages are likely to generate coordination failures downstream? Is the project actually ready to mobilize?
For an architect or engineer: Is the current design meeting the client's real performance and financial objectives? Which decisions being made today are creating cost or coordination risk three phases from now? What should the team investigate before the next submission?
Those questions are harder to automate than a meeting summary. They depend on context, domain judgment, structured data, rules, geometry, and economics — often several of these at once. But they are frequently worth far more than the tasks that show up first on an opportunity list, which is exactly why an AI agenda can't be built by cataloging tasks. A company first has to decide where better intelligence would actually change a business outcome.
The correct sequence starts with the business and moves toward the technology, not the other way around.
Most companies experiencing the adoption-impact gap are starting at the seventh or eighth level. They decide they need agents, select tools, invite business units to propose use cases, and only then try to connect the resulting projects back to strategic priorities. The sequence works better run in the other direction.
Business strategy defines where value actually matters. A developer chasing higher risk-adjusted returns will prioritize sharper acquisition discipline and faster design evaluation. A contractor chasing margin stability will prioritize earlier risk detection and tighter coordination between design, procurement, and field execution. Without that clarity established first, nearly any AI use case can be made to sound worthwhile — which is precisely the trap.
This does not diminish the case for an AI strategy. It gives that strategy a purpose. Companies don't need less AI strategy. They need it positioned correctly — as the seventh step in an eight-step system, not the first.
Innovation teams often get measured by activity: pilots launched, workshops run, proofs of concept completed, vendors evaluated. Those numbers are easy to report and easy to mistake for progress. They are not the job.
The job of an innovation function is to translate strategic priorities into new organizational capabilities — and, just as often, to say no to opportunities that are interesting but not consequential. That means diagnosing problems rather than collecting them, distinguishing symptoms from root causes, and mapping the decisions in the business that carry the most weight. It also means knowing when a problem isn't ready for a pilot yet — because the data doesn't exist, the workflow hasn't been agreed on, or nobody owns the outcome.
Innovation should not own the mandate to find uses for AI. It should own the harder mandate of determining which new capabilities are worth creating.
The hierarchy tells leadership where to look. It doesn't explain why an employee two levels down the org chart would choose a harder, riskier capability bet over a tool that works tomorrow with no onboarding, no procurement fight, and no chance of a visible failure. Left to its own devices, individual adoption behavior will rationally drift toward exactly that — and that profile describes a task-level opportunity almost by definition, not a capability one.
This isn't primarily a communication problem, and it doesn't get solved with a town hall announcing that "AI is a priority." It's an incentive problem. If an organization quietly rewards visible, low-risk wins and treats a well-reasoned initiative that didn't pan out the same way it treats a shortcut nobody bothered to vet, people will optimize for the safe choice no matter how good the strategy document is.
The evaluation framework later in this piece can end up reinforcing this by accident: if "time to value" is read as a hard gate rather than one input among many, it quietly excludes every capability-level bet before the rest of the framework gets a chance to weigh in.
The fix has to come from the top, and it has to be visible, not just declared. McKinsey's 2025 research found a direct link here: organizations qualifying as AI high performers were three times more likely than others to say senior leaders demonstrated strong ownership of and commitment to their AI initiatives. In practice that means funding at least one capability-level bet that won't show results this quarter and saying so publicly, and distinguishing in performance conversations between a rigorous initiative that didn't work and a shortcut that was never vetted.
None of that is expensive. All of it requires the CEO and the executive team to actually do it, repeatedly, where people can see it.
Not every AI opportunity is playing for the same stakes. It helps to separate them explicitly.
All three levels matter. But most AI portfolios are weighted heavily toward the first because tasks are the easiest to prototype and quantify in a demo. The research on where value actually concentrates points elsewhere: in McKinsey's 2025 survey, organizations qualifying as AI high performers were nearly three times more likely than others to say they had fundamentally redesigned individual workflows, and that kind of intentional redesign showed one of the strongest links to measurable business impact of any factor tested.
Transforming a genuinely consequential decision usually requires several workflows and several types of technology working together — not one well-prompted agent.
The word "agent" now covers so much ground that it obscures a real architectural distinction. An agent can retrieve information, summarize content, call tools, coordinate a sequence of steps, and hold a conversation. Those are genuinely useful capabilities. But an interface that can access information is not the same as a system that possesses the underlying domain model required to reason reliably about a physical asset, a contract, or an investment.
An agent can give an organization a new way to interact with what it already knows. It does not, by itself, create the capability the organization is missing.
Take a developer trying to determine whether a proposed multifamily design will hit its business objectives. A reliable answer may require extracting geometry from drawings, recognizing units and circulation, calculating net-to-gross efficiency, checking code and accessibility requirements, comparing the result against relevant benchmarks, layering in cost and operating assumptions, and being explicit about what's a fact versus an estimate.
A conversational agent can orchestrate that analysis and explain it in plain language. It cannot reliably infer all of that underlying truth from unstructured drawings well enough to support a capital decision — that requires computer vision, deterministic calculations, rules engines, and in many cases optimization or simulation, with a human professional retaining accountability for the judgment call at the end.
This matters more in AEC than in most industries because the outputs touch capital, contracts, public safety, and physical construction. NIST's Generative AI Profile — the official companion to the NIST AI Risk Management Framework, published in 2024 — is useful context here: it identifies risk categories including confabulation, information integrity, and human-AI configuration. An incorrect meeting summary is a minor inconvenience. An incorrect assertion that a design satisfies a life-safety requirement is not. The architecture and the level of human oversight should be matched to the consequence of being wrong, not applied uniformly across every use case.
Companies need a disciplined way to decide which opportunities earn a place in the portfolio. The following questions work at the project, business-unit, or enterprise level.
This framework guards against two opposite mistakes. The first is prioritizing purely by ease — chasing whatever is simplest to demo. The second is prioritizing purely by theoretical value — funding an ambitious idea with no usable data, no executive owner, and no realistic adoption path. A portfolio needs both quick, practical wins and a smaller number of strategic capability bets, but leaders should be clear about which is which, because they deserve different funding thresholds and different success metrics.
A simple two-by-two helps separate commodity efficiency from differentiated intelligence.
Standardized and lower consequence. Meeting transcription, general drafting support, commodity document summarization, basic enterprise search. These create real productivity gains, but no company will build durable advantage by reinventing tools every competitor already has. The work here is disciplined selection, integration, and adoption — not proprietary development.
Company-specific but lower consequence. An internal standards assistant, automated assembly of recurring reports, retrieval from an internal knowledge base, a first-draft investment memorandum generator. Internal, lightweight tools are often appropriate here because the differentiating ingredient is the company's own process or data, not a fundamentally new technical capability.
Standardized but strategically important. Financial planning, project controls, contract management, cybersecurity, core BIM collaboration, mature scheduling and estimating platforms. These are consequential, but the value comes from enterprise-wide implementation discipline and data quality — not from owning the underlying software.
Company-specific and strategically consequential. Proprietary site-acquisition intelligence, design-performance evaluation tied to an owner's investment thesis, project-readiness scoring built on internal risk history, portfolio-level benchmarking, specialized constructability intelligence. This is where the hardest sourcing decisions live, and where the next section matters most.
Once an opportunity is prioritized, the sourcing decision shouldn't be a reflex. Each option fits a different situation.
Build internally when the capability is genuinely differentiating, proprietary data or methods are central to the result, and the organization has — or is willing to fund — the product management, AI architecture, data engineering, security, and ongoing maintenance a production system requires. That last part is where companies most often overestimate themselves. An internal prototype can prove an idea is useful without proving the company should own the production system behind it.
Subject-matter experts can define what good looks like. They do not, by themselves, constitute a product organization.
Buy when the need is common across the industry, mature solutions already exist, the capability isn't a source of differentiation, and speed matters more than ownership. Buying still requires real strategic work — selecting the right platform, redesigning the workflow around it, integrating the data, and driving adoption. Buying software is not the same as creating a capability.
Configure sits between the two. This is the increasingly common middle path: adopting a commercial platform as the technical foundation, then layering in proprietary data, business logic, workflow rules, and controls that reflect how the company actually operates. Configuration lets a company avoid the cost of building core infrastructure from scratch while still encoding what makes its process distinctive — an internal standards assistant built on top of a commercial retrieval platform is a configure play, not a build.
Use consultants when the problem is poorly defined, priorities need translating into an actionable portfolio, decision rights are unclear across business units, or the team needs outside perspective and implementation support. Consultants accelerate diagnosis and change management well. What they don't do is substitute for ownership — a presentation, a process design, or a prototype accelerates learning, but it isn't a durable operating capability. The company has to retain accountability for the problem and the outcome even when it outsources the acceleration.
Partner when neither side has all the necessary ingredients. An AEC company typically brings domain expertise, project data, internal standards, historical outcomes, and a live environment to validate against. A technology partner brings specialized architecture, product infrastructure, and continuous development capacity. That combination frequently outperforms either a generic software purchase with minimal adaptation or an internal team trying to recreate a specialized platform from nothing.
Co-develop when the opportunity is genuinely strategic, the external market for it is still immature, and both sides have something the other needs — domain knowledge and validation on one side, reusable technical infrastructure on the other. Co-development requires more upfront discipline than any other path: intellectual property ownership, data rights, exclusivity, roadmap influence, validation responsibilities, and what happens to the relationship after the pilot all need to be settled before the work starts, not after.
None of these sourcing choices work without internal capability to make them well — even the ones that end in "buy." Companies need clear ownership across a short list of roles:
Neither full centralization nor full decentralization tends to work well here. MIT CISR's December 2025 research on enterprise IT operating models makes a related point directly relevant to this problem: an effective operating model in the AI era needs to let the enterprise's most valuable capabilities innovate and scale while still managing risks like cyber threats and competitive exposure, and the researchers frame this as a genuine leadership and governance choice — not a default setting — since different operating models deliver meaningfully different outcomes. In practice, the workable model is usually hybrid: centralized governance, security, architecture, and reusable infrastructure, paired with distributed problem ownership sitting inside the business units that will live with the results.
Two things about this governance structure are worth stating plainly. First, it isn't optional overhead to be added later once an AI program grows large enough to justify it — governance becomes inevitable the moment AI and innovation are folded into stated business strategy, because that's what a strategic priority is. A CEO who names AI a priority has, in that same act, already created the governance question: who decides what gets funded, who is accountable when something goes wrong, and who has standing to say no to a business unit's pet pilot.
Treating governance as something to bolt on after the fact — rather than as the direct, immediate consequence of the CEO's own prioritization — is usually why it arrives too late to matter.
Second, this isn't only an internal discipline question. Not every employee's job should be to innovate, and giving that responsibility clear, named ownership is also what makes a company legible from the outside. A technology partner, vendor, or potential co-development partner needs to know who inside the organization actually owns a given capability bet. Without that structure, every external relationship starts over — a one-off built on whichever executive happened to take the meeting — instead of an institutional relationship that persists and compounds as the technology and the market mature.
Everything above assumes some internal capacity to do the sequencing work — someone who can run the evaluation framework, own the portfolio, and hold a technology partner accountable. Plenty of companies, particularly in the middle market, don't have that function today and don't have years to build one before they need to move. For them, the realistic path is often to buy a compressed version of it: one external team that can diagnose the problem, help prioritize the portfolio, and also build the solution — the same logic as a fractional CFO or fractional general counsel, applied to this problem instead.
That compression is a reasonable way to move without disrupting the internal organization, but it carries a specific risk worth naming rather than assuming away. A team that gets paid to build has a natural interest in finding things worth building. That doesn't make the arrangement dishonest, but it does mean the evaluation step — the same step that's supposed to protect a company from starting with the technology instead of the problem — stops being neutral once the people running it are also the people who benefit from what gets approved. Left unmanaged, this model can quietly relocate the exact failure mode this article opened with, from inside the company to inside the vendor relationship.
Two things keep that from happening. First, name an internal owner — even if it's the CEO doing this personally for now — whose job is to hold the external team's recommendations against actual business outcomes, not against the external team's own backlog. Delegating the building is fine. Delegating the definition of what matters, with nobody internal actually checking, is not. Second, put the path to ownership into the engagement itself at the outset: intellectual property terms, data rights, and a specific point at which particular capabilities get evaluated for bringing in-house. Left implicit, external arrangements like this tend to become permanent by default, since the outside team has little incentive to make itself replaceable.
What can't be compressed away even under this model is the top of the hierarchy. Business strategy, strategic outcomes, and which decisions actually matter to the company have to stay with the company — a partner can help answer those questions, but shouldn't be the one setting them.
A partner can help answer those questions. It shouldn't be the one setting them — that judgment is the premise the rest of this framework depends on.
The pressure to modernize is real and isn't going away. In Autodesk's 2025 State of Design & Make report — based on nearly 5,600 industry leaders across architecture, engineering, construction, and operations, design and manufacturing, and media and entertainment — cost control remained the top challenge cited by AECO leaders, and 58 percent said a lack of access to skilled talent was hindering growth. Sixty-nine percent of leaders still believe AI will enhance their industry, but that figure is down twelve points from the year before — a sign that enthusiasm is cooling as implementation gets harder, not that the underlying opportunity has changed.
The right response isn't to slow down. It's to be more disciplined about where the effort goes. Every developer, contractor, architecture firm, and engineering organization should be able to answer, in specific terms:
That last question deserves a concrete answer before the project starts, not after. Reasonable metrics include decision-cycle time, capital protected, risk detected earlier in the process, forecast accuracy, rework avoided, and approval-cycle reduction.
The measure of success is never that the demo was impressive. It's that the business became more capable.
An AI strategy is not a catalog of agents a company intends to deploy. It's a disciplined system for determining where AI creates real leverage, what outcomes it's meant to support, what data and architecture it depends on, where human judgment stays essential, how risk and oversight scale with consequence, which capabilities are centralized versus distributed, and what the company builds, buys, configures, or creates with others.
That definition does real work. It makes room for experimentation without mistaking experimentation for transformation. It builds internal expertise without assuming everything has to be built in-house. And it takes agents seriously as a tool without treating them as the answer to every problem.
The organizations that get the most value from AI over the next several years won't necessarily be the ones that deployed the most tools or launched the most pilots. They'll be the ones that got disciplined about three things: identifying which problems actually matter, assembling the right mix of people, data, process, and technology to solve them, and being honest about whether the business actually got better as a result.
Companies need an AI strategy. But the purpose of that strategy isn't to deploy AI everywhere. It's to determine where intelligence can create the greatest advantage — and how to build that capability responsibly.
Russell Goldman is Founder and CEO of Buildable Engine, where he helps development, construction, and design organizations turn AI ambition into operating capability. He previously led AI product management and served as Head of Innovation at one of the world's largest consumer electronics companies.
As AI makes it nearly effortless to generate endless possibilities, the harder problem becomes deciding what actually works. The next frontier of AI may be systems that can evaluate, optimize, and navigate complexity—while leaving humans to define what “better” means.
Buildings accumulate disconnected representations of themselves from the moment design begins — drawings, models, specifications, and field records that were never designed to stay in sync — and most of the built environment is operated, maintained, and traded against information that stopped matching physical reality the day construction began. The industry has built an entire economy of workflows to manage that drift, and the next significant shift in construction software is treating it as an infrastructure problem rather than a documentation one.
