Escaping AI Pilot Purgatory: From POC to P&L

In McKinsey’s recent State of AI 2026 global survey, 89 percent of respondents said that their organizations regularly use AI in at least one business function. Yet only 37 percent attributed an EBIT impact to AI, most of them under 5 percent of EBIT. McKinsey’s “Seizing the agentic AI advantage” report calls the mismatch between widespread use and limited bottom-line impact the gen AI paradox.

A previous article on this blog about enterprise agentic platform architecture provides a useful framing for this imbalance: horizontal solutions such as copilots and chatbots may be easy to deploy, but they’re loosely coupled to core processes and so don’t move the dial. In contrast, vertical solutions embedded into specific workflows can be transformative. For large organizations with the budget and executive sponsorship for AI at scale (itself a non-representative slice of the market), technology is rarely the binding constraint. For these companies, capable models exist, frameworks are mature, and cloud infrastructure is available. What keeps stalling is the move from “interesting proof of concept” to “production system that moves P&L in the right direction.”

This article captures key lessons about the engineering and delivery practices that separate initiatives that move the P&L from those that don’t. We’ll give an engineering perspective on principles that other McKinsey authors have framed strategically and architecturally. It runs in parallel to the six lessons described in the earlier McKinsey article “One year of agentic AI”.

The case studies

Two McKinsey engagements anchor most of what follows. We’ll refer back to them as Case 1 and Case 2.

Case 1: Manufacturing service operations

A global manufacturer working with our team and AWS deployed four AI solutions across an end-to-end service journey, and saw meaningful improvements in key service metrics, with clear P&L impact over the program’s measurement window. Each solution addressed a different step and used a technique suited to the problem: LLMs for unstructured text, optimization algorithms for resource allocation, and ML models for recommendation and prediction, with agentic orchestration over the top.

Case 2: Enterprise agentic platform

A global manufacturing conglomerate, working with our team, has built and launched its first enterprise agentic AI platform at scale, currently released to more than 10,000 account executives and strategy leaders. The platform is the venue through which dozens of agentic use cases are delivered across business units — the architectural side of the “codify and replicate” challenge in Lesson 6.

Both engagements started as proofs of concept, and both could easily have stayed there. We mention them upfront not as a pair of victory laps, but because the lessons that follow draw on the details of their delivery, as well as other engagements where we did not get these things right the first time.

The shape of pilot purgatory

The phrase “pilot purgatory” is one that our McKinsey colleagues have used before, for example in “How COOs maximize operational impact from gen AI and agentic AI”. That article describes organizations developing gen AI tools “that have little effect beyond saving workers a few minutes a day.” We use the term as shorthand for a pattern that’s pointed to by several independent data points, even though each measures something slightly different:

• Project abandonment. Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear value, and weak risk controls. The prediction also notes a tendency among vendors to engage in “agent washing,” rebranding existing tools as agentic. Gathered data already points this way: S&P Global Market Intelligence found the share of organizations abandoning most of their AI initiatives rose to 42 percent in 2025, from 17 percent a year earlier, with the average organization scrapping 46 percent of its proofs of concept before they reached production (note that this is self-reported, and “most” initiatives is not “all”).
• POC-to-production conversion. IDC research on enterprise gen AI programs describes a funnel in which a typical enterprise identifies hundreds of potential use cases, launches dozens of proofs of concept, and puts fewer than six into production.
• Maturity. In McKinsey’s Superagency research (a US-weighted C-suite survey), only about 1 percent of respondents describe their gen AI rollouts as “mature” (full source and caveats in “Why knowing what to do is not enough” below).

The metrics are not strictly comparable, but together they describe an industry that is much better at starting AI work than finishing it. The engagements we see exhibit a consistent pattern: a proof of concept lands well, stakeholders are excited, the real work begins, and progress stalls. There are several recurring symptoms:

• The demo-to-production gap. A model that works on curated data but doesn’t survive real-world inputs with incomplete records, inconsistent formats, and edge cases nobody anticipated because the training data was too clean.
• The adoption cliff. A technically impressive system that nobody uses, because end users were not involved in the design and it does not fit their workflow.
• The accountability vacuum. Data science built the model, engineering built the infrastructure, the business unit owns the process, and a vendor manages the platform. So when the system underperforms, everyone points at someone else.
• The “next model” trap. Instead of fixing the deployment, the team pivots to a new model, framework, or vendor. Each pivot resets the clock, and the pilot stays a pilot.
• The skills mismatch. A team can say it “knows AI” because it built a prototype that calls an LLM API. Production AI engineering has a much wider scope, which overlaps with rather than replaces MLOps and traditional software engineering. We return to that distinction in Lesson 5.

