An AI agent deployment plan sets out how one agent moves from idea to production: what it will do, the stages it passes through (train, shadow, certify, widen), the exit criteria for each, the approvals, staffing and rollback arrangements, and the dates. Copy the template, fill one per agent, and use the sample as a guide.
What makes an agent deployment plan different from a software plan?
A software release is mostly done when the code ships. An agent deployment is mostly done after it ships, because the agent earns authority in stages. It starts by reading and drafting alongside people, proves itself on real cases, and only then acts on its own, one capability at a time. The model is set out in train, shadow, certify, widen.
So the plan is organised around evidence gates, not build tasks. Each stage ends when its exit criteria are met, not when its dates arrive.
When should you use it?
Draft it once the role charter is agreed and before any build. Update it at each stage gate. The plan should be the document the steering group reviews, with the board paper (if needed) summarising it.
It also needs two companions: a rollback plan that says how to back out at each stage, and an approver absence cover plan so held work does not stall when approvers are away.
How do you fill in each field?
- Scope lists capabilities in the order they will be widened. Start narrow.
- Stages use the same four names for every agent so reports are comparable.
- Exit criteria are measurable: a number of cases, a pass floor, a period of shadowing with no critical misses.
- Capacity and staffing says how many people review held work at each stage, and what changes as volume moves to the agent. Staffing tends to be underplanned; see how to plan staffing when an AI agent takes on volume and how to plan capacity for AI agents.
- Release pattern says whether the agent takes all volume at once or a growing share. Running old and new side by side and switching traffic in stages, as in blue-green deployment, reduces the risk of a bad day.
The template
| No. | Section | What to write |
|---|---|---|
| 1 | Agent and owner | Name, inventory ID, accountable owner |
| 2 | Purpose | One sentence |
| 3 | Capabilities in widening order | List with target depth |
| 4 | Stage 1: train | Brief, sources, connections; exit criteria |
| 5 | Stage 2: shadow | Duration, volume, comparison method; exit criteria |
| 6 | Stage 3: certify | Cases, floor, gates; exit criteria |
| 7 | Stage 4: widen | First capability at target depth, then next; criteria per step |
| 8 | Approvals | Who signs each gate |
| 9 | Capacity and staffing | Reviewers per stage; volume expected |
| 10 | Release pattern | All at once, phased share, by segment |
| 11 | Rollback | Reference to rollback plan |
| 12 | Communications | Staff and customer communications |
| 13 | Risks and dependencies | Key risks, systems, people |
| 14 | Indicative dates | Per stage, subject to exit criteria |
A filled sample
A hypothetical bank's account servicing agent.
| No. | Entry |
|---|---|
| 3 | Answer balance and transaction questions (1); update contact details (3); order replacement card (3); change direct debit date (3) |
| 4 | Brief built from servicing procedures; sources: core banking (sealed), procedures library (sealed). Exit: brief reviewed by servicing lead, 50 sample questions answered correctly |
| 5 | Four weeks alongside the servicing team on live requests; agent drafts, staff act. Exit: 2,000 shadowed requests, no critical misses in the final two weeks |
| 6 | 1,000 past cases replayed per capability. Exit: every gate cleared at depth 3 |
| 7 | Contact details first at depth 3 for 10 days at a quarter of volume, then all volume; replacement card next; direct debit date last |
| 8 | Stage gates: servicing lead and operational risk. Widening steps: head of servicing |
| 9 | Shadow: no change. Widening: two servicing staff move to held-item review and complex cases |
| 10 | Phased share of chat volume, starting with existing customers with simple requests |
| 14 | Train: 3 weeks. Shadow: 4 weeks. Certify: 2 weeks. Widen: 6 weeks |
Row 7 is where most plans go wrong. Widening one capability at a time, with a small share of volume first, means a problem shows up in a handful of cases instead of thousands.
Questions people ask
How long does a typical agent deployment take?
From a few weeks for a narrow read-and-draft agent to several months for one that acts in customer accounts. Shadowing and certification take most of the time, and both depend on case volume.
Should the plan have fixed dates?
Give indicative dates for planning, but make it clear that exit criteria, not dates, close each stage. A plan that forces go-live by date undermines the evidence it is built on.
Who should own the deployment plan?
The agent's accountable owner in the business, supported by a delivery lead. Technology delivers parts of it, but the business owns the outcome.