Rebuilding vs. Automating Broken Workflows

Enterprise AI is widely adopted and rarely transformative, and the two facts sit side by side without canceling each other out. Most organizations are making existing work faster without changing what that work actually is, and that is where the promised value of AI quietly disappears.

Why most enterprise AI efforts produce more speed, not better outcomes

Deloitte's State of AI in the Enterprise report puts a number on something operations leaders have suspected for a while: access to AI inside companies rose sharply in 2025, but that access hasn't translated evenly into changed work. Of the organizations Deloitte surveyed, a third are using AI to reinvent core processes, another third are redesigning key processes around it, and the remaining third have made little or no structural change at all, even as they roll the tools out.

The gains that appear most often in these organizations are efficiency and productivity gains, people doing the same work faster. Revenue growth and operating profit impact lag well behind, and most organizations still describe revenue growth through AI as something they hope for rather than something they can point to. That gap between reported efficiency and reported profit is the clearest sign that something in the middle is not converting one into the other.

The shortfall isn't about how fast companies adopted the tools or how good the tools are. Most organizations are pointing AI at the work exactly as it already exists, so the process structure underneath stays the same even as the software on top of it changes. A faster version of a broken workflow is still a broken workflow, just one that produces its results, and its failures, on a shorter timeline. That raises the question the rest of this piece is built around: what actually separates the organizations that turn AI into measurable operating results from the ones that only turn it into speed?

What Separates Organizations That Get Measurable Value

The answer McKinsey offers in The Operating Model Advantage is not about which tools companies bought or how much they spent. It comes down to sequence. Companies that attribute meaningful EBIT impact to AI are nearly three times as likely to have redesigned their workflows before deploying AI, and twice as likely to have done that redesign before they even chose which tools to use.

McKinsey draws its line between two different questions companies ask before they buy anything. One group asks how to make the current work happen with less manual effort. The other asks whether the current way the work happens is the right way to begin with. The first question accepts the process as a given and looks for friction to remove from it. The second question treats the process itself as the thing open to change. Automation answers the first question by speeding up execution. Redesign answers the second by rebuilding the structure the execution runs on, and without that structural change, any efficiency gain automation produces is capped by the limits of the process it was layered onto.

Operations leaders who hear "redesign your workflow before you deploy AI" reasonably hear a long, expensive consulting engagement standing between them and any usable AI system. That fear misreads the scale of what's being asked. Redesign doesn't have to mean an enterprise-wide transformation program before a single model goes into production. It can mean scoping the redesign to one painful, well-understood process and proving the sequence works there first, a point the rest of this piece returns to once the mechanics of what goes wrong are clearer.

Automation Layered Onto a Broken Process

Automating a process that's already broken doesn't produce a faster version of the eventual outcome. It builds the process's dysfunction directly into software logic, where it's no longer visible for someone to question or fix. Redundant steps, unclear ownership, and informal workarounds that experienced staff used to patch over daily all get locked into the automated system's rules, and every automated cycle reinforces those rules instead of exposing them as problems.

The costs compound in a specific order. The build itself is only the first expense. After that comes ongoing manual cleanup behind the automation, declining trust in a system that keeps producing errors people have learned to route around, and eventually a rearchitecting effort that costs several times what the original build did.

Three structural signs reliably tell you a process needs rebuilding rather than automating: exception rates that run high, logic that depends on informal workarounds instead of designed rules, and tool sprawl that has scattered the process across a fragmented handoff chain.

A Fortune 500 insurer's experience shows how this plays out. The company had mature documentation and a sizable automation footprint already in place, and its straight-through processing rate had still fallen. Automation had been layered onto workflows that were already generating heavy exception volume, which produced a system that was both brittle and expensive to maintain. Once domain experts redesigned the workflow itself, removed the bottlenecks causing the exceptions, and assigned clear ownership over the process, performance recovered significantly. The fix wasn't more automation. It was redesign the automation had been substituting for.

The Cost of Wrong Sequencing in Construction