These are mostly socio-technical failures rather than algorithmic ones: a mix of workflow design, ownership, executive alignment, and engineering discipline. Better algorithms alone do not solve them.

Our lessons from production

1. Redesign the workflow alongside the model.

This is the lesson McKinsey colleagues have already amplified, and we build on it here. In “One year of agentic AI,” the first of the six lessons is “It’s not about the agent; it’s about the workflow.” The State of AI survey shows that intentional workflow redesign and senior-leader ownership correlate strongly with meaningful business impact, though this is an association across self-reported high performers, not a measured intervention effect. The broader “rewiring” thesis is the subject of McKinsey’s popular technology playbook “Rewired”.

A common mistake in AI deployment—and one we have made ourselves more than once—is treating it as a technology insertion problem. The team takes an existing process, bolts an AI model onto one step, and expects transformation. This is the horizontal-solution pattern called out in a recent QuantumBlack platform architecture article, in which copilots and chatbots ride on top of existing workflows, making them easy to ship and scale, but leaving them loosely coupled to the process they are meant to improve. In Case 1, the obvious horizontal approach would have been a single chatbot frontline teams could query when stuck: a reasonable pilot, but one that provides just a fraction of its potential impact. Our QuantumBlack colleagues reached the same conclusion from the software-development angle in Agentic workflows for software development. Agents earn their value only when they run inside redesigned, convention-driven workflows rather than bolted onto the old ones, and doing that well “requires organizational change that goes beyond technical tooling.”

In Case 1, we worked with the client to redesign the end-to-end service journey and put four AI solutions into production across it. On its own, no single solution would have moved the needle. Together, in the client’s reporting, they were associated with the service-metric improvement and P&L impact noted earlier. We treat those as program-attributable rather than a clean causal claim. AI was one factor among several, and the client’s own teams did the integration work that made the savings stick. This pattern appears in the research too: enterprise-level benefit shows up more often alongside vertical, workflow-embedded redesign than horizontal point automation.

Internal AI teams often struggle to break out of pilot mode because they are usually organized around a single function or technology layer. Seeing the full workflow and having a mandate to redesign it from end to end requires a cross-functional perspective and executive sponsorship that pilot teams frequently lack. The problem is not the teams so much as an operating model built for tools rather than transformation.

The teams that ship redesign the whole workflow, not just the step where the model sits.

2. Measure in P&L rather than accuracy.

Model accuracy is necessary, but it’s not the full story. A 95 percent accurate model that nobody uses delivers no business value; a lower-accuracy model embedded in a workflow people actually follow can move an operation. The shift that matters is from “does this model work?” to “does this system move the business?”

In Case 1, the C-suite tied a portion of their own performance targets to the AI program’s outcomes. In our experience this is a stronger forcing function than any technical KPI. Optimization arguments become business arguments, and trade-offs are resolved in days rather than quarters. We do not claim the incentive structure caused the results, but it visibly changed the conversation.

That kind of alignment might sound obvious, but it’s also rare, and the State of AI 2026 survey suggests that the organizations capturing value are the ones that instrument for it. AI high performers — the roughly 6 percent of respondents who attribute at least 5 percent of EBIT to AI and report ‘significant’ value from it — are about twice as likely as others to say their organizations have defined processes to measure the impact of their AI initiatives. That is correlation, not proven causation, and it’s important to note that high performers are doing several things right at once, with practices that reinforce one another. But the correlation matches our own observation that teams who successfully move the P&L tend to be the ones measuring in P&L terms from the start.

Many pilots are still measured in technical metrics (F1 scores, latency, throughput) that the business cannot easily act on. Show accuracy charts to a CFO trying to understand cost-to-serve and the pilot gets another quarter of funding without anyone learning anything new. Closing that gap takes someone who can translate technical architecture into financial outcomes for the CFO, then turn those outcomes into system requirements for engineering. Many organizations have people who can do one or the other, but the combination of skills is rarer. This becomes especially important in the second or third quarter when sponsorship is renegotiated.

