The Minimum Viable Rewire

Analysis·Giovanni Leonardi·August 2026·9 min read

The useful unit of AI transformation is the workflow that produces an outcome, not the tool that accelerates a task.

The twenty-minute task inside the nine-day process

A claims team introduces an AI assistant to prepare an initial case assessment. Drafting falls from twenty minutes to two. The customer still waits nine days.

This is an illustrative workflow, not a reported case. Its logic is familiar. The draft enters the same supervisor queue. Missing customer data still requires an email to another department. Higher-value cases still wait for a committee. An approved decision is still copied into the core system by hand. The task accelerated; the operating outcome did not.

That gap explains why so much enterprise AI activity produces enthusiasm without economics. Reuters reported in December 2025 that one survey found 15% of executives had seen improved profit margins from AI, while another found 5% reporting widespread value [S1]. Those surveys do not establish why returns are limited. They do expose the distance between using AI and changing performance.

The common response is a false choice. Keep adding pilots, or launch a sweeping enterprise rewire. Both can avoid the harder judgement: deciding exactly how much of a workflow must change before a local gain can reach the customer, the accounts or the risk outcome.

The useful unit of AI transformation is the workflow that produces an outcome, not the tool that accelerates a task.

Where local gains go to die

A workflow is an economic chain. Each task consumes information, produces an output and transfers responsibility. Improving one link matters only when the improvement survives the rest of the chain.

Research summarised by MIT Sloan in April 2026 makes the sequence, grouping and handoff of tasks central to understanding AI’s effect on work [S2]. If several adjacent tasks are suitable for AI, they can sometimes be combined or executed in sequence. Fewer handoffs can reduce waiting and coordination cost. Yet chaining tasks also changes where exceptions arise, who can authorise action, what data must be available and when a human must intervene.

Leave those conditions untouched and the gain is absorbed:

  • A faster draft waits in the old approval queue.
  • An automated recommendation cannot act because authority sits elsewhere.
  • A customer response is generated immediately but depends on data refreshed overnight.
  • An agent completes a sequence but cannot write the result to the system of record.

Local productivity creates capacity. The unchanged workflow preserves the constraint.

This is not unique to generative AI. Historical research on information technology found that performance gains depended on complementary organisational investments and could arrive with delay [S3]. AI changes the opportunity because it can affect coordination as well as computation. It does not remove the need to align work, authority, skills and information.

The minimum viable rewire

The answer is a minimum viable rewire: the smallest coherent redesign of tasks, handoffs, authority, oversight, data and interfaces that lets an economically important workflow produce a measurable outcome.

Return to the illustrative claims process. A bounded rewire might make six linked changes:

  1. Define success as elapsed time to a safe and accurate settlement, not minutes saved drafting.
  1. Give the assistant access only to verified policy, customer and case data needed for an initial assessment.
  1. Permit straight-through handling only for low-value, reversible cases that meet explicit completeness and confidence thresholds.
  1. Route exceptions directly to the person able to resolve them, with the evidence and reason for escalation attached.
  1. Replace review of every case with mandatory review of named risk conditions plus sampled quality review.
  1. Write an approved decision back through a controlled interface.

This is more than a tool deployment because work, control and accountability change together. It is less than an enterprise-wide transformation because the boundary is set by one outcome and its binding constraints.

That boundary is commercially important. Every additional dependency enlarges delivery risk. If a controlled interface to a legacy system is enough, replacing the core is not a prerequisite. If inconsistent customer identity makes reliable decisions impossible, data remediation belongs inside the rewire. If the weekly committee is the dominant delay, no model improvement will remove it until decision rights change.

Modernisation should follow a demonstrated constraint. It should not be charged as a universal admission fee for AI value.

A minimum viable rewire is complete when the workflow can produce the intended outcome safely and measurably. It is not complete when every surrounding system looks modern.

Four tests before transformation expands

The right depth of change can be judged through four tests.

Can the gain reach an economic measure?

Start with an end-to-end baseline: cycle time, capacity, quality, cost, revenue or risk. Task metrics remain useful diagnostics, but they are insufficient. If a tenfold improvement in one activity cannot move the full outcome, the use case is wrongly placed or too small to justify wider change.

Where does the gain stop?

Trace the work from trigger to outcome. Mark queues, approvals, reconciliations, data retrieval, system transfers and exception loops. The first point at which the local gain disappears is the likely binding constraint. This prevents a platform programme or target architecture from substituting ambition for diagnosis.

What authority can safely move?

Autonomy should follow reversibility and error cost. A low-cost decision that can be corrected tolerates more automated execution than a safety-critical or irreversible one. “Human in the loop” says too little. The control must specify who decides, which thresholds trigger review, what evidence accompanies escalation and who owns the outcome.

