Essay
Five stages of scaling AI in the enterprise
Experimentation, selected use cases to pilot, a platform paved path, self-service adoption, and an AI-native operating model. Most enterprises are stuck between stage two and three, because that is where the unit of work changes from a use case to a road everyone else can drive on.
Every enterprise I talk to says it wants to scale AI. When I ask what scaled would look like, the answers vary a lot more than the ambition does. So here is the model I use: five stages, each with a different unit of work, a different owner, and a different way to get stuck.
1. Experimentation
Individuals and small teams try things. Someone builds an assistant over a document set, someone else automates a report with a coding agent. There is energy, a lot of it unofficial, and very little of it is connected.
This stage is valuable and most organisations underrate it. It is where people learn what the technology can actually do, which no strategy deck will teach them. The risk is not the experiments. The risk is shadow AI: personal accounts, company data pasted into tools nobody approved, nothing traced.
What moves you on: give experimenters a safe place to play. Approved tools, models reached through a controlled gateway, no production data. Make the safe option the easiest one, and most people will take it.
2. Selected use case to pilot
A few use cases get picked, funded and owned. They have a business sponsor, success criteria, a team, a deadline. This is where most AI programmes are today, and it looks like progress, because it is.
But look at how each pilot is built. Every team solves model access, data access, identity, security review and monitoring on its own, by hand. The pilot works. The second pilot solves the same problems again, slightly differently. By the tenth, you have ten integrations, ten security reviews and ten things to maintain. That is the trap I have called pilot purgatory.
What moves you on: stop counting pilots. Count how much the next one reuses from the last one. If the answer is nothing, you are not scaling yet.
3. Platform paved path
This is the jump that matters, and it is different in kind from the stages before it. The unit of work stops being a use case and becomes the road every use case drives on.
A paved path is the set of shared capabilities that make the next agent cheap and safe to build: model access through one gateway, tools and data through a governed connector layer, a standard agent runtime, agent identity, tracing and cost by default, a catalog where people find what already exists. I described those capabilities in the two journeys essay.
The hard part is not the technology. It is three organisational moves at once:
- Ownership moves. One platform team owns the paved path as a product, with a roadmap and an SLA. Not as a side task of whichever pilot needed it first.
- Governance moves. It stops being a gate each project passes and becomes something built into the road: identity issued at registration, policy enforced at the gateway, every agent traced.
- Funding moves. Project budgets fund use cases. Nobody’s project budget funds the catalog or the runtime that every future project will need. The platform has to be funded ahead of demand, which is a hard conversation in any budget cycle.
What moves you on: do not design the platform from scratch. Your best pilot already solved the plumbing in a one-off way. Harvest it, harden it, and make it the first version of the road.
4. Self-service adoption
The paved path exists, and teams build on it without asking the central team for help. Makers in the business ship agents through templates. Engineering teams use the runtime standard without a design review. The central AI team stops being a delivery team and becomes a platform team plus a small group of enablers.
You know you are here when the platform team learns about a new agent from the catalog, not from a meeting request. The number of agents grows faster than the platform team does.
New risks show up at this stage: agent sprawl, duplicated agents, cost drifting up one small call at a time. The answer is the same as for any self-service platform. Good defaults, a registry with lifecycle (approve, deploy, retire), and visible cost and usage per team.
What moves you on: measure outcomes, not agents. Self-service makes it easy to build many agents. It does not make sure they change anything.
5. AI-native operating model
In the last stage the processes themselves change. Instead of adding an agent to an existing workflow, the workflow is redesigned around what agents and people each do well. People set direction, define standards and judge outcomes. Agents do more of the steps in between.
This is also where AI moves from assisting to acting on its own, and that jump has a cost most roadmaps leave out: it de-skills seniors. In stages one to four, AI assists. A senior engineer, analyst or buyer still does the work, faster, and their expertise is what makes the AI’s output usable. Autonomous AI takes over exactly the steps that expertise was built on. The senior’s job shifts from doing the work to specifying it and judging the result.
That shift is harder than it sounds, for two reasons. First, judging an agent’s work well requires the hands-on skill you are no longer exercising, so it erodes quietly over time. Second, juniors never get the years of doing that turned today’s seniors into good judges. An organisation can end up with agents doing the work and nobody left who could tell when they do it badly.
So the move to autonomy needs a deliberate plan for expertise: keep seniors close enough to the work that their judgment stays sharp, make reviewing agent output a real skill that is trained and measured, and design new paths for juniors to build depth when the easy work is gone.
This is less a technology stage than an organisational one. Roles change, team shapes change, how work is measured changes. It is also the stage where the earlier choices pay off or bite: if identity, tracing and governance were built into the road in stage three, an organisation can trust agents with real work. If they were not, it cannot.
Where the effort should go
Most enterprises I see are somewhere in stage two, running more and more pilots on selected use cases. The instinct is to keep going: more use cases, more teams, more vendors. But stages four and five do not come from more pilots. They come from the jump to stage three, and that jump is a change in ownership, governance and funding, more than a change in technology.
If you only do one thing this year, find the team that will own the paved path, and give it the mandate and the budget to make the road worth driving on.