The teams that ship measure success in business outcomes and translate P&L goals into engineering requirements.

3. Design for adoption.

The hardest engineering problem in AI deployment is getting people to use it well, and this is hard to get right on the first attempt. In an earlier engagement we assumed operators would adopt a separate tool once we showed what it could do. In practice, usage barely moved. The pivot that mattered was rebuilding an integration so the AI’s recommendations appeared inside the tools they already used, where following a recommendation took fewer steps than ignoring it. Usage increased sharply over the following months.

In Case 1 we built that lesson in from the outset, and the four solutions reached high active-usage rates across the targeted frontline population within the measurement window. We do not put a single number on that outcome here, because adoption-rate definitions vary by tool, role, and time window. The result was not accidental because adoption was treated as a first-class engineering requirement. Our experience suggests a few key principles:

• Build alongside end users. Frontline operators were in the room during design. We watched them work and mapped their tools, frustrations, and workarounds, then designed the systems to fit the workflow they already had rather than replace it.
• Optimize for trust, not just accuracy. Operators with decades of experience rarely trust a black box, so the systems show their reasoning: why an action was recommended, what data was used, the confidence level. Transparency is an engineering decision, and a costlier one than it looks. It has to be built into the model interface, evaluation harness, and UI in a coordinated way.
• Ship incrementally. Each system went live independently, proved its value, and built confidence for the next. By the time the last launched, the organization had already internalized AI as part of how it works.

Adoption, measured properly, is a form of behavior change. The test we look for is whether people reach for the AI over their existing process when both are available, and keep doing so once launch attention fades.

The teams that ship design for adoption with end users and fit AI into the tools they already use.

4. Own the outcome end-to-end.

Pilots stall most often where ownership is fragmented. When the model is built by one team, the infrastructure by another, the frontend by a third, and integration managed by a vendor, nobody owns the outcome and decisions get relitigated. At scale, one engineering group needs to own enough of the stack — architecture, code, infrastructure, and the technical relationship with the client’s governance functions — to defend the design end-to-end. Not everyone must build everything, but someone has to be answerable for the whole picture, and reaching that arrangement often requires reorganization that can be uncomfortable in the short term.

At enterprise scale, technical governance reviews are inevitable: security teams audit the architecture, compliance questions data flows, senior stakeholders ask why one approach was chosen over another. The team that can speak credibly to architecture, coding standards, test coverage, and security practices retains trust. The team that defers to a vendor, or escalates to someone who was not in the room when the decisions were made, quickly loses it.

We have seen what this looks like when it goes wrong. In one earlier engagement we accepted what looked like a clean split, with a vendor owning the inference layer, a partner the data pipeline, and our team the application layer. In practice, though, every governance review revealed an ownership gap: a security question that needed three answers, an integration bug that needed three reproductions before anyone could diagnose it. The program was stalled not by technology, but coordination. The uncomfortable fix involved re-scoping to take operational accountability for the full stack, holding the vendor and partner to a defined interface as upstream suppliers rather than parallel owners. That broke a few expectations, but ended the governance stalls within the next quarter.

One note, for transparency: McKinsey supports its clients with exactly this kind of integrated capability, but there are legitimate alternatives, such as investing in platform teams, hiring senior AI engineering leadership, building deeper hyperscaler partnerships, or setting up a structured handover from a consulting partner into in-house ownership. Indeed, many of our engagements are completed this way. The point is that someone, internal or external, must own the architecture, the code, and the governance conversation as a single point accountability, rather than three.

The teams that ship give one engineering group clear accountability for the architecture, code, infrastructure, and governance relationship.

5. Staff for production AI engineering.

Production AI engineering is not a wholly new discipline. It overlaps heavily with mature MLOps and production-grade software engineering, and most of the strongest practitioners we work with come from one of those backgrounds. What is different is the surface area that LLM-based and agentic systems introduce on top:

• rigorous evaluation and output validation at every step
• model selection accounting for cost, latency, and capability constraints
• streaming and retry patterns tuned for token-by-token responses
• observability
• migration paths when the underlying model changes every few months.

Instincts about systems differ because AI failure modes are not the same as those in deterministic software, nor in classical ML pipelines.

