Why does our AI agent hallucinate product features?

An agent invents a feature of your product because it has to produce an answer, and nothing forces it to check first. The fix is not a better prompt: you need a source that can be queried for the question asked, and a verification path cheaper than invention.

That sounds obvious until you connect a tool and watch it fail. Plenty of teams wire up a knowledge base, see the invented answers continue, and conclude the model is poor. The model is not the problem. The missing condition is spelled out in the MCP specification itself — but first, the four shapes invention takes.

Four inventions, and the mechanism behind each

The four answers below are illustrative examples: they reproduce the shape these errors take, and they are not transcripts from customer accounts. What matters is not the answer but the mechanism, and the tell that gives it away.

1. The feature that fits the neighbourhood

"Yes — you can turn on two-factor authentication under Settings → Security → Two-step login."

That menu does not exist. The model did not lie; it completed a convention. Your other settings really do live under Settings → Security, the feature is standard in your category of product, and that sentence is the most probable continuation of the question.

The tell: an interface path more specific than anything in your documentation. An invention by neighbourhood is always tidier than reality, because it was manufactured to reassure.

2. The feature that was true, and is stale

"CSV export runs from the button at the top right of the dashboard."

It did. Three weeks ago it moved, or was renamed, or was dropped for a different flow. The source the agent consulted describes a real product: the one that existed before your last deployment.

The tell: none. This is the most expensive kind of invention, because a stale answer is indistinguishable from a correct one. Only the date of the source settles it, and almost no source carries its date.

3. The neighbour's feature

"You will find those events in the Audit log tab of your workspace."

Your competitor has an audit log. The library you depend on has one. So did the product the agent was trained on. Yours does not — but the name rings true, and it is used everywhere in the same category.

The tell: vocabulary. When an agent reaches for a term your team never uses, it is not talking about your product.

4. The feature announced and never shipped

"Two-way sync is available on the Business plan."

This one comes from your public roadmap, an old blog post, or a comparison page written for sales. Those pages are indexed, they speak in the present tense, and an agent has no way to tell a promise from a fact.

The tell: the answer is present tense and the feature is future tense. An agent fed on marketing copy inherits the grammar of marketing.

These four mechanisms share exactly one thing, and it is the thing that gives you leverage: in all four, the answer was never looked up in the product.

Why connecting a source is not enough

Here is the part integration guides leave out. Handing an agent a tool does not mean it will use one. The Model Context Protocol specification, revision 2026-07-28, says so in its opening section on tools: "Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts."

Read it closely: the model decides, based on its understanding of the context. And what it bases that decision on is the tool's description — the field the spec defines as "Human-readable description of functionality". The same page confirms it in its guidance on stateful tools: a retention policy belongs in the description "so the model can see it when deciding to create state". The description is the model's decision surface.

So three conditions have to hold together before a connected source ends the inventions. None of them is automatic.

One: the tool has to be called. A tool named search_docs, described as "search the documentation", has no reason to be called when someone asks why did this behaviour change after the update. The model reads the description, sees no connection, and answers from memory. The fix is editorial before it is technical: a description should name the questions the tool answers.

Two: the source has to be able to answer the question asked. An index of documentation pages answers "what is this setting called" well. It cannot answer "what changed since v2.3", because a difference requires two states and the history that links them. The agent calls the tool, gets something off-target, and falls back on what it thinks it knows.

Three: silence has to be a result, not a void. This is the most neglected of the three, and the spec takes a side: tool execution errors are passed back to the model "to enable self-correction". A tool that answers "no information on this point" lets the agent say it does not know. An empty list, returned without a word, invites it to fill the gap itself.

And the question "what changed in the product this week?"

That is where all four mechanisms fire at once, and it is no accident: the question is about a change, and frozen knowledge only ever holds one state — the state of the day it was written.

A source that can answer it has to read two things: the code as it stands, and its history. That is what an MCP server connected to the repository does — it reads the real code, resynchronised on every push, along with commits and their diffs. The difference is not index freshness but available material: a diff carries the before, the after, and the intent written by whoever made the change. We have covered why any agent plugged into a product needs to know what shipped, and what becomes of a support agent whose knowledge predates the release.

"We'll just tell it in the prompt not to make things up"

That is the first instinct, it is a good one, and it plateaus fast. An instruction to "answer only from the provided sources" moves the problem without solving it: it does not create the source, and it does not say which source answers a question about a release. When the available source cannot answer, the agent has two exits — admit ignorance or fabricate — and the second stays more likely as long as it is cheaper.

The tooled-up instinct deserves better than a shrug: connecting the agent to the repository through the official GitHub MCP server gives access to the GitHub API, diffs included, and an equipped developer gets a lot out of it. The constraint sits elsewhere — it wants a token per requester. Your support agent inside Intercom, the client under NDA, the person in customer success will never have one. They are also the people asking the most questions about your product.

One distinction of method remains, and it decides what the agent can verify: indexing ahead of time, or reading at question time. We treated it when comparing MCP and RAG for codebase knowledge.

"And DeployIt reads your repository too"

It does, and here is the frame, in the same terms we ask of everyone else. We connect to GitHub read-only, and that access stays revocable at any time. One project, one server, with no window from one to another.

What leaves the server are answers sourced to commits and diffs, never a dump of raw source code. A requester gets the information, not the access, with no GitHub token to hand over. And because every answer carries the commit it came from, an invention becomes something anyone can spot.

What this does not fix

An agent connected to your product will keep inventing about everything else: the libraries you depend on, the conventions of a framework, your billing if billing does not live in that repository. A source grounds what it covers, and nothing more.

The fourth mechanism stays entirely human. As long as a public page announces an unshipped feature in the present tense, an agent will relay it — no server will rewrite your comparison page for you.

Mini-FAQ

How do we find out our agent is inventing before a customer tells us? Ask it ten questions whose answers you know, three of them about what your latest release changed. Those three are the only informative ones.

Should we lower the model's temperature? That setting narrows the variety of phrasings, not the absence of a source. A wrong answer delivered with confidence is still wrong.

Does this affect all our agents? The ones that talk about your product, yes — and more so when they talk to outsiders. An internal assistant gets contradicted by a colleague; an AI support agent that doesn't know your product gets believed by a customer.

Do hallucinations come back after every deployment? Every time the source falls behind the code. That is why resynchronising on each push matters more than the richness of the index.

What to take away

An agent invents when answering is possible and checking is not. The four shapes of that invention — the neighbourhood, the stale, the competitor, the announced — all reduce to an answer that was never looked up in the product.

Connecting a source is necessary and not sufficient. The tool has to be called, it has to be able to answer, and it has to be able to say it does not know. Those three conditions live in the tool's description and in the material it reads — not in the prompt.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server itself remains in early access: the design partner program is the way in for teams who want to test it against their own repository.