On the Seam: Working Drafts · July 2026

Rewired Assumes You're the Customer. What If You're the Product?

McKinsey's Rewired is written for the enterprise using the platform. If you are the platform — the legacy software company whose product is the transformation infrastructure your clients run on — a different sequence applies.

By Dr. Trey Harper

I have been reading the second edition of Rewired. It is a serious book. The six-capability framework holds up: transformation roadmap, talent bench, operating model, distributed technology environment, embedded data, adoption and scaling. The new material on agentic workflow design is the most useful addition to the second edition.

But before engaging the framework, two things about it need to be said plainly.

First, the failure data underneath Rewired's premise is damning. RAND Corporation's analysis found that 80.3% of enterprise AI initiatives fail to deliver intended business value [1]. MIT's Project NANDA found that 95% of enterprise generative AI pilots delivered no measurable P&L impact [2]. McKinsey's own research reports that 70% of digital transformation programs fail to reach their targets [3]. Any playbook built on this evidence should be read with that number visible.

Second, a substantive published critique identifies where the framework falls short: the change management section—where 70% of transformations fail—is the thinnest part of the book. Recent empirical research supports this critique directly: hybrid governance produces 41% higher adoption, and upskilling produces 2.7x higher success rates. The book is right about what you need to build. It underestimates how hard it is to build it.

With those caveats stated, here is the deeper problem.

Rewired assumes you are the enterprise using technology to transform your operations. It does not address what happens when you are the technology company whose product is the transformation infrastructure for someone else. That is a different problem — and for legacy enterprise software companies trying to become agentic, it is the harder one.

The assumption that breaks the framework

The book's domain-based approach tells you to find the domains where AI will generate the most value, reimagine the workflows inside them, and sequence your investment accordingly. For a bank, a retailer, or a manufacturer, that is actionable. You know your domains and you can map your legacy systems to them.

For a company whose product is the system of record inside a regulated industry — the platform running loan origination, or claims adjudication, or clinical scheduling — the domain-based approach breaks on contact. Your domains are your customers' domains, not your own. The workflows you would reimagine are not your internal operations. They are the operations of the banks, insurers, and health systems that have built decades of embedded institutional practice around how your software works today — practice that is wired into their audit regimes, their examiner expectations, and the procurement cycles that govern when anything is allowed to change at all.

You are not transforming one organization. You are transforming a platform that transforms other organizations — while those organizations are running live operations that cannot absorb disruption, on infrastructure that cannot be taken offline for modernization, subject to audit requirements and procurement constraints that your own timeline does not control.

Rewired also insists companies must be strong across all six capabilities at once to win. I do not think that is how it actually works, and the research on AI-enabled exploration points the other way: readiness and technology fit build sensing capability first, and sensing is what enables everything downstream [9]. The order is load-bearing. The companies that fail rarely skipped a capability — they built the right ones in the wrong sequence. That is the thing the framework underweights, and for legacy software companies the sequence is specific. Here is the one I believe in, and why it runs the way it does.

Step one: Inventory what you actually have — before you build anything

Rewired front-loads the roadmap. For legacy software companies, the roadmap cannot come first — because the roadmap depends on a portfolio assessment you have not done honestly yet.

Before any AI decision, you need to know which of your products contain genuinely differentiated workflow logic and which contain commodity functionality wrapped in proprietary code because platform services did not exist when you built them. Authentication, document management, notification pipelines, payment processing — none of that is your intellectual property. It is technical debt that accumulated because the platform layer was never built.

The research is unsparing here. Enterprise organizations spend an estimated 60 to 80 percent of their IT budgets maintaining aging systems [5]. Forrester found that 70% of transformations are slowed by legacy infrastructure [4]. And critically: Gartner has projected that 85% of organizations relying heavily on legacy systems will struggle to execute their digital strategies [5].

You cannot build a coherent agentic strategy until you have separated the differentiated workflow logic from the commodity infrastructure underneath it. The differentiated logic is what you modernize. The commodity infrastructure is what you replace. This step has no AI in it, no demo, no press release — which is precisely why it gets skipped. Skipping it is why most enterprise software modernization programs fail before they begin.

Step two: Separate the platform from the products — before you name a use case

Agentic AI lives at the platform layer. It needs a unified data model to know what is in the system, a consistent API surface to take action across products, a shared identity layer to understand who is authorized to approve what, and a reliable event architecture to understand what is happening in real time.

If the platform is fragmented — multiple data models, inconsistent APIs, product-specific authentication built by different teams over different decades — you cannot build agentic capability that works consistently across your portfolio. You build a collection of disconnected AI experiments, each impressive in isolation, none interoperable, all creating more fragmentation than you started with.

Rewired describes a distributed technology environment as one of its six capabilities, something to build in parallel with the others. For legacy software companies it does not work in parallel; the fragmentation has to be consolidated first. And that consolidation is not the thing you do before the AI strategy. It is the AI strategy.

This is the hardest organizational step, because it asks product teams to accept platform constraints they do not control — a leadership problem before it is a technical one. Research on large-scale transformation makes a related point: the organizations that navigate deep uncertainty well are the ones that build a deliberate practice for surfacing what they do not yet know, such as the "Sirius Days" retreat model [10]. In a platform consolidation, what you do not know is which product dependencies and legacy integrations will only surface once the work begins. The teams that fail treat consolidation as a technical exercise and discover it is a political one.

Step three: Find the workflows, not the features — inside a domain, not across the portfolio

Rewired's domain-based approach is exactly right here, but the unit of analysis needs adjustment. The book recommends identifying high-value domains and prioritizing them. For a legacy software company, the domain is not the product — it is the workflow pattern that repeats across products.

