Automating Without Redesigning Is the Most Expensive Way to Preserve the Past
There is a sequence of decisions that repeats itself with surprising consistency across large companies with substantial digital transformation budgets: they identify a process that generates friction, they contract automation technology, they deploy the tool on top of the existing workflow, and they report progress. Executive dashboards show speed. Committee presentations talk about efficiency. And six months later, the same problems reappear, now packaged inside a system that is much harder to dismantle.
This is not an anecdotal phenomenon. McKinsey reports that 88% of organizations use artificial intelligence in at least one business function, but only 39% attribute impact to their operating margin. The difference between both groups does not lie in the vendor chosen or the budget allocated. It lies, almost invariably, in whether the organization redesigned its workflows before introducing automation or simply covered them with a layer of technology.
The magnitude of that gap deserves to be read carefully. We are not facing a problem of technological adoption. We are facing a problem of organizational design that technology is making visible at greater scale and at greater cost.
When Automation Turns Error Into Speed
Traditional automation, based on defined rules and narrow flows, already had this fragility. If a process contained undocumented exceptions, steps that depended on the tacit judgment of certain employees, or incomplete data that someone corrected manually before the system ever saw it, automating that process produced inconsistent results. But volumes were limited and the damage was manageable.
Agentic AI operates differently. It interprets objectives, generates recommendations, activates workflows, and makes decisions across multiple systems simultaneously. That makes it more powerful in well-designed contexts and significantly more damaging in poorly designed ones. An agent deployed on a process with ambiguous decision logic does not detect the ambiguity: it executes it with consistency and volume. What a senior analyst previously resolved with judgment, escalation, and institutional intuition now becomes an automated pattern of error that circulates through the system before anyone notices.
The documented case of a Fortune 500 insurance company illustrates the mechanism with precision. The company had documented operating procedures and a mature automation foundation. However, straight-through processing of cases had dropped sharply. The diagnosis revealed that automation had been deployed on top of workflows loaded with exceptions. The result was a fragile and costly system. The solution was not more technology: it was business experts who redesigned the flow, eliminated bottlenecks, and assigned clear responsibilities to specific leaders. After that, performance improved in a sustained manner.
The pattern revealed by that case is not technical. It is one of organizational design. Automation amplified the existing structure, defects included. What was missing was not a better AI model, but a process that actually deserved to be automated.
The Trap That Never Appears in Progress Reports
There is a dynamic that rarely makes it into executive progress reports on transformation projects: organizations tend to confuse activity with foundation. When automation is deployed, certain metrics improve immediately, at least superficially: processing speed, reduction of visible manual interventions, apparent cycle time. Those indicators feed quarterly presentations and reinforce the perception of progress.
What does not appear in those reports is the cost of the undocumented work that disappeared with automation. Not the manual work that the system replaced, but the invisible work of correction, informal validation, and situational judgment that employees performed to compensate for the deficiencies of the process. When automation eliminates that human work without first having resolved the deficiencies that made it necessary, those deficiencies remain present in the system, only now without any cushioning.
BCG names this error clearly: the frequent temptation is to automate what already exists. The value comes from starting from the desired outcome and reinventing how to deliver it. That distinction is not semantic. It has structural consequences. An organization that starts from the outcome must ask itself what flow of decisions, data, and responsibilities is needed to produce it in a sustained way. An organization that starts from the existing process is merely converting what was already happening into code, with its inefficiencies built in.
The cost of that difference scales. Dismantling poorly designed automation requires systems reengineering, model retraining, governance review, and in many cases, management of the damage the system produced during the time it operated. The expenditure is not only financial: it includes trust lost among the teams that depended on the process and among the customers who experienced it.
The Five Moves That Separate Correction From Escalating the Damage
For organizations that have already deployed automation on top of processes with weak foundations, pausing is not enough. Stopping the deployment limits incremental damage, but it does not correct the source. The five actions that mark the difference between real correction and a temporary patch all point to the same core: making the process visible before attempting to govern it with technology.
The first move is to identify the highest-risk workflows and halt their expansion. Not all poorly designed processes carry the same damage profile. Those that combine high frequency, decisions that are difficult to reverse, and regulatory or financial exposure are where the cost of delay is greatest. Those require priority attention, not additional analysis.
The second move is to map the process that actually exists, not the one that is documented. In most organizations, the documented process and the operated process diverge in ways that IT or automation teams cannot see from their positions. The exceptions, the workarounds, and the informal interventions that kept the flow running are not in the diagrams. They live in the daily practice of the people who execute them. Making them visible is not an audit exercise: it is a prerequisite for any redesign that is actually going to work.
The third move is to assign responsibility over the process, not over the tool. When accountability is fragmented among the technology team, the operations team, and the business area, the process has no owner. It has partial custodians who each optimize their portion without taking responsibility for the total outcome. Agentic AI cuts horizontally across multiple functions, decisions, and data sets. Without a leader accountable for that end-to-end outcome, automation improves isolated tasks while the business indicator remains stagnant or deteriorates further.
The fourth move is to rebuild human validation at the points where error is costly. This does not mean halting automation indefinitely or recovering manual steps that add no value. It means identifying the decision nodes where an incorrect output carries material consequences that are difficult to reverse, and maintaining active oversight at those points while the process stabilizes. The autonomy of agents must be earned progressively, not assumed from the outset.
The fifth move is to change the success metrics. Cycle speed and reduction of manual interventions are indicators of activity, not of outcome. Organizations that achieve sustained corrections monitor decision quality, the cost of error recovery, the robustness of regulatory compliance, and the impact on the customer experience. Those indicators do not improve with more automation layered on top of weak processes. They improve when the underlying process is sound.
The Moment of Crisis Already Occurred Before AI Arrived
There is a reading of this problem that deserves not to be lost from view: when AI automation produces deficient results, the crisis that manifests in that moment was not created by the AI. It was created earlier, at the moment the organization chose not to invest in the design of its processes. AI only made visible, at greater scale and with greater urgency, a structural fragility that already existed.
That changes the nature of the diagnosis. We are not facing a problem of technological adoption that is resolved with more investment in tools, better change management, or more technical training. We are facing organizations that used the promise of automation to defer a design decision that at some point became uncomfortable or costly to make.
The case of the technology company with erroneous revenue projections is revealing in that sense. The projection workflows involved multiple handoffs of responsibility and asynchronous updates that produced incorrect forecasts. Those projections distorted hiring, planning, and margin decisions. The solution was not a more sophisticated forecasting model. It was a redesigned process with clear checkpoints and responsibility assigned to cross-functional leaders. Once the foundation was corrected, the automation that had amplified the problem began to close the gap.
The lesson is not that AI does not work. The lesson is that AI works exactly as well as the process surrounding it is designed to work. The organizations that scale with confidence are those that treat process clarity as a strategic asset before treating it as a destination for technology.
An organization that automates something it has already poorly designed is not accelerating its transformation. It is accelerating its distance from the point from which it will eventually have to start again.
