Why AI Pilots Stall and How to Move Them to Production

An AI pilot moves to production when it has a defined job, a source of truth it can read, permissions sized to that job, a test set that defines good output, approval rules for risky actions, and a named owner after launch. Most pilots stall because those operational pieces were never built, not because the model was weak. The fix is to treat the pilot as a rough draft of a supervised agent and close each gap on purpose.

Key takeaways

• Pilots usually succeed under protected conditions (one enthusiast, clean samples, informal checking) that do not exist in daily operations.
• The blockers are mostly operational: an undefined job, borrowed knowledge and access, no test for good output, unclear approval limits, and no owner.
• Each blocker has a concrete removal step, and most of them can be done without changing the underlying model.
• Running the agent in shadow mode and then widening its authority in stages builds trust faster than a single launch date.
• Production is not an event. It is a maintained service, so someone must own monitoring, evaluation and permission review.

Why do AI pilots stall after a good demo?

A pilot is built to answer one question: can this work at all? That question is cheap to answer. One motivated person tries a model on a handful of well-chosen examples, tweaks the instructions until the output looks good, and shares a result that impresses the room.

Production asks a different question: can this work every day, for people who did not build it, on messy inputs, with real consequences when it is wrong? The answer depends on things a demo never exercises. Who is allowed to use it? What happens when a document is out of date? What happens when a login expires on a Friday evening? Who notices when quality drifts?

When those questions have no owner, the pilot does not fail loudly. It simply stops being used. People return to their old habits because the agent is not trustworthy enough to rely on and not visible enough to fix. That quiet stall is the pattern to diagnose.

The rest of this article walks through the five blockers we see most often between a promising pilot and a supervised production agent, then gives a plan for removing them in order.

Blocker one: the pilot never had a defined job

Many pilots begin with a broad aim such as help the sales team or speed up support. That is fine for exploring, but it cannot be tested, supervised or handed over. Nobody can say whether the agent did its job, because the job was never written down.

A production agent needs a role small enough to prove. That means one recurring task with a clear trigger, a known input, an expected output and an obvious point where it stops. If you are unsure which task to pick, choose a first workflow that is small enough to prove and resist the urge to widen it until it holds up.

To remove this blocker, write a short task contract. It should answer these questions in plain language:

• What starts the task, and who or what provides the input?
• What does a finished result look like, and where does it land?
• What must the agent never do on this task?
• When should it stop and hand the work to a person?
• How will we observe whether it succeeded?

If your team cannot agree on those answers, the problem is not the technology yet. It is a process question that the agent has exposed, and settling it is useful work in its own right.

Blocker two: knowledge and access were borrowed, not designed

Pilots often run on shortcuts. Someone pastes documents into a chat, or connects the agent through a personal login with wide access, because it is the fastest way to get a result. Those shortcuts are reasonable for a trial and unacceptable for an agent that acts on behalf of the company.

Two problems follow. First, the knowledge is fragile. Pasted files go stale, and the agent has no way to know which version is current. The fix is to name a source of truth for each kind of fact the agent depends on (price lists, policies, customer records), and to make the agent read from that source rather than from a copy. Stale context is one of the quietest causes of wrong answers.

Second, the access is too broad and tied to a person. When that person changes roles or leaves, the connection breaks or, worse, stays open. Production access should belong to the role, not the individual, and it should start at the smallest scope that lets the task work. Authorization guidance such as the OWASP authorization cheat sheet describes the same principle: grant only what is needed and check it on every request.

A practical way to separate permissions is to treat reading, drafting and sending as three different levels. An agent that can read a customer record and draft a reply is far easier to trust than one that can also send it. You can widen access later, once the evidence supports it.

Also plan for the boring failures. Tokens expire, services change their interfaces and a webhook occasionally arrives twice. A pilot can ignore these. A production agent needs defined behavior for each: pause, report clearly, retry safely or ask for help.

Blocker three: nobody can say what good output looks like

In a pilot, quality is judged by impression. The person who built it looks at a result and thinks it seems right. That works until a second person disagrees, or until a change to the instructions quietly makes something else worse.

Production needs a test set: a collection of real cases with an agreed description of the correct outcome. Build it from actual work. Include ordinary cases, awkward ones, and cases where the right answer is to refuse or escalate. Then run the agent against the set whenever anything changes, whether the instructions, the model, the tools or the knowledge source.

This does not need to be elaborate. A modest set of carefully chosen cases, reviewed by the person who owns the process, tells you far more than another round of informal trying. Guides such as Anthropic's overview of evals for agents make the same point: define success in terms of outcomes, grade what the agent actually did, and keep the checks repeatable. For a longer walkthrough, see how to evaluate AI agents on real business tasks.

