A pilot ends with a good result and a natural question from management: can we do the same in the other departments? The honest answer is "partly". Some of what you built is reusable. Some of it only looks reusable because the pilot team is good at working around its own gaps.
This article is for operations leads who have a working agent in one team and are asked to extend it. It separates what usually carries over from what has to be rebuilt, and suggests a simple gate to pass before each new team.
Why a pilot result does not transfer on its own
A pilot succeeds under favourable conditions. The process was chosen because it was a good fit, the team volunteered, the people around the agent knew its quirks, and somebody was watching closely. That is a good way to start, and it is also the reason the numbers will not repeat automatically.
The next department differs in ways that are easy to miss:
- Different documents. Another team keeps its rules in other places, with other owners and other levels of tidiness.
- Different exceptions. The edge cases that fill the pilot team's week are not the edge cases of finance or customer service.
- Different people. The pilot team chose to take part. The next team may have been told to.
- Different risk. The same agent that is harmless when it drafts internal answers may touch money or customer data elsewhere.
So the useful frame is not "roll out the agent" but "run a smaller pilot, using what we learned". That is much faster than the first time, but it is still a pilot.
If you have not yet closed the first one properly, start with the pilot review: expand, adjust or retire is a decision, and it should be written down before anyone asks for a second team.
What usually carries over
These parts are about control. They do not depend much on the department, so they are the best place to save time.
Guardrails and permissions. The principle of the least access needed for the task is the same everywhere. Reuse the permission model, the rule that the agent never holds more access than the process needs, and the review of that access. The details are in our guide to least privilege for AI agents. The actual permissions will differ, because the new team uses different systems; the way you decide them does not.
Escalation and handover rules. When the agent must stop and pass a case to a person is a pattern: unclear request, missing source, high-value or irreversible action, a customer who asks for a human. Keep the pattern and let the new team fill in the thresholds. See when to stop and pass the case.
The activity log and the review routine. What you record, who reads it, and how often are decisions you already made. Reusing them gives you comparable evidence across teams, which management will want later. The starting point is what to record in the activity log.
The way you measure. Reuse the structure of the scorecard - adoption, quality, rework, cost - and the habit of measuring a baseline before the agent starts. The numbers will differ per team, but if each department measures something else, nobody can say whether the programme works. The value scorecard is a reasonable template.
Incident and change handling. Who can switch the agent off, how a mistake is communicated, how a change to the brief is tested before it goes live. These are company routines, not team routines. Write them once.
What usually has to be rebuilt
These parts are about the work itself. Copying them from the pilot is where most expansions quietly go wrong.
The sources. The agent is only as good as the documents it relies on. The new team's documents have their own owners, formats and gaps, and some of the rules live in people's heads. Go through the steps in preparing company documents for an AI agent again for this team. Do not assume that a tidy knowledge base in one department says anything about the next.
The process description and the exceptions. Ask the new team to describe how the work is done today, including the exceptions and who decides them. The questions in describing the process before an AI agent work as well the second time as the first.
The brief, examples and acceptance test. A brief that was testable for one team is not automatically testable for another. Examples of good, bad and borderline output must come from the new team's real work, and the new team must be able to judge them. Reusing the template is sensible; reusing the content is not.
Training and expectations. The pilot team learned by doing, next to the people who built the agent. A new team needs less theory and more practice with its own cases: what the agent is for, what it will get wrong, how to give feedback, and what changes in their daily work. The material in getting a team ready and explaining the agent to employees applies again, adjusted for this group.
The owner. Every team that uses the agent needs a named person on its side who owns the brief, reads the review and decides on changes. It is tempting to leave this with the pilot team, because they know the agent. Resist that. If the pilot team becomes the support desk for every department, their own work suffers, and the first team to have a problem will wait in a queue.
A short gate before each new team
A gate is a short list of things that must be true before the agent goes live in a new department. It does not need to be heavy. Four checks are usually enough:
- Baseline measured. You know how long the work takes today, how many cases there are, and how often they come back for rework. Without this, success cannot be shown later.
- Test set passed. A set of real cases from the new team, with a result that the team's owner accepts. Twenty to thirty cases is a sensible start.
- Shadow period done. The agent works alongside the people for a short time and its output is compared, not used. The approach is described in staged rollout and rollback criteria.
- Rollback agreed. The team knows how work continues without the agent, and who decides to switch it off.
If one of the four is missing, delay the launch for that team. A late start costs a week; a failed start in a second department makes the third one much harder to approve.
Pace and order
Expand one team at a time, at least until the second team has run for a full review cycle. A second success is the real evidence that the approach works beyond the first group, and a second failure is much cheaper to understand when only two teams are involved.
When choosing the next team, prefer one with a similar kind of process, a willing owner and low risk, as in choosing the first process. Leave the highest-risk department for later, when the shared routines have been tested twice.
Also plan the ongoing cost. Every new team adds review time, source maintenance and support. The annual budget view helps to keep the programme honest, because savings in one department are easy to cancel out with unplanned effort in another.
What to report to management
Keep the message simple. For each team: what was measured before, what is measured now, what the review found, and what is still open. Avoid adding the teams' numbers into one headline figure early on, because the processes are different and the sample is small. A table of four or five teams with the same columns says more than a single percentage.
Common mistakes
- Treating the pilot as proof for the company. It is proof for one process and one team.
- Copying the brief and the sources unchanged. They describe somebody else's work.
- Skipping the baseline in the new team. The improvement then cannot be shown, only believed.
- Leaving the owner role with the pilot team. Support does not scale that way.
- Expanding to several teams at once. Problems then overlap, and nobody can tell which change caused which result.
- Letting each team measure differently. The programme loses the ability to compare.
Where to start
Take the team you are asked to extend the agent to next and run the four checks on paper: what is the baseline, who would own the agent, where are the sources, and what would a rollback look like. If you cannot answer two of them, the team is not ready yet, and the answers tell you what to prepare first.
The aim is not to repeat the pilot. It is to reuse the control parts that are the same everywhere, and to rebuild the work-specific parts together with the people who do the work.
