The differentiator concentrates in one place
The enterprise AI productivity story has two halves. Broad adoption: 88% of organizations now use AI in some form, per McKinsey's 2025 State of AI survey. Concentrated impact: only 6% of those organizations qualify as AI high performers, defined as capturing 5% or more EBIT from AI use. The same survey identified the differentiator. High performers were 3.6x more likely than the rest of the cohort to fundamentally rework workflows when deploying AI. The gap between what AI is producing and what most organizations are getting is not a function of which model they bought. It is a function of how AI was built into the way the organization operates.
The published case studies make this concrete. The headline numbers attract attention. The structural answer underneath the numbers is what matters.
What Klarna actually built
Klarna's AI customer service agent does the work of 700 full-time employees. It handles two-thirds of customer service chats. Customers resolve their inquiries in under two minutes instead of eleven. Repeat inquiries dropped 25%. Klarna estimated the agent contributed $40 million in profit improvement in 2024 and saved roughly $60 million by Q3 2025.
The reflex reading is that AI replaced humans. The structural reading is more interesting. Klarna did not deploy a customer service chatbot on top of its existing operating system. It rebuilt the customer service operating substrate around the assumption that AI would handle the high-volume work and humans would handle the long-tail, high-judgment work. The agent has access to the same internal systems the human agents have. It speaks 35 languages because the organization invested in giving it that range. It resolves issues in two minutes because the workflows it operates were architected for AI to execute end-to-end.
Klarna has since rebalanced toward a human-hybrid model. That refinement does not weaken the case. It strengthens it. The organization treated AI as part of its operating architecture, observed where the architecture needed to evolve, and refined. That is what an AI-native operating mode looks like.
What Morgan Stanley actually built
Morgan Stanley launched a GPT-based code review agent in January 2025. By mid-year, the agent had reviewed 9 million lines of legacy code and saved approximately 280,000 developer hours. Fifteen thousand developers shifted from manual code translation to strategic product work.
The numbers are large. The architectural choice underneath them is what produced the numbers. Morgan Stanley did not give its developers a code review chatbot to consult when they remembered to. It made the agent part of the workflow itself. Code that needed review went through the agent. The developers who used to do that work were redirected to higher-impact product engineering. The capability was not optional; it was operational.
That distinction is the entire story. Optional AI accumulates as a sidebar that engineers use when convenient. Operational AI changes what the engineering function does and how it spends its time. Only the second produces the kind of compounding return Morgan Stanley reported.
The structural finding
The case studies are vivid. A 2025 study from the University of Chicago Booth School of Business made the same finding rigorous. Researchers analyzed the rollout of a coding agent across 1,000 organizations and measured what happened to code output.
Firms using the tool as an optional feature saw modest gains. Firms that made it the default workflow saw a 39% increase in weekly code merges within weeks. The sharpest jump in output occurred only after the agent shifted from optional to default. The conclusion the researchers drew is unambiguous: building AI directly into core tools matters more than offering it as an add-on.
Three cases. Two named organizations and one cross-organization study. Different sectors, different tasks, different scales. One structural answer. The largest returns belong to organizations that build AI INTO the operating substrate, not the ones that bolt it on as a feature.
What "built in" looks like in practice
Building AI in is harder than bolting it on. Bolting it on requires a vendor relationship and a license. Building it in requires an architecture. Specifically: a record of how the organization actually operates, a system that holds that record where AI can read it, and a discipline for shipping AI capabilities into the operating mode of one department at a time.
That is what Growth Architecture is. The Foundation maps the organization across the six domains that govern how AI behaves inside it. The Blueprint is the living architectural record that captures what the Foundation found and the build sequence the Growth Architecture OS expands through. Each Activation Cycle takes the highest-priority initiative from The Blueprint, runs it through four disciplined phases, and ships one new capability the organization did not have before. A new skill the AI can execute. A new connector to a system of record. A new agent that orchestrates both against governance rules. The capability becomes operational. The Blueprint refines. The next cycle starts one rung higher.
The case studies above describe this pattern. Klarna built an operating substrate that includes AI as a participant. Morgan Stanley made AI part of the engineering workflow itself. The Booth study found that organizations get the productivity premium only when AI is operational, not optional. The pattern is consistent because the architecture is the differentiator.
The question for organizations
The competitive question for organizations is not whether to use AI. Most are already using it. The question is whether AI is being built into the operating substrate or accumulating as features. The first produces a capability premium that compounds. The second produces a procurement bill.
The market premium the Klarna, Morgan Stanley, and Booth study cases describe is available to any organization with the architectural discipline to claim it. The work is what changes. The substrate is what matters.