Most agent pilots that fail do not fail on accuracy. They fail because the thing that worked in a demo with one person watching it has no one watching it at 2am, and no way to turn it off without filing a ticket. The jump from pilot to production is rarely a technology problem. It is an ownership problem wearing a technology costume.
I have watched teams spend months tuning prompts and retrieval and then ship with no answer to the question “who gets paged when this does something wrong at 3am on a Saturday.” That question, not the eval score, determines whether a pilot survives contact with real volume.
The gap from pilot to production is ownership, not technology
Nobody disputes that the model works during the pilot, because the pilot is small, supervised, and forgiving. Five people run it, they catch the weird outputs themselves, and a wrong answer costs nothing because a human reads it before it reaches a customer. Production removes all three of those cushions at once: volume goes up, supervision goes away, and the blast radius of a bad output lands on a real account. The technology did not change between pilot and production. The conditions did. That is why the four ways agent pilots die almost never come down to the model itself. They come down to unattributed failures nobody is watching for and errors with no clear owner.
What a rollback plan actually needs
A rollback plan is not a paragraph in a runbook. It is a mechanism someone has actually exercised before go-live. If the only way to disable an automated workflow is to ask an engineer to revert a deploy, you do not have a rollback plan, you have a hope. A real rollback plan has three properties: it can be triggered by the person watching the system, not just the person who built it; it reverts to a known-good manual process, not to nothing; and it has been tested at least once under conditions that resemble a real incident, not just in a staging environment with fake data.
Ownership model: who gets paged
An ownership model answers one question concretely: whose job is it when the automation is wrong. Not “the team,” a name. Pilots get away without this because the builder is still watching everything personally. Production breaks this immediately, because the builder has moved on to the next pilot and the system now runs unattended for a process that used to have a human doing the work. If no name is attached to the failure path, the system will degrade quietly for weeks before anyone notices, and by then the damage is in your CRM data, your customer trust, or both.
Production readiness before you flip the switch
Production readiness is a short list, worth writing down before you negotiate scope with whoever is pushing for launch. Does the system have a kill switch that any on-call person can use without code access. Is there a dashboard that shows failure rate, not just success rate, broken out by failure type. Has someone run the numbers on what this process actually costs today, because frequency times cost times stability tells you whether this was worth automating in the first place. If the answer is “not really,” no amount of production readiness saves it.
When to kill the pilot instead of scaling it
Sometimes you should not graduate the pilot at all. If the underlying process was broken before you automated it, speeding it up just breaks it faster and louder, which is the core problem with automating a broken process rather than fixing it first. A pilot that only works because a skilled human is quietly fixing the model’s mistakes before anyone sees them is not close to production. It is a demo with a safety net you are about to remove. Kill it, fix the process underneath it, and run the pilot again with the fix in place rather than scaling the workaround.
Rollback plans and named owners do not make it into the pitch deck. But the teams that get agent pilots into durable production use are the ones who treated “who owns this when it breaks” as a launch requirement, not something to figure out after the metrics looked good.