Scale the operating model before you scale the agents. One agent runs on attention; ten cannot. Before adding the second and third, set up an inventory, a standard brief, a repeatable certification method, one owner per agent, and a cap on how much held work each reviewer carries. Then add agents only as review capacity grows.
What breaks when you go from one agent to several?
With one agent, the people who built it watch everything. Problems are caught by attention rather than by controls. That stops working quickly.
The usual failures are predictable. Reviewers who approved one agent's work now face three queues and start approving faster than they can read. Two agents end up with overlapping scopes and both act on the same case. Certificates issued in the same month all lapse in the same week. Nobody can say how many agents exist or who owns each one. And costs, previously one line, become impossible to attribute.
What needs to be standard before agent number two?
- An inventory of every agent: owner, capabilities, certified depth, sources, certificate dates.
- A brief template, so every agent's role, sources, connections and escalation contacts are written the same way.
- One certification method, applied to each agent's own cases. The method is shared; the certificate is not.
- A scope check that no two agents may take the same action on the same case type.
- Staggered certificate dates. Certificates lapse after 90 days, so spread them across the cycle.
- A review-load limit per person. Our analysis of how many agent approvals one person can handle well explains why this limit matters more than headcount.
What does each agent do and what stays with people as you scale?
| Task | Each agent | People |
|---|---|---|
| Its own capabilities, within its depth | Yes | Review held work and samples |
| Hand-offs to another agent | Passes the case with its record | Owners agree the hand-off rules |
| Coordinating several agents | Only an orchestrator, at depth 5, once certified to that depth | Platform owner sets its bounds |
| Deciding to add a new agent | No part | Portfolio owner, on evidence |
| Owning each agent | No part | One named owner each |
Orchestration is a later step, not a starting point. Most organisations get further with several well-bounded single agents than with one coordinator managing a crowd.
What does a well-paced scale-up look like?
Say a building society starts with one agent in its mortgage servicing team, drafting replies to redemption statement requests. After it is stable at depth 2, the operations director wants five more agents across savings, complaints and arrears.
Instead of launching five at once, the team adds them in pairs, a quarter apart. Each one goes through the same sequence: shadow on its own team's cases, certification, then depth 2. Each new agent has a named owner in the team where it works. Before each pair, the team checks reviewer load and finds that complaints reviewers are already at their limit, so the complaints agent waits until the team adds a reviewer.
A year and a half later there are five agents, not six, all certified, with certificates spread across the quarter. The pace was set by the people, not the technology. The pilot in one team was the template for each new team.
Which controls make scale safe?
- Portfolio owner: approves each new agent against the inventory and reviewer capacity. Evidence: a filed approval.
- Each agent's owner: widens depth one capability at a time. See widening an agent's depth one capability at a time. Evidence: a certificate per agent.
- Data protection lead: checks each new agent for new processing that needs an impact assessment, as set out in when a DPIA is required for AI agents. Evidence: a screening note per agent.
- Operations lead: reviews supervision coverage monthly. The question of how many people you need to supervise AI agents is answered by your own queue data. Evidence: queue ages per reviewer.
The full sequence for each agent is in our guide to deploying an AI agent.
Questions people ask
Should every team build its own agents?
Teams should own and describe their agents, but build and certify them through one shared method and platform. Otherwise each team invents its own controls, and auditors face a dozen different records.
When should we introduce an orchestrator?
Once several single agents are stable and hand-offs between them are causing delay. An orchestrator should earn depth 5 the way any agent earns its depth, on cases that show it coordinates correctly.
How do we retire an agent?
Remove its credentials, record the date and the reason, and keep its filed verdicts for your retention period. Retired agents should stay in the inventory, marked as inactive.