Construction brings together nearly every failure mode this sequencing problem produces: data scattered across disconnected systems, plans that diverge from field reality, and exception rates that run high by the nature of the work. That concentration is also why construction is where correctly sequenced AI redesign produces the clearest measurable gains, once it's done in the right order.

McKinsey's 2026 report on architecture, engineering, and construction lays out the baseline: global construction output and demand are enormous and still growing, yet construction productivity grew far more slowly than manufacturing productivity over the same stretch of time. That gap between construction and other industries didn't open up recently; it's been building for years.

The evidence for how badly plans and field execution diverge is concrete. A benchmark review of tens of thousands of CPM schedules found that a large majority finished later than the original baseline end date, and only 12% of baseline schedules met high-quality standards. The planning tools aren't the weak link here. What the tools are trying to represent, the actual process generating the schedule, is the weak link.

Out of a large database of projects analyzed by economic geographer Bent Flyvbjerg, only a small fraction met both cost and schedule targets, and a review of megaprojects showed average cost overruns and schedule delays that dwarf any efficiency gain from surface-level automation.

Most AI systems trained on text and structured project data can optimize a schedule on paper, but they can't tell whether that schedule is actually executable against real site conditions. Automating schedule review before closing that gap just produces confident-looking plans faster, and confident-looking plans that don't survive contact with the field are often worse than no plan at all, because people act on the confidence.

McKinsey's AEC report describes a scenario that makes this concrete. A field superintendent discovers that prefabricated pipe spools no longer fit because of a late engineering change. Handled the traditional way, that discovery triggers a cascade of RFIs, drawing reviews, procurement checks, and schedule updates, while crews on site sit idle waiting for an answer. In a redesigned workflow with AI agents built into it, the same discovery gets cross-referenced within minutes against the 3D model, the engineering drawings, procurement records, and the construction schedule, with the agents drafting routing options and delivering a consolidated view of trade-offs to decision-makers within hours instead of days. The contrast there is a redesigned process with AI agents built into its core, against an unchanged process with AI bolted on as an extra reporting layer.

Energization readiness as the construction chokepoint automation cannot fix without process redesign

Energization readiness, the point where procurement, scheduling, civil work, and equipment installation all have to come together precisely, shows what's at stake when this sequencing problem gets concentrated into a single chokepoint. Automating the coordination process as it currently exists, instead of rebuilding it, produces some of the most expensive failures in the entire construction lifecycle.

High-voltage interconnections, on-site substations, and standby generation systems all require design decisions to be locked in early, because the equipment behind them, large generators, transformers, switchgear, routinely carries lead times measured in years. Civil work, structural installation, and equipment energization all have to line up with real precision, because a delay in any single package can stall commissioning for the entire facility. There's no partial energization to fall back on.

Weekly or monthly reporting cycles simply can't surface a deviation early enough to do anything about it in this kind of environment. The procurement window that could have corrected a lag closes before that lag appears in a monthly report.

Teams running multiple sites at once need an integrated, near-real-time view across schedule logic, committed cost, earned progress, procurement status, and logistics flow all at the same time. Building that view isn't a reporting upgrade. Building that view is a process redesign problem, because the data behind that view sits in separate systems that were never built to reconcile with each other. Contractors running these programs have found that near-real-time data lets deviations appear within days instead of weeks, but getting there requires redesigning the underlying data flows and who owns which piece of accountability, not just connecting the existing systems to a dashboard. The intelligence layered on top of a process is only as useful as the process it's sitting inside of.

How logistics and manufacturing are learning the same lesson in parallel

Construction isn't unique in learning this lesson. Logistics and manufacturing are arriving at the same conclusion at roughly the same time, which is itself evidence that redesign-before-automation is a structural requirement rather than a quirk of how buildings get built. The organizations capturing real value from agentic AI in these sectors are the ones that used AI deployment as the occasion to redesign the underlying process, rather than treating AI as something to lay over the existing one.

