How to Take an AI Pilot to a Company-Wide Rollout
Most AI pilots stall because they were built on a setup that cannot scale, such as shared API keys and local config files. Run the pilot on the same access layer you would use for the whole company, with per-user sign-in, group access, and logging. Measure what agents do in company tools, fix what fails, then add teams one group at a time, reusing the integrations and skills the pilot proved. Metorial is built to run the pilot and the rollout on the same setup.
A pilot is meant to be the first step of a rollout. Many turn out to be a separate project that has to be thrown away, because the fastest way to get a demo working is rarely a way security will approve for a thousand people.
Why do pilots stall?
Three reasons come up again and again. The pilot used shortcuts, such as one admin's API key, that security will not approve for everyone. Nobody measured whether people used it for real work, so there is no case for expanding. And each new team would need its own setup, so scaling means repeating the pilot many times.
How do you set the pilot up to scale?
Build it on the layer you would use for everyone. In Metorial, that means a portal for the pilot team, integrations published to a group, per-user sign-in for each app, and a Magic MCP URL for each person. The pilot then proves the actual rollout setup, not a demo.
What should you measure during the pilot?
- How many people on the team connected at least one app.
- Which tools and skills were used, and how often.
- Which calls failed, and why.
- What the team would add or remove.
Tracing and each account's operations view provide the first three. The fourth comes from asking. More in How to measure AI adoption.
How do you roll it out after the pilot?
1. Get approval for the setup as it is. Run the AI enablement checklist with security while the pilot runs.
2. Add the next team as a group. Create the group, allow the integrations it needs, and reuse what the pilot set up.
3. Carry over the skills that worked. Share the pilot's most used skills with the new group, and ask the new team to write one of its own.
4. Give each team an owner. Someone on the team who reads the failed calls and requests tools.
5. Review monthly. Remove tools nobody calls, spread the workflows that run every day, and widen write access where reads have gone well.
Frequently asked questions
Why do so many AI pilots never scale?
The common reasons are that the pilot used shortcuts security will not approve, that nobody measured real use, and that each new team had to be set up from scratch.
How big should the pilot be?
One team, two or three tools, and two to four weeks. Big enough to show real use, small enough to change quickly.
What should the pilot prove?
That people use it for real work, visible as tool calls in company apps, and that security can approve the setup as it is. If either is missing, fix it before adding teams.
How fast should we add teams after the pilot?
One or two at a time, each with an owner. Reusing the pilot's integrations and skills makes each new team faster than the last.
Do we need to rebuild anything after the pilot?
Not if the pilot ran on per-user sign-in, group access, and central logging. If it ran on shared keys, those connections need to be redone before anyone else joins.