The Stanford Enterprise AI Playbook reports substantial variation in deployment timelines and describes sponsorship, existing processes, user willingness and fit-for-purpose oversight as relevant to outcomes [S4]. Its cases are selected rather than randomised, so they do not prove that any one organisational choice caused success. They reinforce the need for workflow-specific control.

Which foundation is causal?

Ask whether data, integration or legacy architecture prevents the selected workflow from reaching its outcome. Fund foundation work where that relationship is specific and testable. “AI readiness” is too broad to govern. “Customer records cannot be reconciled in time for a controlled decision” identifies something that can be measured and fixed.

These tests turn transformation from a contest in programme size into a discipline of constraint removal.

The case against rewiring

The strongest sceptical view is not that workflow design is irrelevant. It is that the current rewire narrative can become a supplier-friendly relabelling of cloud, data, ERP and outsourcing demand.

The sceptic has evidence. AI capability remains uneven. Reuters reported that Cando Rail paused a chatbot intended to help employees study safety materials after inconsistent summaries and fabricated content. The company had spent about $300,000 on AI product development. Klarna retained human support for complex customer cases after emphasising automation, while Verizon continued to use AI for triage but restored easier access to people [S1].

These examples are reported cases, not controlled comparisons. They nevertheless establish a boundary. Redesign around unreliable capability can amplify error. Broad operating-model change can consume more value than it creates. A personal-productivity tool can also deliver useful local benefit without any transfer of authority or core-system integration.

This objection sharpens the argument. A minimum viable rewire is not the maximum contiguous chain that AI can touch. It is the smallest chain across which capability, recoverability and control justify change.

Cando Rail’s difficulty was not insufficient organisational ambition. A critical task was unreliable and safety-sensitive. In customer service, the workable boundary can place routine matters with automation and preserve human handling for complexity. The operating model must follow demonstrated capability and error cost, rather than a target level of autonomy.

Why large programmes start in the wrong place

Enterprise programmes often reverse the order of proof. They approve a platform, modernise foundations and establish a central operating model, then search for enough use cases to validate the investment. This can be rational when several priority workflows have already exposed the same shared constraint. Without that evidence, a bounded hypothesis becomes an enterprise bet.

The alternative is coordinated without being indiscriminate. A central function can provide approved tools, evaluation methods, interface standards, data controls and risk thresholds. Workflow owners remain accountable for the economic result and local operating design. Business leaders cannot delegate the outcome to technology; technology leaders cannot resolve incentives, authority and workforce design alone.

A sound investment review should require:

  • the workflow outcome and baseline;
  • the binding constraint and where local gain currently disappears;
  • the proposed changes to tasks, decisions, oversight, data and interfaces;
  • the conditions under which automation stops or reverses;
  • the comparison that will distinguish genuine improvement from stronger management or easier use-case selection.

The final requirement matters because the causal evidence is incomplete. Organisations with better data, stronger management and greater change capacity may both redesign workflows and achieve better results. Selected cases cannot isolate the effect of redesign. Where practical, teams should compare redesigned and unchanged variants, record error and exception costs, and measure the complete workflow.

Let evidence decide the architecture

The minimum viable rewire offers restraint with consequence. It rejects task gains that never reach an operating result. It also refuses to make wholesale modernisation the default price of scaling AI.

Its limits are clear. The approach fits repeatable, economically material workflows where coordination, handoffs, data access or decision rights constrain performance. It is weaker for low-volume work, novel judgement, irreversible high-stakes decisions and processes built on unreliable data. In some modern bounded workflows, the existing design may already fit the technology.

Several bounded rewires can reveal a common architectural constraint. That is the moment to fund shared modernisation with evidence from operations. The same work can show that controlled interfaces are sufficient, avoiding an unnecessary core replacement.

The question for the executive committee is therefore no longer, “How much should we modernise to become AI-ready?” It is: Which constraint prevents this workflow from producing value, and what is the smallest coherent change that removes it without exceeding the technology’s reliability?

Sources

  1. Reuters — AI promised a revolution. Companies are still waiting. — 16 December 2025 — https://www.reuters.com/business/business-leaders-agree-ai-is-future-they-just-wish-it-worked-right-now-2025-12-16/
  1. MIT Sloan — How AI is reshaping workflows and redefining jobs — 22 April 2026 — https://mitsloan.mit.edu/ideas-made-to-matter/how-ai-reshaping-workflows-and-redefining-jobs
  1. American Economic Association — Beyond Computation: Information Technology, Organizational Transformation and Business Performance — 2000 — https://www.aeaweb.org/articles?id=10.1257%2Fjep.14.4.23
  1. Stanford Digital Economy Lab — The Enterprise AI Playbook — March 2026 — https://digitaleconomy.stanford.edu/app/uploads/2026/03/EnterpriseAIPlaybook_PereiraGraylinBrynjolfsson.pdf

Giovanni Leonardi  ·  About  ·  LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *