Six Capabilities for Scaling AI, and the One Nobody Funds

The Vocabulary Arrives Before the Plan

You find out late, and sideways. In some committee meeting, someone mentions that progress will now be reported by domain. Two weeks later, "domain owner" shows up in a memo. The following month, a manager who never talked this way asks about the area's talent bench. Nobody explained where these words came from, but everyone started using them, and whoever doesn't use them ends up speaking an outdated language in their own company.

If you're a department head, a product leader, or a technical owner, this is the moment when it pays most to understand the framework: while the language is still being installed, and before you're asked to deliver results in it. Because that vocabulary almost always has the same origin.

The Document Everything Traces Back To

The text ordering much of this conversation today is Building the foundations for agentic AI at scale, published by McKinsey on April 2, 2026, authored by Asin Tavakoli, Brian Goodman, Henning Soller, and Kayvaun Rowshankish, with Akshat Kumar, Carlos Barreto, Satyajit Parekh, and Tancredi Bernard Litta Modignani. It's ten pages, publicly available. Worth the read.

The article opens with a number worth keeping handy for your next meeting: roughly two-thirds of companies worldwide have already experimented with AI agents, but fewer than ten percent have managed to scale them into tangible value. And when asked why, eight out of ten point to the same place: their data limitations. Not the models. The data.

That article, moreover, isn't a standalone piece. McKinsey explicitly states that its core elements come from the chapter No data architecture, no AI advantage in the second edition of Rewired (Wiley, April 14, 2026), by Eric Lamarre, Kate Smaje, and Rob Levin, with Alex Singla and Alexander Sukharevsky. Rewired is the larger framework. The article is one of its six pieces, developed in detail.

The Six Capabilities, As Formulated

The book argues that results don't come from having better technology, but from the speed and effectiveness with which a company applies that technology to real business problems — and that this only happens when six capabilities are developed. These are, in the second edition's formulation, translated into what they mean for someone actually running operations:

1. A transformation roadmap aimed at real value. Not a catalog of initiatives: a sequence of domains with committed value. The tangible test: if your project doesn't have a number attached and a baseline, it's not on the roadmap even if it's on the list.

2. A bench of highly skilled talent. The book's strong assumption is that this capability gets built in-house. The tangible test: the question isn't how many people you have, but how much of what your team knows walks out the door the day a vendor contract ends.

3. An operating model that allows movement at pace. Cross-functional teams, domain owners, distributed decision-making. The tangible test: if your team got assembled but the budget still gets allocated once a year by leadership, the domain owner doesn't decide — they ask.

4. A distributed, flexible technology environment. A modular platform where many teams build without asking permission. For you: if spinning up a new environment requires a ticket and three approvals, you bought the technology but not the model.

5. Data embedded across the organization. Data treated as a product, with an owner, quality, and shared meaning. The tangible test: this is where the semantic layer lives, which is simply agreeing on what "active customer" means before an agent decides based on that word.

6. Adoption and scaling that let solutions generate value. That what gets built actually gets used and reused. The tangible test: it's the box that decides whether your successful pilot still exists a year from now.

The April article, for its part, lands all of this in four coordinated steps:

1. Choose a few high-relevance workflows to agentify,
2. Modernize each layer of the data architecture instead of rebuilding it from scratch,
3. Ensure data quality continuously rather than through cleanup campaigns, and only then
4. Build the operating and governance model for the agents.

What the Framework Doesn't Say, and Is Worth Noticing

Go back and read the six again, and notice what's missing: there is no capability called strategy. The framework starts at the roadmap, which presupposes that strategy already exists and that the real problem is translating it into sequence, domains, and capabilities. That's a thesis, not an oversight. And it's consistent with what the authors have been saying for years: Eric Lamarre sums it up by saying that with generative AI "the toolbox got bigger," but the capabilities needed to use it stayed the same (The McKinsey Podcast, 2024).

The second thing the framework doesn't say is in what order. It's presented as a list, and lists read as if their elements were simultaneous, but no organization executes them all at the same time. They execute them in some order, and that order almost never got written down by anyone. That's where most of the money gets lost: governance drafted before knowing what will be automated, platforms bought before agreeing on what the data means.

And a third thing: of the six, two almost never get funded. The talent bench and adoption are slow, unglamorous, and impossible to show on a progress slide. They're rarely completely empty, though. They tend to be held up by someone with no budget and no formal mandate, who took them on because they cared. On the dashboard, it looks fully staffed. It isn't.

On what separates one organization from another, Kate Smaje put it with an image that's hard to forget:

Companies that pull this off operate at a different metabolic rate, and where others reallocate resources once a year, they do it every month.

(Author Talks, McKinsey, April 2026).

What You Can Do From Where You Sit

Three things, and none of them require authorization.

1. Place your current work in one of the six boxes and say it out loud in your next meeting. When the framework arrives formally, whatever isn't placed will become illegible, and illegible gets reassigned.

2. Ask about the sequence, not the list. The question "which capability comes first, and who owns that transition?" is uncomfortable, cheap to ask, and almost never has a prepared answer. That absence is information.

3. Name your area's hidden dependency: which capability only looks covered because one person is holding it up without a mandate. Naming it isn't ratting anyone out — it's turning an invisible risk into an agenda item before it collapses.

Where We're Working

At Itera we work with teams that already have this framework hanging over them, sometimes without knowing it. The work is almost never about debating the model, because the model is usually fine: it's translating it into the reality of this organization, with these budgets and these vendors, and ordering the actual sequence — which is exactly what the framework doesn't prescribe.

If you placed your team in these six boxes today, which one would you say is being held up by a single person?

That's the conversation we're interested in having.