Once a test set exists, many arguments end. Instead of debating whether the agent has gotten worse, you can look at which cases changed.

Blocker four: approval limits and visibility are unclear

The fourth blocker is the one that makes leadership hesitate, and rightly. If nobody can say what the agent is allowed to do on its own, or see what it did yesterday, approving it for real work feels like a leap of faith.

Remove it with two pieces of design.

First, decide where the agent stops and asks. Low-risk, reversible actions can run unattended. Anything that sends external messages, changes records of value, or commits the company to something should wait for a person at first. The article on where your AI agent should stop and ask covers how to draw that line.

Second, make the work observable. A useful log answers what the agent was asked, what it looked at, what it did and what it decided not to do. Observability concepts from engineering, such as traces and structured events, apply directly here. Without that record, a mistake cannot be explained and a good result cannot be defended.

The safest way to combine both is shadow mode: the agent performs the task alongside the human, produces its proposed output, and takes no action. You compare its proposals with what people actually did and widen its authority only where the two agree.

Here is an illustrative scenario. A services firm wants an agent to prepare a daily summary of new client requests and propose which team member should take each one. In shadow mode, the agent posts its proposals to a private channel while the coordinator assigns requests as usual. After a period of comparison, the team sees that routine requests match well and requests involving contract changes do not. The agent is then allowed to assign routine requests automatically, while contract-related ones keep a human decision. Nothing about the model changed. What changed was the evidence behind each permission.

Blocker five: no one owns the agent after launch

The last blocker is the most overlooked. A pilot has a champion. A production agent needs an operator.

Agents are not install-and-forget software. Instructions drift as the business changes. Integrations break when a provider updates something. Permissions accumulate unless someone reviews them. Quality shifts when the underlying model or the source documents change. If nobody is assigned to notice, the agent decays, trust falls, and the pilot ends up in the pile of tools that were tried once.

Ownership has two sides. On the business side, one person is accountable for what the agent is supposed to do and decides when its authority grows. On the technical side, someone is responsible for monitoring, re-running the test set, maintaining connections and responding when something fails. Small companies often lack the second role internally, which is why the choice between building that capability and bringing in a partner deserves a deliberate decision rather than a default.

Adoption belongs here too. Even a well-run agent stalls if the team does not understand what it does, when to trust it and how to correct it. Give people a simple way to flag a wrong result, and show them that the flags lead to changes.

A short recurring checklist keeps ownership concrete:

• Review the log for failures, escalations and unusual actions.
• Re-run the test set after any change and note what moved.
• Confirm every connection still works and still has only the access it needs.
• Check that source documents are current.
• Collect user feedback and decide which changes to make.

A step-by-step plan to move from pilot to supervised production

You do not need to fix everything at once. This order removes the blockers in a sequence that builds on itself:

• Step one: pick the single task the pilot did best and write its task contract, including the stop conditions.
• Step two: name the source of truth for each fact the task depends on, and remove pasted copies.
• Step three: replace personal logins with role-based access at the smallest scope, separating read, draft and send.
• Step four: build a test set from real cases, including ones where the agent should refuse or escalate.
• Step five: add logging that records requests, sources used, actions taken and handoffs.
• Step six: run in shadow mode and compare the agent's proposals with human decisions.
• Step seven: grant authority in stages, starting with reversible actions, and keep approval on anything external or high-value.
• Step eight: assign a business owner and a technical operator, and schedule the recurring review.

A test for whether you are ready to call it production: someone other than the builder can explain what the agent does, see what it did yesterday, and know who to call when it breaks.

How Be Human handles this transition

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which maps directly to the blockers above. Managed operations then cover the recurring work: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with the agent's identity, memory and permissions kept under the company's control. The service is remote and available in English and Portuguese.

Frequently asked questions

How long should a pilot run before moving to production? There is no fixed duration, because the right signal is evidence rather than time. Move forward when the agent has a written task contract, a test set it handles reliably, and a record from shadow mode showing where its judgment matches your team's. If those are missing, extending the pilot without adding them rarely helps.

Should we switch models if the pilot underperforms? Usually not as a first step. Poor results more often come from missing context, vague instructions or unclear success criteria than from the model itself. Fix those first, use your test set to compare options fairly, and only then consider changing the model.

Do we need a technical team to run an agent in production? Someone must be responsible for monitoring, evaluation, integrations and permissions, but that does not have to be a large in-house team. Some companies build the capability internally, others use a managed partner, and many combine the two. What matters is that the responsibility is named and the work actually happens on a schedule.

What is the biggest risk of skipping the shadow period? You grant authority without evidence, so the first sign of a problem is a real mistake in front of a customer or in a live record. Shadow mode lets you find the cases where the agent is weak while nothing depends on its answer. It also gives your team a fair basis for deciding how much to trust it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.