Why Most AI Pilots Never Reach Production

Pilots do not fail on model quality, they fail on the half nobody demoed

The conversation at the end of a stalled pilot is always the same. The output looks good, everybody agrees it looks good, and nobody can say whether it is better than what the team does today, because nobody measured what the team does today. There is no golden set, so no version can be compared to another version. There is no write path, so nothing has been proved about permissions or rollback. The pilot has demonstrated that the model can do the task, which was rarely the open question.

This is not a model problem and buying a better model does not fix it. It is a scope problem created at kickoff, when the pilot was defined as the cheap half of the system. The fix is to write the exit criteria before the pilot starts, so that the pilot is built as a small production system rather than as a persuasive demonstration.

The Demo-to-Production Delta

For every capability a demo appears to have, it has implemented the cheap half. Naming the five halves that are missing is the quickest way to turn an argument about whether the pilot worked into a list of work items with owners.

The six gates a pilot has to pass, and who owns each

Turn the delta into gates with owners. A gate without a named owner is a gate nobody walks through, and the gates that stall pilots are almost never the model ones.

Pilot success criteria and production entry criteria are different documents

Write both, and write them before the pilot begins. Conflating them is what produces the meeting where a successful pilot is refused permission to go live and nobody can explain why the two facts coexist.

The useful discipline is to pick the pilot so that crossing from the left column to the right is short. That is mostly a selection decision rather than an engineering one, and it is covered in how to pick the first process to automate.

The cost curve nobody models before the pilot

Pilot economics mislead in two directions at once. Volume is a fraction of production, and the demo usually makes one model call per case while the production version makes several: a plan, two or three tool calls, a verification pass, and a retry when a tool times out. Multiply both factors and the monthly number can move by an order of magnitude between the pilot and the real thing.

Non-determinism against a change process built for deterministic software

This is the gate that surprises engineering-led teams. Your release process asks whether the software produces the expected output for a given input. An LLM system does not have one expected output, so the existing question has no answer and the release sits in a queue while people argue about whether that is acceptable.

Replace the question rather than fighting it. The new question is whether the graded quality of a sample stayed inside an agreed band. That needs four things: a golden set of real cases with agreed answers, a scoring function per case type, a threshold written down in advance, and a diff report showing which cases changed verdict between versions. Case-level diffs matter more than the aggregate score, because a change can hold the average steady while breaking one important category entirely.

The evals themselves are a discipline of their own, covered in writing evals for systems that are not deterministic. The short version: build the golden set from the pilot's own logs while the pilot is running, because that is the cheapest labelled data you will ever have.

Write the exit criteria before the pilot starts

This document does more for a pilot than any other hour you will spend, and an hour is roughly what it takes. It has to be written before anybody builds, because once the demo exists every criterion becomes a negotiation about whether the thing on the screen counts.

# Write this BEFORE the pilot starts. Signed by the pilot sponsor AND by the
# person who will own the system in production. If they are the same person,
# you do not yet have a production owner.

pilot: invoice-coding-agent
starts: 2026-09-01
decision_date: 2026-10-13        # a date, not "when we are happy"

baseline:                        # measured before the pilot, never after
  cases_per_month: 0
  median_minutes_per_case: 0
  error_rate_definition: how the business defines an error today
  error_rate_value: 0
  measured_on: YYYY-MM-DD

exit_criteria:                   # all true, no partial credit
  graded_sample:
    size: 150                    # fixed set, chosen before the pilot begins
    scored_by: someone who did not build it
    threshold: agreed with the golden label on N percent of cases
    per_category_floor: no single case type below M percent
  exceptions:
    unhandled_case_types: 0      # every type handled or routed
    escalation: named queue, named owner, response time
  write_path:
    proved_in: staging | production behind a flag
    idempotency: key and dedupe window documented
    rollback: one command, tested, time recorded
  observability:
    per_run_record: [input_hash, prompt_version, model_id, tool_calls,
                     output, cost, latency, verdict]
    retention_days: 90
    replay: can a past case be re-run against a new version, yes or no
  cost:
    cost_per_case_at_production_volume: 0
    ceiling: the number above which this stops being worth doing
  ownership:
    production_owner: name
    alert_rota: name or rota
    budget_code: where the running cost lands

stop_criteria:                   # write these too, or the pilot never dies
  - graded score below threshold after two improvement cycles
  - export or write path still manual at the decision date
  - no production owner named by the decision date
  - cost per case above the ceiling at production volume

How to restart a pilot that has already stalled

A stalled pilot is usually recoverable in a few weeks, because the expensive discovery is done. Work in this order, and add no new capability until step five.

1. Reconstruct the baseline from history2 to 3 days

   You missed the pre-pilot measurement, so rebuild it from the period before the pilot started: case counts, timestamps, correction and rework records. It is less clean than measuring properly, and it is enough to answer the comparison question. The method is in the baseline you must take before any automation.

2. Build the golden set out of the pilot's own logs1 day

   Sample a hundred and fifty cases the pilot has already processed, stratified across case types rather than drawn purely at random, and have an expert mark each output right or wrong with a reason. Two or three hours of expert time converts an unfalsifiable pilot into a measurable one.

3. Take one case type all the way to a real write1 to 2 weeks

   Pick the narrowest, safest case type and put it behind a feature flag with a scoped service account, an idempotency key, a full run record and a tested rollback. Depth on one type teaches you more than breadth across five, and it converts the write gate from a question into a fact.

4. Name the owner and the budget code1 day, mostly waiting

   Get a person, a rota and a code in writing before scope grows again. If nobody will accept ownership, that is the real finding, and it is better surfaced now than after launch when the alerts start arriving in an unwatched channel.

5. Set a kill date and hold itsame day

   Put a decision date in the calendar with the stop criteria attached. Pilots rarely die of failure, they die of indefinite extension, which costs more than an honest cancellation and teaches the organisation that AI projects do not finish.

Definitions that keep the go-live meeting short

Definitions

Idempotency key

A stable identifier attached to a write so that repeating the same request does not create a second record. It is what makes retries safe, and its absence is the most common reason an automation that recovers from an error leaves duplicate rows behind it.

Dead letter queue

The place a message goes after retries are exhausted, so that a failure is parked rather than lost. It only works if a named person reads it on a schedule and the items can be replayed once the underlying fault is fixed.

Canary release

Routing a small share of live traffic to a new version while the rest stays on the old one, then comparing graded quality and error rates before widening. It converts a release decision from a judgement call into a measurement with a rollback trigger.

Regression suite

The fixed set of graded cases run against every version of a non-deterministic system, reporting both the aggregate score and which individual cases changed verdict. The case-level diff is the part that catches a change which holds the average while breaking one category.

Building whole processes with these gates designed in from the start, rather than bolting them on after a demo, is the work described under business process automation.