How to Get AI Agents Into Production (And Why Most Pilots Never Do)

Most organisations we meet have already built something with AI. A demo exists, it worked, people were impressed. Then it stopped.

The gap between a demo and a thing people rely on is where enterprise AI programmes quietly end. The reasons are consistent, and almost none of them has anything to do with the model.

Reason one: it was built on a half-connected business

A demo runs on a curated set of documents. Production runs on everything, including the contract nobody filed properly and the three versions of the pricing sheet.

An agent built on partial information does not fail loudly. It gives confident, wrong answers — which is considerably worse, because people believe it for a while.

This is why the connection work comes first, and why it is most of the job. Not the interesting part, and not the part that demos well. But an agent can only be as good as what it can reach.

Reason two: permissions were left until last

The fastest way to end an AI programme is for an agent to surface a salary, a redundancy list or a board paper to someone who should not see it. It only has to happen once.

Permissions cannot be retrofitted convincingly. The index has to respect them from the first document, so that what an agent can see for a given person is exactly what that person could already see. Getting this right at the start is unglamorous. Getting it wrong at the end is fatal.

Reason three: nobody owned it

Pilots are often run by whoever was curious. Production needs someone whose job includes it — who notices when the output degrades, who fields the complaint when it gets something wrong, who decides what happens next.

An agent without an owner does not get switched off. It gets ignored, which takes longer and teaches you less.

Reason four: the output could not be checked

The agents that reach production almost all produce something a person reviews — a brief, a draft, a flag, a populated model. The person stays in the loop, which means errors get caught and fed back.

Pilots that try to have an agent decide something unsupervised tend to stall at the risk conversation, and they are right to. The reviewable output is not a limitation to be engineered away; it is what makes deployment defensible.

Reason five: it solved a problem nobody had

A surprising number of pilots address work that was not actually painful. They came from a workshop rather than from a person.

Every agent we have seen reach production started with somebody describing a job they were tired of doing. That origin matters, because the person who resents the work will tell you the edge cases — and the edge cases are where these things break.

What the path actually looks like

Compressed to its shape:

• Connect first. Index the systems the work actually lives in, with permissions intact. Slower to start, and it removes three of the five failure modes above.
• Pick a job someone named. Not the biggest opportunity — the one with an owner who wants it.
• Ship to one team. A small group using it daily will find in a fortnight what a steering committee would not find in a quarter.
• Keep a person in the loop. Review, correct, feed back. That loop is the improvement mechanism.
• Then build the second one. The second is dramatically faster than the first, because the connection work is already done.

The measure that matters

Not accuracy, and not usage. The question is whether people would complain if you switched it off.

An agent nobody would miss is a demo that happens to still be running. An agent whose absence would be noticed within a day has made it into production — whatever the governance framework says.