NewCost control: a token allowance a month for each model choice — when one runs out, the cheaper one answers.See how it works
memtro
13 October 2026 · 4 min read

Your AI pilot did not stall because of the model

Most internal AI projects die somewhere between the demo and the second week. The model is almost never the reason, and the thing that is has a name.

Every company that has run an internal AI pilot in the last two years knows the shape of it. A demo goes well. Twenty people get access. Usage is high for nine days and then falls off a cliff, and by the end of the quarter the honest summary is it writes nice emails.

The post-mortem usually blames the model, so the next pilot waits for the next model. That pilot stalls in the same place, because the model was never the constraint.

What people actually asked it

Pull the transcripts from a stalled pilot and the questions sort into three piles.

The first pile is writing: draft this, summarise that, make this shorter. These work, which is why the pilot demos well. They are also the least valuable thing the company does.

The second pile is questions the assistant cannot answer at all. Has BigCo paid the September invoice? Who owns the billing migration? What did we promise Acme on the last call? The assistant does not know, and says so. People ask twice, get nothing twice, and stop asking.

The third pile is the expensive one: questions it answers confidently and wrongly, because the person pasted in half the context and the model filled in the rest. One of these is enough to end a pilot. Nobody wants to be the person who sent a customer a number an AI invented.

The second and third piles are the same problem. The assistant has no access to what the company knows, so it either declines or guesses.

The gap is not knowledge, it is retrieval

The company is not short of information. The answer to has BigCo paid exists, precisely, in the ledger. Who owns the billing migration was settled in a thread in March. What you promised Acme is in a meeting recording and somebody's notes.

What is missing is any path from a question to those records. So the burden falls on the person asking: find the ticket, open the CRM, check the ledger, paste the relevant parts into the chat, and hope you pasted the right parts. That is not an assistant. That is a research assignment with a writing tool at the end of it, and it costs more time than it saves, which is exactly what the usage graph shows.

The pilots that survive are the ones where the assistant can look things up itself. Not "has been fine-tuned on your data" — looked up, at the moment of asking, from the system of record, with the record named in the answer.

Three things that have to be true

It has to reach the systems of record. Not an export from six months ago. The live ticket, the live invoice, the live deal. A sync that runs hourly is a different product from a training run that happened once.

It has to cite what it used. An answer with the invoice number in it can be checked in ten seconds. An answer without one has to be verified from scratch, which costs more than doing the work yourself. Citation is not a trust feature; it is the thing that makes the output cheaper to use than to ignore.

It has to remember. If every question starts from nothing, the person asking pays the context tax every single time — re-explaining who the customer is, which system matters, what was decided last month. The second question about an account should be faster than the first. If it is not, people stop at the first.

What this changes about the business case

The usual pilot business case is about writing speed: hours saved per person per week, multiplied by a salary. It is a weak argument, and everyone in the room knows it, because the hours do not show up anywhere you can see them.

The stronger case is the one the second pile points at. How long does it currently take to answer which of our customers have an open escalation and a renewal in the next sixty days? In most companies the honest answer is somewhere between forty minutes and nobody has ever asked, because it crosses the support desk, the CRM and the ledger, and no one person has all three open.

That question has a dollar value, it gets asked every week, and it does not need a better model. It needs the model to be able to read three systems and remember what it found.

Start there. Pick the five questions your team already asks across systems, and measure whether an assistant can answer them with the records cited. If it can, adoption takes care of itself — nobody has to be persuaded to use something that answers a question they were going to spend forty minutes on. If it cannot, a newer model will not change the outcome.