Why your AI support agent keeps getting it wrong

It's not the model.

Companies are building AI support agents on top of their documentation right now. The approach is called retrieval-augmented generation, or RAG: feed the model your help articles and KB content, have it pull the relevant pieces, and let it answer support questions from that source. Then watch it give confidently wrong answers. Edge cases missed. Instructions that don't match the product. Users who get the right topic but the wrong version.

The first instinct is to blame the AI. Try a different model. Tune the retrieval. But most of the time, the problem is the source material.

Documentation written for browsing fails at search

A human reading a help article will fill in gaps from context. They'll see a heading like "Advanced Settings" and understand it's about configuration. They'll scan until something looks relevant and read from there.

A retrieval system doesn't do that. It splits the content into chunks, converts those chunks into embeddings, and matches them against a query. If an article uses "user" in paragraph two and "operator" in paragraph four to mean the same person, those are two different concepts as far as the model is concerned. If the help content is organized around features ("The Export Menu") instead of tasks ("How to export a report"), the model retrieves a feature description when the user needs step-by-step instructions.

Terminology drift and shallow taxonomy are part of it. So is feature-based structure. These are content architecture problems, not AI problems.

Same feature. The "before" alternates between "operators" and "users" four times in five sentences — a retrieval system treats those as different concepts. The "after" uses a task-based heading and consistent second-person voice throughout.

What structured for retrieval actually means

Last year I migrated 145,000 music catalog records for WPKN 89.5 FM. The catalog had accumulated across 60 years of paper cards, dBASE, Access, and Excel. The genre field alone had over 110,000 entries representing maybe 43 real categories. "Jazz," "jazz," "Jazz/Vocal," "Vocal Jazz," "JAZZ," and "classic jazz" were all in there as distinct values.

The first task was building a controlled vocabulary. Forty-three terms. Every record maps to one of them. That's a metadata problem as much as a content problem. The search interface works because the taxonomy is clean. When someone queries "jazz," they get jazz.

An AI support agent consuming a knowledge base where "contact support" appears in 200 articles, each meaning something slightly different, has the same problem that catalog had before the taxonomy was cleaned. The model can't resolve ambiguity that the content never resolved.

The skill that transfers

At Pitney Bowes I built and maintained a knowledge base cited in over 1,700 support cases. The reason it worked was topic-based structure: one article, one task, consistent terminology. A reader who found an article could find the answer. Whether that reader was a customer or an automated retrieval system didn't change what the article needed to do.

Clean controlled vocabulary and consistent terminology. Task-based structure, with a taxonomy that reflects how users actually think about the problem. That's what makes content usable by an AI support agent. Not clever prompting or a better embedding model.

The packaging problem

Most documentation is not written this way. It grew. Products changed, people added to it, nobody maintained the taxonomy. The docs are technically accurate and practically unusable. Not by customers. Definitely not by the AI system the company just built on top of them.

The writer who can fix that is not the one who knows the most about large language models. It's the one who understands information architecture. Those people have been around for a while. They've just been writing user guides.