Why most AI pilots never reach production, and how to fix it

A demo that dazzles a room and a system that survives Monday morning traffic are two different animals. Understanding why AI pilots fail is mostly about the distance between them.

The demo worked. It always works. A support agent that reads a ticket, pulls the order, drafts a refund reply, and the room goes quiet in a good way. Three weeks later that same pilot is a stalled Slack thread and a half finished Notion doc. Nobody killed it. It just stopped moving. I have walked into this exact scene more times than I can count, and if you want to understand why AI pilots fail, you have to stop looking at the model and start looking at the six inches of ground between the demo and the first real user.

I embed with companies for short stretches and put agents into production, then stay long enough to make them hold. So I am not theorizing here. The failure is almost never the thing everyone worries about in the kickoff meeting. It is rarely the model being dumb. It is the pilot being built to impress instead of built to run.

The demo is a lie you tell yourself

A demo runs on three inputs you picked by hand. Production runs on ten thousand inputs that nobody picked at all. Those are different problems wearing the same shirt. In the demo the ticket is clean, the customer is polite, the order exists, and the refund is under the policy threshold. In production the ticket is three forwarded emails deep, the customer is furious, the order ID is pasted twice, and half the message is a signature block in Comic Sans.

The pilot that shone in the meeting was tuned, consciously or not, to the happy path. And the happy path is maybe forty percent of real volume. The other sixty percent is where the whole thing lives or dies. When a pilot fails to reach production, it is usually because someone measured success on the forty percent and got ambushed by the rest.

Reason one: the scope was a science project, not a job

Most pilots are scoped as "let's see what AI can do for support." That is not a scope. That is a hobby. A real scope names one job, one trigger, one owner, and one number that has to move. Something like: when a refund request under fifty dollars comes in through Zendesk with a valid order, draft a reply and set it to pending agent review, and cut first response time on that slice from four hours to ten minutes.

Notice how much that sentence throws away. It ignores refunds over fifty dollars. It ignores fraud review. It ignores angry escalations. Good. Every clause you cut is a clause that would have stalled you in week two. The pilots that make it to production are almost embarrassingly small. The ones that die tried to be a platform before they were a feature.

Reason two: nobody planned for the wrong answer

Here is the question I ask in the first week, and it changes the room every time. What happens when the agent is confident and wrong? Not if. When. An LLM will hallucinate an order number, invent a policy, or refund the wrong customer with total composure. If your pilot has no answer for that moment, it is not going to production, and it should not.

The fix is not a better model. It is a seam. You put the agent behind a review step, you log every decision with its inputs, and you make the wrong answer cheap to catch and cheap to reverse. A draft that a human approves is a fundamentally different risk profile than an action that fires straight into your billing system. Most pilots skip the seam because the demo did not need one. Then legal asks one question and the whole thing freezes.

This is roughly the shape I reach for. A schema the model must fill, a confidence gate, and a human in the loop for anything below the line.

def handle_ticket(ticket):
    result = agent.run(ticket, response_format=RefundDecision)

    # Never trust free text. Force a typed decision.
    if result.order_id not in orders:
        return escalate(ticket, reason="unknown_order")

    if result.confidence < 0.8 or result.amount > 50:
        return queue_for_human(ticket, draft=result.reply)

    # Cheap to reverse: draft only, agent still approves.
    return set_pending_review(ticket, draft=result.reply)

# RefundDecision is a strict schema:
#   order_id: str
#   amount: float
#   reply: str
#   confidence: float
# The model returns JSON that fits, or it fails loudly.

None of that is clever. That is the point. Production code for AI is boring on purpose, because the model is the only part allowed to be surprising.

Reason three: the data was never going to be there

A lot of pilots assume a retrieval layer that does not exist yet. Someone says the agent will answer from the knowledge base, and the knowledge base turns out to be a Confluence graveyard last updated in 2022, plus tribal knowledge that lives in one senior rep's head. You cannot retrieve what was never written down.

When I scope a pilot I spend a full day just reading the actual data. Real tickets, real orders, real edge cases. I want to know if the answer the agent needs is reachable from somewhere queryable, whether that is Postgres, a pgvector index, or a plain API call to the order system. If the answer lives in a PDF that lives in an email, that is not a model problem and no amount of prompt tuning saves it. Half of why AI pilots fail is that the retrieval story was fiction and everyone agreed not to check.

Reason four: no owner, no path, no Tuesday

Pilots love a launch date and hate an owner. But a launch is an event and production is a Tuesday, and then another Tuesday. Who watches the logs? Who gets paged when latency spikes because OpenAI is having a slow afternoon? Who decides that a prompt change is worth shipping? If those names are blank, the pilot has no path to production even if the code is perfect.

I have seen genuinely good pilots rot because they were built by a consultant who left and handed off a LangGraph flow nobody internally could read. The tool does not matter much here, n8n or Zapier or raw code all work. What matters is that someone who still works there can open it on a Tuesday and change one thing without fear.

How I actually get one across the line

The move that works is shrinking the pilot until it is almost too small to be impressive, then wiring it into the real system on day one instead of day ninety. Real Zendesk, real database, real logging, from the first draft. Ship it in shadow mode where the agent drafts but a human sends, and let it run against live traffic while it stays invisible to customers.

• Pick one job with a clear trigger and a number that has to move.
• Read a day of real data before you write a line of prompt.
• Run in shadow mode against live traffic, human sends, agent drafts.
• Log every input and decision so you can see the sixty percent you missed.
• Only widen scope after the narrow version is boring and reliable.

Shadow mode is the whole trick. It gives you production traffic without production risk, and after two weeks of logs you know exactly where the agent breaks. You stop guessing. The failure modes stop being scary and start being a list. And a list is something an engineer can close out one line at a time.

A pilot that cannot survive its own logs was never a pilot. It was a screenshot with ambition.

The uncomfortable part

Most of the reasons AI pilots fail have nothing to do with AI. Scope, ownership, data access, a plan for being wrong. These are the same things that sink any software project, they just hurt faster with a model in the loop because the model is so good at looking finished when it is not. A demo hides all of it. Production hides none of it.

So if you are staring at a pilot that impressed everyone and has not moved in a month, do not go looking for a smarter model. Go find the seam you skipped, the owner you never named, and the sixty percent of traffic you never looked at. That is where it stalled. It was always going to stall there. The good news is that ground is walkable, and it is a lot shorter than the demo made it look.