Hallucinations are the smallest of three problems with AI agents

Everybody talks about hallucinations because they are visible and easy to demo. The three things that actually kill agent deployments never make it into a slide, because none of them shows up in a demo. Here they are, with the cost of each and a way to check whether they apply to you.

·5 min read·Antoni Łubisz
Hallucinations are the smallest of three problems with AI agents

Hallucination is the loudest problem with AI agents and the easiest one to solve. A model that invents things gives itself away immediately. The three failures that sink deployments do not demo, do not screenshot, and therefore do not appear in anybody's proposal.

All three below, with what each costs and how to test for it.

Why hallucination is a second-order problem

A language model returns the most probable answer, not the true one. Asked about your pricing, it produces a number that sounds like pricing.

You can close that. Constrain the agent to your knowledge base, require it to cite the source, and make it decline when it cannot find one. This is engineering work on a solved problem.

The trouble is that the conversation stops there. People buy protection against invention, get it, and then the deployment dies of something else entirely.

Problem one: the answers drift

An agent that worked in March gives a different answer in July to the same question. Nothing broke. Your pricing changed, a service was added, the returns policy moved, and nobody updated the knowledge base.

This is not an outage. Outages announce themselves. This is a slow separation between what the agent says and what is true, and you usually find out when a customer quotes a price from six months ago.

The cost runs two ways. You misinform a customer, and you lose the team, who quietly stop pointing anyone at the agent.

How to test: take ten questions the agent answered correctly at launch and ask them again. One stale answer means you have drift, and you need an update cycle rather than a better model.

Problem two: the bill scales with cases, not headcount

In proposals, running costs look like a subscription. In reality there are two parts and only one is fixed.

The subscription does not move when you hire five people. Model usage moves with how many cases get handled. In a small company that is usually $15 to $80 a month, but double the traffic and that line doubles while the subscription does not.

The reverse hurts more. When volume drops the subscription stays whole, because your vendor was charging for readiness rather than for cases handled.

How to test: ask what the bill looks like at twice the volume, and whether you can step down a tier through a dead quarter. “It's a small amount” means nobody ran the numbers.

Problem three: nobody is obliged to look

This is the one that goes unmentioned, because it is not a technical problem.

The agent will not report that it has been answering worse since Tuesday. It will not call when it stops catching one query in five. It will not notice that a whole category of requests stopped reaching it because somebody changed a form.

For anyone to catch that, logs have to exist, somebody has to read them, and reading them has to be in someone's job description. A tool generates none of those three, because nobody asked it to.

How to test: ask who reviews conversations in month three, and what happens when the agent starts answering badly on a Saturday. A specific answer to both tells you more about a vendor than the whole price list.

What this means for choosing a supplier

All three share one root, and it is not technology.

Drift needs an update cycle. The bill needs somebody watching it. Silent degradation needs somebody looking. Each is an obligation spread over time, not a feature to ship.

Which is why “which model is best” is the wrong opening question. The good one is: who maintains this in a year, and how will they know when it starts going wrong.

What happens when you get in touch

We start with your ten questions and check whether your current agent still answers them correctly. If you do not have one yet, we run the same test against your knowledge base and tell you how much of it is usable.

You talk to the owner, the call runs 45 minutes. If the numbers say your volume is too low for an agent to pay for itself, we say so and tell you not to build it.

If we work together you get what no tool provides. Somebody reads the conversations in month three and calls before your customer does. Somebody updates the knowledge base when your pricing changes. Somebody picks up on a Saturday, and it is in the contract rather than in good intentions.

Your code sits in your repository from day one. The warranty covers repairs at no extra charge.

Questions & Answers(FAQ)

An answer that sounds credible and is not true. It happens because the model predicts the most probable sequence of words rather than checking facts. Asked about pricing it produces a number that looks like a price without being yours.

Constrain it to your knowledge base, require a cited source, and make it decline when it cannot find one. That part is solved engineering. Keeping the knowledge base current over the following months is the harder half.

Because reality changed and the system did not. New pricing, a new service, a revised procedure. The agent answers from what it was given at launch. That is drift, not failure, and only a periodic review of answers will catch it.

There is a fixed part and a variable part. The subscription is fixed. Model usage scales with cases handled, typically $15 to $80 a month in a small company. Double the traffic and that second line doubles.

Only from logs that somebody reads. The agent will not report that it has been answering worse since Tuesday or that it stopped catching one query in five. Ask your vendor who reviews conversations in month three.

Got a similar process on your side?

If something in this article sounds like your day-to-day - let's talk. We'll tell you plainly what can be improved, and what's not worth touching.