Two recent QuantumBlack pieces map this concretely. “Generative AI workflows need engineering discipline to scale beyond the demo” argues that what breaks in production “is almost never the quality of the underlying model, but the way the system is structured,” and treats reproducibility, observability, and evaluation as first-class properties, not afterthoughts. “Agentic workflows for software development” shows the same discipline at the level of a single workflow: bounded agent execution wrapped in deterministic orchestration, with automated evaluation at every step. The engineers who do this well treat those practices as the job, not as overhead.

Teams that staff for “software engineers who have used an LLM once” tend to discover this the hard way, in production. Many are able adapt if given time to learn the new failure modes, with support from a senior practitioner who has shipped LLM systems at scale. But the adjustment happens somewhere, and a pilot is a cheap place to learn it. A high-visibility production rollout is not.

A related challenge is domain expertise. Engineers can write prompts, but they are rarely best placed to know what a good output looks like in a given business context. A subject matter expert can tell you whether a recommendation is reasonable for an aftermarket service call, but is not usually the right person to build the evaluation harness around it.

Domain experts take charge of prompts, evaluation criteria, and output validation; engineers scale and harden what works. Treating prompt engineering as a form of software engineering, rather than a domain task with engineering infrastructure around it, is a common and costly mistake.

The teams that ship pair production AI engineers with domain experts who own prompts, evaluation criteria, and output validation.

6. Codify and replicate.

Production is not the finish line, and AI projects are successful only if they keep working after they are deployed. We recently described this dynamic in our article about live AI operations, “AI value: The growing AI operations challenge”.

The real value multiplier, in our experience, is turning a single successful deployment into a repeatable approach. “One year of agentic AI,” cited in Lesson 1, puts a sharper version of this in its fifth lesson: “…the best use case is the reuse case.” Companies often build a unique agent or pipeline for each task, when the same components — ingesting, extracting, searching, analyzing — recur across many tasks and can be assembled from parts already built.

The most common first instinct is documentation, in the form of detailed pages on architectural decisions, integration choices, and lessons. But a few months later, few outside the original team have read it, and the next engagement rebuilds the same things from scratch.

What works better is packaging the decisions as runnable scaffolds — template repositories, evaluation harnesses, integration adapters for a new team to clone and adapt — with a much shorter narrative on what the patterns are and when not to use them. Engineers are far more likely to reach for the code their colleagues have already written than the documentation about it. In Case 1 we codified the most reusable artifacts as runnable assets with a thin narrative wrapper: architectural patterns for multi-agent orchestration over enterprise data, integration approaches for common back-end systems, the frontline adoption playbook, and the governance model used to clear internal risk and compliance.

The approach has since shortened the path, through people and patterns more than transplanted code. With an overlapping team, the disciplines from Case 1 — a habit of building evaluation harnesses, orchestration conventions, and shared McKinsey engineering tooling — carried into Case 2 and cut time-to-first-deployment for new use cases, even where little of the implementation transfers directly. Case 1 is a reference point for later teams to start from, rather than a blank page. The recent QuantumBlack platform architecture article frames this as building for composable and compostable assembly: modular blocks that combine into complex systems and can be replaced without redesign. That is the bar that Case 2 is being built to meet.

There is a difference between building a single instance and building a capability. Under delivery pressure, AI teams usually do the former: ship, declare victory, start the next project. Codification asks for abstraction, time spent on assets that will not directly benefit the current engagement, and an honest retrospective about which parts of the last build were actually transferable and which were incidental. That last part is the hardest, because it asks the engineers who built something to argue against parts of it. It is easy to skip, yet it is the difference between a team that delivers projects and one that builds a capability the next program can stand on. Knowing what to codify comes from having shipped across industries and use cases more than once.

The teams that ship turn reusable decisions into runnable scaffolds that later teams can clone and adapt.

7. Build business-led capability.

To escape pilot purgatory, build AI as a capability that the business owns and runs, instead of a finished system handed over to it. Lesson 5 argued that domain experts, not engineers, should own prompts, evaluation criteria, and output validation; this lesson is about the operating model around them.

In the programs that scale, business and domain leaders take ownership of the product build, setting requirements, shaping and refining prompts, and validating successive versions of the output so that hard-won domain expertise is encoded in the system rather than approximated by engineers.

