Almost every company we talk to has a demo that worked.
Somebody wired a model to some internal data, showed it in a meeting, and the room got quiet in the good way. Then six weeks passed and nothing about how that team works is different.
This is the part of AI adoption nobody writes about, because the interesting parts are earlier — picking the model, designing the prompt, choosing the architecture. But the failure almost never happens there. It happens in the ten feet between a working demo and the workflow it was supposed to change.
Here's what actually goes wrong, in roughly the order we encounter it.
Nobody owns it
The pilot has a champion. A champion is not an owner.
A champion is enthusiastic, usually senior enough to get the thing funded, and has eleven other priorities. When the quarter turns, the champion is in a different room. The system doesn't get turned off — it just stops being anyone's job, which produces the same result more slowly.
An owner is different. An owner is accountable for the number the system was supposed to move, and has the authority to change the process around it. If you can't name that person before the build starts, you're not building a system, you're building an artifact.
The test: when the system produces a wrong output next Tuesday, whose calendar does that land on?
It lives outside the work
Most failed deployments we inherit are technically fine and located in the wrong place.
The output arrives in a new dashboard. The workflow runs in a new tab. The team is asked to check a new tool at the start of their day, in addition to the six things they already check. Every one of those asks is small, and every one of them is a tax the system has to be dramatically better to overcome.
The systems that survive tend to be unglamorous about this. The output shows up in the ticket the support agent already has open. The research lands in the CRM field the rep already reads. The summary posts into the Slack channel where the decision was going to be made anyway. Sometimes the best interface is an email, because that's where the person already is.
If the deployment requires new behavior and new judgment and new trust, it will lose. Pick at most one of those to ask for.
People don't trust it, and they're not wrong to
Somebody gets burned early. The model confidently mislabels a customer, or drafts an email with a wrong price in it, and now the whole team's mental model is "this thing makes things up."
You don't fix that with a better prompt. You fix it structurally:
- Keep the human in the loop at the step where a mistake is expensive, and take them out of the steps where it isn't. Most workflows have exactly one or two decisions that genuinely need judgment. Automate around them, not through them.
- Show the work. A recommendation with its sources attached gets checked once and trusted after. A bare recommendation gets checked forever, which is more work than doing it manually.
- Make the failure mode boring. A system that says "I'm not sure, here are the three records I found" survives being wrong. A system that always answers doesn't.
Trust is a design constraint, not a change-management problem to be solved with a training session.
Nobody agreed what "worked" means
This one is quiet and fatal.
Without a number agreed in advance, the deployment's success becomes a matter of opinion — and after a few weeks, the loudest opinion belongs to whoever was skeptical in the first meeting. We've watched genuinely good systems get killed because nobody could say what they'd done, and mediocre ones survive because someone in leadership liked the demo.
The fix costs one conversation at the start: what is this supposed to move, and what were we at before we started? Time per case. Percentage of records that need a human touch. Hours the team spends on the Friday task. It doesn't have to be sophisticated. It has to exist, and it has to be written down before the build, because a baseline measured afterward is not a baseline.
The integration is where the schedule goes
Engineers know this and still under-plan for it, ourselves included.
The model call is the easy part. Then you meet the permissions model of the internal system nobody has documented, the API that rate-limits in a way that isn't published, the field that's a free-text string containing four different date formats, and the one team whose approval you need to write anything.
We now assume the reverse of the intuitive split. Getting to something that works in a notebook is a small fraction of the effort. Getting the same thing to run reliably inside the company's actual plumbing is most of the work. Scope accordingly, and be suspicious of any plan where integration is the last phase — that's the phase that teaches you the design was wrong.
What this implies
If you accept that the last mile is where deployments die, a few things follow that are unpopular with the way most AI work gets sold.
Strategy comes out of deployment, not before it. The team that has put something in front of users knows things the roadmap authors don't. Six-month transformation plans are usually built on assumptions that a two-week deployment would have falsified for a fraction of the cost.
Small and shipped beats broad and planned. One workflow that genuinely changed is more useful — politically as well as operationally — than nine pilots that were all "promising."
The engineer has to be in the room. Someone has to notice that the real problem isn't the one in the brief. That doesn't happen in a requirements document; it happens by watching somebody do their job and asking why they just did that.
Sometimes the answer isn't AI. A meaningful share of the workflows we're asked to put a model into should be a query, a deleted approval step, or a form with fewer fields. Saying that out loud costs a line item and buys the trust to be believed on the next thing.
None of this is a critique of the technology. The models are, for most business problems we see, already good enough. The gap is that using them requires changing how work happens, and that is an engineering and organizational problem living in the same ten feet.
That's the part we do.