The demo shows an agent can do the work. Production needs proof that it should, on whose authority, and what happens if it goes wrong. Most stalled pilots lack three things: a business owner who will answer for the agent, a plan for the evidence that would justify each step, and named people to approve its held work.
Why does the demo succeed so easily?
Because a demo is built to succeed. It runs on chosen cases, clean inputs and a happy path. It shows the agent reading a document, reasoning about it and producing a sensible outcome, and it is impressive. Sponsors see what is possible and approve a pilot.
The pilot then runs into everything the demo left out: messy inputs, rare cases, the systems of record, the people who would have to approve the agent's work, the risk function that would have to sign off, and the operational team that would have to own it. None of these is a technical problem, which is why the technical team that ran the demo often cannot solve them.
What is usually missing when a pilot stalls?
Three gaps account for most stalls. Our piece on why AI agent pilots fail covers the wider set; these are the ones that hit after a successful demo.
No owner. The pilot belongs to a technology or innovation team. Nobody in the business has agreed to own the agent in production, answer for its outcomes, set its scope or staff its review. When the pilot ends, there is nobody to hand it to. The decision to go live has no natural decision-maker, so it never gets made.
No evidence plan. The pilot was set up to show the agent works, not to produce the specific evidence that would justify giving it authority. Nobody agreed in advance what the agent would need to show, on which cases, for each capability, before moving from drafting to executing. At the end, the team has impressions and anecdotes, and the risk function has nothing it can approve.
No approvers. The pilot assumed that "a person will check" without naming who, how many items they would see, how long they would have or what authority they would hold. When someone finally does the arithmetic, the review load turns out to need people nobody budgeted for.
What else tends to block the path to production?
Several smaller gaps compound the big three.
| Gap | How it shows up |
|---|---|
| Procedures not ready | The agent performs well on demo cases and erratically on live ones because the procedures it relies on have gaps |
| Risk involved late | Risk sees the agent for the first time at the go-live decision and asks questions nobody planned to answer |
| No path back | Nobody has said what happens if the agent goes wrong, so nobody will take the risk of starting |
| Integration deferred | The pilot used exports and copies; production needs live connections with proper identities |
| No measure of success | The pilot ends without agreed criteria, so success becomes a matter of opinion |
Each of these is cheap to plan for at the start and expensive to fix at the end.
Why does a plan for going backwards help a pilot go forwards?
Because the people who must approve production need to know the risk is bounded. If the agent goes wrong in its first month, what happens? Who lowers its authority, how fast, and what happens to the work? If nobody can answer, a cautious risk function will say no, and it will be right.
A written plan for reducing the agent's authority after an incident answers that question in advance. An autonomy reduction plan template gives a structure: triggers, who decides, which capabilities drop to which depth, how affected cases are found. A clear process for rolling back an agent after a bad change adds the technical half. Together they turn going live from a leap into a controlled step.
What should a pilot charter contain from day one?
The charter should be written for production, not for the pilot.
- A named business owner who will own the agent in production and has agreed to.
- Scope: which cases and capabilities, and which stay with people.
- An evidence plan: for each capability, what the agent must show, on how many real cases, scored how, to start at draft and to move to execution.
- Named approvers, with an estimate of review load and the time allocated.
- Exit criteria for the pilot, agreed with risk before it starts.
- A reduction plan for what happens if things go wrong.
- The production path: integrations, identities, sources and procedures that must be ready.
A pilot with this charter can stall too, but it will stall for a reason someone can see and fix.
What is the trade-off?
Writing a production-ready charter makes pilots slower to start and less exciting. It forces conversations about ownership, risk and staffing before anyone has seen the agent work, and some promising ideas will not survive those conversations.
That is better than the alternative, where the idea survives the demo and dies quietly six months later after consuming a team's time. For each pilot you are running now, check whether it has a named owner, an evidence plan and named approvers. If any of the three is missing, stop adding features and fill the gap. The full sequence from build to production is set out in our guide to deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Should pilots use real customer data?
For the evidence to count, the agent should be tested on real cases from the business's own operation, handled under proper data protection controls. Pilots on synthetic or curated data produce results that will not transfer to production.
How long should a pilot run?
Long enough to produce the evidence in the plan, across the natural cycles of the work. A pilot that ends on a fixed date regardless of evidence tends to end in an inconclusive debate.
Who should decide whether a pilot goes to production?
The business owner who will run it, with risk's agreement against the criteria set at the start. Technology confirms the platform is ready. A decision made by the pilot team alone is likely to be revisited.