Sustaining that at enterprise scale means investing in AI literacy across a broad base of business staff, so they can work shoulder-to-shoulder with technologists instead of lobbing requirements over a wall. In our experience this business–technology divide is where many programs quietly stall, and the organizations that succeed are dissolving it deliberately. The roles blend over time, and the capability to run AI becomes the enterprise’s own rather than a vendor’s or a central lab’s. This is the least engineering-centric of our lessons and, for that exact reason, the one most often left to chance.

The teams that ship make AI a business-owned capability, not a system handed over by technologists or suppliers.

Why knowing what to do is not enough

None of these seven lessons is a secret, and most technology leaders could read the list and nod. The lessons are facets of an integrated system, and each depends on the others, which is a point that Rewired and State of AI make at the strategic level. We restate them here, but from an engineering and delivery perspective.

Workflow redesign needs executive sponsorship, which needs P&L-linked KPIs, which need enough understanding of the workflow to know what to measure.

Adoption depends on trust, which depends on owning the governance relationship, which depends on a production AI engineering skill set that goes beyond “has used LLMs.”

Codification depends on having shipped enough to recognize what generalizes.

And underneath all of them sits business-led capability: the domain ownership and AI literacy that let an organization own this itself rather than depend on outside help.

The industry data broadly supports this, with some caveats. In McKinsey’s US-weighted Superagency in the workplace survey (which includes 238 C-level executives), only one percent of C-suite respondents describe their gen AI rollouts as “mature” (fully integrated into workflows, driving substantial outcomes). Another striking number, albeit a US-heavy one based on self-reporting against an ambitious bar, comes from the global State of AI 2026 survey, which shows 44 percent of overall respondents scaling AI (up from 38 percent the previous year). Among organizations with over $1B+ in revenue, the share scaling agentic AI increased from 27 percent in 2025 to 40 percent in 2026.

Cost is a material part of why so few get there. Gartner’s analysis of gen AI deployment approaches puts deployment at US$5–20 million for business-model-innovation cases (a gen AI category, not an agentic-specific figure); we see comparable ranges by analogy, well above most pilot budgets. Outside the largest revenue tier, that shifts where the bar for “worth doing at scale” sits, and why staged investment with frequent value checkpoints matters.

The organizations we have seen escape pilot purgatory rarely do it with a single existing team on its own. They combine three things: an internal core that owns the AI agenda over time, external partners (whether consulting, hyperscaler, vendor, or open-source) who bring in patterns from other deployments, and an explicit plan for bringing the capability in-house as the program matures. The cost of learning by trial and error often dwarfs the cost of borrowing pattern recognition from outside. We support clients with one version of that outside help, but the broader claim does not depend on who supplies it.

In summary

This article explains the gap between AI’s promise and its production reality and why, more often than not, it comes down to delivery rather than to better models or newer frameworks. The seven lessons from teams that ship are as follows:

• Redesign the workflow alongside the model.
• Measure in P&L rather than accuracy.
• Design for adoption.
• Own the outcome end-to-end.
• Staff for production AI engineering.
• Codify and replicate.
• Build business-led capability: the business owns the build, and AI literacy is spread across the organization.

Agentic systems, which autonomously plan, use tools, and chain actions across workflows, stress every lesson above. And the bar is rising: the State of AI 2026 reports that 20 percent of respondents have now reached the point of scaling AI agents.

Workflow redesign now crosses system boundaries, ownership blurs across many models and tools, and a mistaken agent takes a bad action rather than just returning a bad answer. McKinsey’s “Seizing the agentic AI advantage” frames that shift strategically and the QuantumBlack platform architecture piece answers it architecturally. Case 2 is our attempt at the “dozens across an enterprise” version, and we expect to write more as it matures.

One fair pushback on the “AI is the easy part” framing is worth examining: AI is not easy in any absolute sense, because building, evaluating, and tuning modern models is hard, and the field moves quickly. What we mean is that relative to redesigning workflows, securing executive alignment, engineering for adoption, defending the architecture in governance, hardening for production, and codifying the result, the model-building part is the more solved element for most enterprise use cases. And that cross-functional work is growing more demanding, not less, as systems become more autonomous and deployments more interconnected — engineering many organizations have not had to do at this scope before.

Are you interested in finding out more about what we’ve learned in McKinsey engagements? Leave us a comment or reach out to us, and follow this publication for further insights, deep-dives, and case-studies.