Skip to main content

How to scale an AI pilot across the company.

A pilot scales when the next team reuses what the first built: the approval, the budget line, the inventory entry and the agent itself. How to plan for it.

Topic
Pilots and delivery
Products
Novie Control, Novie OS
Format
Guide
Reading time
3 min
In short

To scale an AI pilot across the company, make the second deployment cheaper than the first. Turn what the pilot proved into things the next team can reuse: an approval pattern, a budget line with a cap, an inventory entry with an owner, a measured cost per outcome, and the agent itself. Judge the pilot on whether the tenth team could run it, as well as on whether it worked.

Proving and scaling are different problems

A pilot answers one question: does this work here? Scaling answers another: can every team that needs it have it, without starting again? Most pilots are designed for the first question only. They are built by a small team with special access, approved as an exception, funded from an innovation budget, and measured on whether the demo impressed. None of that transfers.

The gap shows in every survey. McKinsey's State of AI, published in November 2025 from 1,993 respondents, found 88 percent of organisations use AI in at least one function, about one third have begun scaling it, and 7 percent describe it as fully scaled. In New Zealand, Datacom's 2026 State of AI Index found 91 percent of organisations use some form of AI and 15 percent are scaling it across the organisation.

Deloitte's State of AI in the Enterprise 2026, surveyed in late 2025 across 3,235 leaders in 24 countries, found 25 percent had moved 40 percent or more of their AI experiments into production. What separates them is how they work. McKinsey's November 2025 survey found the companies getting the most from AI were far more likely to have redesigned their workflows around it, and to have set rules for when a person checks the model's output.

What the next team needs from the first

  1. The approval, as a pattern. The scope that was signed, written so an agent built the same way can be approved in days.
  2. The budget line. What the pilot cost per run and per outcome, and the cap it ran under, so the next team can ask for a number rather than a guess.
  3. The inventory entry. The agent's row, with owner, model, tools, data and systems, so security reviews a known thing.
  4. The measure. The outcome the pilot was judged on and the result, in the units the next team's leader uses.
  5. The agent. The thing itself, kept somewhere the next team can find it and adapt it, rather than rebuilt from a description.

Success criteria that scale

Measure the pilot on five things, and write them down before it starts.

  • The outcome: what changed in the work, in the business's own units.
  • Cost per outcome: what each result cost, against the old cost of the same work.
  • Time to approval: how long the agent took to be signed off, which the next team will inherit.
  • Adoption: how many of the people it was built for use it in the fourth week, after the novelty.
  • Exceptions: how often a person had to step in, and why.

A sequence for the first ten teams

  1. Run the pilot under production rules: the real approval path, a real budget line with a cap, an owner and an inventory entry. A pilot that skipped them has proved nothing about scaling.
  2. Write the pattern: what was approved, what it cost, what it changed.
  3. Second team, same function. The closest match, to test what transfers and what was local.
  4. Third and fourth teams, adjacent functions. Different data and different leaders, the same pattern.
  5. The library. From here, teams find the agent and its pattern themselves, and the central team's job becomes keeping the library current.

What to stop doing

  • Funding each team's version separately, so the organisation pays the build cost ten times.
  • Approving each agent as if it were the first.
  • Measuring pilots on the demo.
  • Letting what one team learned leave with the person who built it.

How Novie does it

Novie Control is live. Every dollar visible. Every budget governed. Every call optimised. Every agent governed. Every agent carries a named owner, an approval trail and a full audit trail. Every AI dollar is traced to the team, the project and the owner at the moment it is spent, so cost per outcome and the approval pattern are recorded as the pilot runs.

Novie OS is launching soon. Built in your own words. Shared across the company. Kept for good. Smarter with every use. What one team builds goes into the shared agent library, so the second team starts from the agent and its approval rather than from a blank page.

Sources

  1. McKinsey, The State of AI: Global Survey 2025 (5 November 2025)
  2. Deloitte AI Institute, The State of AI in the Enterprise, 2026 edition (January 2026; surveyed August to September 2025)
  3. Datacom, 2026 State of AI Index (31 August 2026), via ChannelLife

Other articles

Frequently asked questions

How do we scale an AI pilot across the company?

Make the second deployment cheaper than the first: run the pilot under production rules, then hand the next team the approval pattern, the budget line and cap, the inventory entry, the measured cost per outcome and the agent itself.

Why do AI pilots fail to scale?

They are built for the demo: special access, an exception approval, an innovation budget and no owner. None of it transfers, so each new team starts again and the organisation pays the build cost every time.

What KPIs should an AI pilot have?

The outcome in the business's own units, cost per outcome against the old cost of the work, time to approval, adoption in the fourth week, and how often a person had to step in.

How many AI pilots should we run at once?

Fewer than most organisations run. A small number run under production rules, with owners and caps, teaches more about scaling than many run as exceptions.

Build the intelligenceyour organisation compounds.