The World Economic Forum, with Kearney, has published a blueprint for an AI-first enterprise. It is one of the best papers I have read of how deeply AI changes the way an organisation creates value, and a good deal of it is simply correct. So let me start with what it gets right, because there is a lot, and then with where I think it goes wrong, which is narrower but more important than it first appears.
Thanks for reading The Operating Model Dispatch! Subscribe for free to receive new posts and support my work.
What the paper gets right
It opens with electricity. Early manufacturers swapped steam engines for electric motors, kept the same factory layout, and got no productivity gain at all. The breakthrough came years later, when pioneers such as Ford redesigned the entire plant around what electric power made possible, distributing motors to each workstation and re-laying the line. The new force only paid off once the structure beneath it had been rebuilt to receive it. That is the right lesson for AI.
The paper is also right about people, in several places. It says that done well, human-AI teaming shifts human contribution towards judgement, creativity and orchestration, and unlocks otherwise hidden capacity. It insists that AI does not define what gets done, that human craft and taste are required for differentiation, that everything the system produces is reviewed with human eyes. It is right that the work cannot be delegated to a central technical team or run as a side initiative, and that the CEO has to own it. It is right that de-siloing is one of the real prizes. And its closing instruction to leaders, to build the capacity to learn and adapt rather than betting on a single fixed model, is continuous adaptation by another name, which is something I believe in wholeheartedly and have been arguing for.
It even names the danger correctly. In a passage on skill atrophy, it observes that as AI takes on more execution, human capability weakens through disuse, and that organisations often only discover how load-bearing their tacit knowledge was at the moment the system breaks. Skills can be retrained, it says, but judgement is harder to restore. That is right, and most documents in this genre say it.
So, this is a very good paper. Which is what makes the two places it goes wrong worth talking about.
It is right exactly where it makes the hard part sound easy
Read the paper closely and a pattern emerges. The passages I most agree with are the same passages that make the difficult thing sound like a step you have already completed.
It says, almost in passing, that while AI can work with unstructured data, the business context still needs to be coded in. True. It is also much harder than that sentence makes it sound, and most of the actual difficulty of an AI programme lives inside it. It lists the characteristics of a good starting workflow: scale, friction, cognitive complexity. Sensible criteria. But workflow friction may or may not be solvable with intelligence, you cannot know which until you have looked, and, crucially, leaders frequently do not know where their real friction sits in the first place. Choosing the workflow requires the assessment the paper treats unworthy of mention. It describes connecting tribal knowledge through a shared context layer so the engine can capture and act on live signals from work. True again, and genuinely powerful, and not remotely simple.
The clearest version of this is the section the paper calls making the business legible to the intelligence engine. The idea is that you digitise and codify how the organisation works, its decisions, rules, handoffs and actions, into an ontology the engine can reason about and eventually run on. I think this is right as a description of the destination. But notice what it assumes. It treats the operating model as already understood well enough to be encoded, so that the task becomes one of engineering: capture it, define the rules, wire it up. The understanding has, in this telling, already happened, or never needed to.
That assumption is the gap. Codifying an operating model you have never deliberately examined does not reveal it. It hard-codes it. Every undocumented dependency, every workaround that quietly holds a process together, every rule that exists because of a constraint nobody remembers, gets encoded as though it were design. The engine then learns from it and compounds on it. The paper says this approvingly, that over time allocation stops being a decision and becomes a property of the system itself. Read with a diagnostic eye, that means the structure you encoded, examined or not, becomes the structure the business can no longer easily see or change.
None of this requires a business to be failing. A company can be performing perfectly well and still have an operating model it has never actually looked at. The point of seeing it first is not fault-finding. It is that you cannot redesign a foundation you have never seen, and you certainly should not hard-wire one into a system built to run on it. The paper’s own better moments know this. Its Genesys example, where the work began with operational leaders embedded across functions to ground everything in real workflows, is what taking the foundation seriously looks like. The paper does this well in its cases and then, in its instructions, skips the step.
This is not a disagreement about where to go. It is a disagreement about whether the hard part can be assumed away. It cannot.
Who is serving whom
The second place is subtler, because the paper has the architecture right and the centre of gravity inverted.
It describes AI-first teams as organised so that the intelligence engine sits at the core while people operate at the edge. As a topology, this is fine. The engine providing context and routing in real time so that teams can navigate uncertainty and bring expertise is a reasonable way to picture how the parts connect. But read across the human-AI section as a whole and the framing keeps tilting. The block opens with revenue per head, firms reaching enormous run-rates with tiny teams, and the unmistakable message that the achievement is how few people you now need. The middle layer of human work is described as something the engine is steadily absorbing. Put together, the framing makes people the part of the system that the engine has not yet swallowed.
That is the inversion. The engine is treated as the centre, and people as what surrounds it. But the value does not originate in the engine. Judgement and subject-matter expertise are the core of what an organisation is worth, and the intelligence engine is the thing that enables the people, not the other way around. People at the edge is acceptable as a description of where they sit. People in service of the engine is the wrong account of who is serving whom.
And this connects straight back to the paper’s own warning. The tacit, load-bearing judgement it tells you to protect against atrophy is exactly the human knowledge its framing treats as a residual, the part being absorbed, the headcount being saved against. The document holds both ideas at once, a real commitment to human judgement and a structural picture that quietly subordinates people to the system, and it never reconciles them. The correction is not to value people more warmly. It is to get the direction of service right. An operating model that is human-centric is not the soft alternative to a high-performing one. It is the same thing, described correctly, because the performance was always coming from the people the engine exists to enable.
One note on survivorship
There is a reason the hard part stays invisible in a document like this. The blueprint is built from more than fifty of the world’s most advanced AI-first enterprises. These are the organisations that made it to the frontier. By construction, everyone who attempted the same redesign and came apart is absent from the sample.
I am not making the easy point that the winners got lucky. I am making the quieter one. We cannot know what this method left out, because the people who could have told us, the ones whose tacit knowledge broke when the engine absorbed it, whose unexamined operating model compounded the wrong thing, are not in the room to be studied. A blueprint drawn only from survivors can describe what the survivors have in common. It cannot show you the failure it never observed. That is not a flaw in the authors’ diligence. It is a property of where they looked, and it is one more reason the discipline that comes before the five building blocks, understanding the operating model you actually have, has to be supplied from somewhere other than this paper.
The destination is right
I do not think the WEF is wrong about where this goes. Intelligence embedded deeply into how an organisation operates is a real frontier, the firms that have reached it have done something genuine, and most of what the paper says about how they did it is sound. I think it is right about the destination and quiet about the road, in the specific way that a map drawn from arrivals is always quiet about the road. It makes the hard parts sound like steps already taken, and it puts the engine where the people should be.
Understand the operating model you actually have, including the parts that work for reasons nobody has written down, before you make it legible to a system that will compound whatever it finds. And keep the order of service straight, because the intelligence is there to enable the judgement, not to replace the people it depends on. Get those two things right and the rest of the blueprint is largely correct. Skip them, and you will have encoded an accident at scale and called it a strategy.