Val Marchevsky, CTO of Uber Freight, put the point directly in AJOT's logistics tech trends report: "The biggest opportunities won't come from layering AI onto broken processes, but from using it to redesign processes for efficiency, eliminate waste, streamline execution, and help teams move faster and smarter". The shift toward agentic AI in logistics in 2026, systems that reason and act autonomously rather than just executing rules, makes this more urgent rather than less. An agent working inside a broken process doesn't just speed the dysfunction along. It starts making autonomous decisions based on that dysfunction.

Darrin Demchuk, SVP of Product for Fleet North America at Platform Science, describes a parallel shift already underway in fleet operations. Instead of drivers and dispatchers juggling several disconnected tools, intelligent agents coordinate workflows in real time across vehicles, back-office systems, and outside networks. That kind of architecture only works if the workflow underneath it has already been standardized and clearly owned before the agents are asked to coordinate across it.

IDC's 2026 Manufacturing Industry FutureScape projects that more than 40% of manufacturers with a production scheduling system already in place will upgrade it with AI-driven capabilities aimed at autonomous processes. IDC is explicit that real scalability depends on clean data, standardized processes, and disciplined governance, conditions that come from redesign, not something automation produces on its own. Early agentic use cases in supply chain and manufacturing, in design augmentation, procurement optimization, and quality assurance, all depend on the same thing: whether the process feeding the agent has been standardized enough to give it coherent information to reason from in the first place.

AI Agents Deployed Inside Broken Processes: A New Category of Operational Risk

Embedding an AI agent in a process changes what a broken process costs you. Once an agent is acting inside the workflow rather than just reporting on it from the outside, the broken logic it relies on stops being merely inefficient. It becomes the actual decision logic the agent is acting on, autonomously, at speed, and in some cases without any recoverable error state once the action is taken.

How often agent deployments actually make it to production reveals that risk. Analysis of enterprise AI agent deployments across 2024 and 2025 found that fewer than one in eight agent initiatives successfully reach production operation, and the two leading causes, scope creep and data quality problems, both trace back to skipping process redesign before deployment.

Agents introduce six failure modes that have no real counterpart in traditional software: tool misuse, context loss, goal drift, retry loops, cascading errors across multi-agent systems, and silent quality degradation. Each of these can happen even when every individual response the model produces looks locally coherent on its own. Retry loops carry particular risk in operational settings, where a failed tool call triggers another attempt and then another, with no limit, potentially exhausting a cloud budget or generating faulty procurement actions before anyone catches it. In construction or logistics, those actions may be impossible to reverse within the project's timeline.

Governance hasn't caught up to this risk. Deloitte's 2026 report finds that only one in five companies has a mature governance model for autonomous AI agents. Most organizations are deploying agents into whatever process already exists, with no oversight structure built to catch the agent acting on broken logic. Microsoft's red-team taxonomy, released between April and June 2026 and built on 12 months of adversarial testing, adds seven new failure modes specific to agentic systems, including supply chain compromise and goal hijacking, that exist specifically because agents operate with more autonomy and system access than earlier software ever did. A hallucination rate that's tolerable in a chatbot becomes operationally dangerous in an agent handling insurance claims or procurement decisions.

The practical threshold for knowing whether to rebuild or automate a specific process

Deciding whether to rebuild a process or simply automate it is a diagnostic question, not a philosophical one, and three structural conditions in any given process reliably show whether automation will fix the problem or make it worse. The first is a high exception rate: when a process regularly produces outcomes that need a person to step in and fix them by hand, automating that process just builds the exception-handling burden permanently into the system, since the exception rate is really a measure of how poorly the documented process maps to what actually happens. The second is logic that depends on workarounds rather than designed rules: when a process only works in practice because experienced staff quietly know what the documented steps leave out, automating it removes those people and leaves only the documented steps, which then fail once they're running in production without anyone there to catch the gap. The third is fragmented handoffs between tools: when data moves between systems through manual re-entry, copy-pasting, or informal reconciliation, automating any single step in that chain leaves the handoffs themselves untouched, and a process is never more reliable than its weakest handoff.

None of these three conditions is a reason to avoid AI. Each is a signal about where AI belongs in the sequence: after the process has been rebuilt.