Software for regulated industries contains a small number of workflow archetypes that appear everywhere: intake, review, approval, notification, disposition, reporting. A commercial loan application, a medical claims review, and an insurance settlement are different products serving different missions. The underlying workflow is structurally identical. An agentic capability built for one — with the right platform abstraction — deploys across all of them.

The selection question is not "which product should we make agentic first?" It is "which workflow pattern, if we build it once at the platform level, creates the most value across the most products at once?" And the stakes are not abstract: organizations that try to scale AI agents without dedicated operational ownership of specific workflow patterns see markedly higher rates of production incidents that require rollback. The workflow has to be the unit of ownership, not the product.

Step four: Build the trust architecture before you build the capability

This is where Rewired's adoption and scaling capability falls shortest — and where the research diverges most sharply from the playbook.

Rewired frames adoption as the last capability in the sequence, addressed through change management and incentive design after the solution is built. For companies serving regulated industries, adoption is a legitimacy problem long before it is a change-management one — and legitimacy has to be earned before the agent is deployed, not managed after.

Enterprises in these sectors are risk-averse by design. They answer to regulators and shareholders, they are subject to audit and examination, and they operate where an error is not a product bug — it is a compliance failure with a paper trail. An agent that takes action inside a business-critical workflow — executes a trade, schedules a clinical procedure, triggers a payment — needs an accountability structure the organization can explain to an auditor, and ultimately to a client who asks why something happened.

A 2026 paper on pre-deployment assurance for enterprise AI agents formalizes exactly this problem, proposing a Trust Certificate framework with graduated deployment verdicts — Approved, Conditional, or Rejected [7]. The Conditional path, for agents that pass most verification scenarios but not all, requires manual review by an authorized human operator before deployment. Read that carefully and you find the assumption most organizations cannot satisfy: that someone on staff holds that authority and knows what to do with a verification report. Only 21% of organizations deploying agentic AI report having a mature governance model for autonomous agents [6]. There is no one to hand the certificate to.

My own research on generative AI adoption pointed to something other than raw capability as the driver of advocacy. What moved people was trust — the structural conditions that make someone willing to stake their name on an AI's output [8]. For enterprise clients those conditions are concrete: explainability, an audit trail, human-in-the-loop checkpoints at defined moments in the workflow, and a way to roll the action back when the agent is wrong. You do not get any of that from the model. It is governance infrastructure, and it has to exist before the agent goes live.

That RAND number — 80.3% of AI initiatives failing to deliver business value — is not really a story about technology [1]. It is a story about adoption. The technology worked. What never got built was the governance infrastructure that would have made people trust it enough to change how they worked.

Step five: Use AI to do the modernization itself

This is the step that makes the entire sequence economically viable — and the one most transformation roadmaps omit because it feels recursive.

The inventory, the platform consolidation, the workflow extraction — all of that work can be dramatically accelerated by agentic AI. Code migration, test generation, API wrapper creation, dependency mapping, data model normalization: these are tasks where agentic systems execute at a speed and consistency human engineering teams cannot match.

A 2026 case study found that AI-augmented modernization hit an 80% automation rate, cutting a set of enterprise application upgrades from 15 sprints to 8. McKinsey has reported developer-productivity gains of 20 to 30 percent from AI-augmented modernization for organizations with the platform infrastructure to support the tooling [11]. That compression changes the economic case for the whole transformation: the ROI arrives faster, which means you can fund later phases from the returns of earlier ones instead of demanding one large capital commitment up front.

This requires the platform to be far enough along to support the agentic tooling — which is why it is step five, not step one.

The missing capability — the one Rewired points to but cannot supply

Rewired's most important insight, confirmed by the failure data, is that transformation is a capability problem, not a technology problem. RAND's breakdown of the 80.3% failure rate is instructive: 33.8% of projects are abandoned before production, 28.4% are completed but deliver no value, and 18.1% deliver some value but not enough to justify the cost [1]. The common thread across all three is organizational, not technical.

For legacy software companies, that argument cuts deeper than Rewired intends. The six capabilities the book describes are necessary. They are not sufficient.

The missing capability is platform governance: the organizational structure that owns the platform as a product, enforces the abstraction layer across product teams, and makes the sequence above stick when individual product lines are under pressure to ship their own AI features their own way. Without it, the sequence becomes aspirational. Every product team finds a reason the consolidation does not apply to them. Every domain leader finds a reason their workflow is too unique for the common abstraction.

This, in my experience, is the decisive variable. The organizations that navigate complex transformation are the ones that stand up a dedicated function with the standing to challenge programs that are not on a credible path — not through org-chart authority alone, but through demonstrated technical credibility and a clear executive mandate. That function has to exist before the sequence begins, not after it stalls.

Rewired is the right book for this moment. The second edition's additions on agentic workflow design are genuinely useful. But the failure-rate data underneath it — RAND's 80.3%, MIT's 95%, McKinsey's 70% — should make every executive who reads it uncomfortable.

The book was written for the enterprise using the platform. If you are the platform — if your product is the infrastructure through which your clients transform — the sequence above is the one that actually applies. Build the capability framework, but execute it in order. The research confirms what experience suggests: simultaneity is the enemy of transformation, sequence is the strategy, and the organization that governs the platform is the one that controls the pace.

This is a working draft. The argument is offered in good faith and is genuinely held, but provisionally so.

Dr. Trey Harper writes on trust, legitimacy, and the architecture of the agentic enterprise at treyharper.com and in the LinkedIn newsletter On the Seam: Working Drafts. The views expressed here are entirely my own and do not represent the policy or position of my employer or any customer.