The short answer
Yes. A support agent can retrieve from your own handbooks, policies, and help articles, then answer only from what it finds there, with the source paragraph attached. That depends on the document set being current, on clear rules for which file wins when two disagree, and on the agent being allowed to say it does not know.
Your team already answers these questions. The answers live in a handbook nobody has opened since the last revision, a shared drive holding four folders named some variation of "policies", and the head of support's memory. Pointing an agent at that pile is most of the project. If you have read the difference between an agent and a scripted chatbot and want the agent, the next question is whether it can answer from your own material, and what has to be true first.
Where does an AI support agent get its answers?
Two places, and the gap between them is the whole product. An ungrounded model answers from what it absorbed in training. Ask it about your refund window and it produces a plausible refund window, because plausible is what it was built to produce. It has never seen your policy. It has seen thousands of other companies' policies and averages them into something that reads like yours and is not.
A grounded agent runs the other direction. Before writing a word, it searches documents you control: your handbook, your help articles, your escalation rules, the notes your team wrote for each other. It pulls the passages matching the question and composes an answer out of those only. Retrieval first, writing second. When nothing relevant comes back, it has nothing to write from, and that emptiness is the feature.
So an AI support agent is not a better writer, it is a narrower one. The model supplies fluency, the corpus supplies facts, and the build keeps that division honest.
What does your document set need to look like first?
Retrieval is only as good as the shelf it reaches into, so somebody has to walk the shelf first.
| What you have now | What retrieval does with it | What to fix first |
|---|---|---|
| Three files describing the same policy | Returns whichever one phrases it closest to the question, which is often the oldest | Keep one canonical file, move the rest out of the corpus |
| A draft named "final v3" | Reads it as settled fact | Publish it or archive it, and keep drafts out entirely |
| A PDF that is a scan of a printed page | Retrieves nothing, because the text is a picture | Run character recognition, or retype the half page that matters |
| A rule only two people know | Answers from something adjacent and wrong, or not at all | Write it down roughly; a clumsy paragraph beats an empty shelf |
| A sixty-page handbook with no headings | Returns a slab of text with the answer buried inside it | Break it into sections with headings that name the question |
The common failure is not missing documents but too many, with no marker for which is current.
Expect the corpus to come from several places at once: a wiki, a shared drive, a ticketing system's saved replies, sometimes a database holding the real answer while the document only describes it. That assembly is the data integration side of the build. If you are adding an agent to a site you already run, the site is often your cleanest source, because someone already edited it for an audience.
What happens when two of your documents disagree?
They will. A refund policy written for the old plan sits beside the new one, the handbook states one notice period and the signed agreement states another, and a support macro from last spring contradicts both. Your team settles these silently, from context. An agent has only text, so it needs the rules.
Two pieces of metadata carry the weight. An effective date lets the agent prefer the current version over the one that merely matches the question better. A rank by document type settles the rest: a signed agreement outranks a published policy, a policy outranks an internal macro, and a macro outranks a thread somebody pasted into the wiki. Within a rank, the later date wins.
Where two documents of equal rank and equal date genuinely contradict, software should not decide. The agent flags the pair, declines that question, and moves on. Wiring the flag into a queue a person reads is part of how a custom agent gets built, not something you add afterward.
Then name an owner: one person who works that queue on a standing slot and can retire a document without calling a meeting. A corpus with no owner drifts back into three versions of everything.
How do you make the agent say "I do not know"?
Grounding lowers the rate at which an agent invents things. It does not take it to zero.
Researchers at Stanford's RegLab ran the first preregistered evaluation of commercial legal research tools built on retrieval over curated case law, published as Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. Their finding: while "hallucinations are reduced relative to general-purpose chatbots," the retrieval-based tools they tested "each hallucinate between 17% and 33% of the time." Those are well-funded products reading a professionally maintained corpus, and your handbook is not tidier than a case law database. Build the part that catches a wrong answer.
Put a floor under the evidence. If retrieval returns nothing above a relevance threshold, the agent does not get to attempt an answer. It takes the abstention path instead, and that belongs in the code around the model rather than in the prompt, because asking a model to be careful is advice and a threshold is a rule.
Cite the paragraph back. Every answer carries its source: the document, the section, and the sentences it drew from. That serves two readers. The customer can check the claim against the original instead of taking the agent's word. Your team, reading transcripts later, can tell whether a wrong answer came from a bad retrieval or a stale document, which are different problems with different fixes.
Make the handoff an action, not a sentence. "Someone will get back to you" is a closing line. A real handoff opens a ticket, names its owner, attaches the transcript and the retrieved passages, and tells the customer who is picking it up and by when, which is the shape we build into the receptionist agent.
Answer the part you can prove. A half-known question is rarely a coin flip. The agent has solid evidence for two-thirds of it and none for the rest, so it answers the covered part plainly, marks where the evidence stops, and passes the remainder to a person. Hedging the whole response teaches customers to skim past hedges.
Then watch the abstention rate on the dashboard. An agent that never says "I do not know" has not reached completeness, it has stopped checking. A clean "I do not have that, here is who does" shapes what visitors take away from your site more than a confident paragraph that turns out to be wrong.
What should never go into the corpus?
Retrieval has no sense of audience unless you give it one. Every sentence in the index is answerable to anyone who asks the right question, which makes the contents of the corpus an access decision rather than a filing decision.
Three categories stay out of a customer-facing index. Personal data about named individuals, including customer records and staff files: the agent should read your policies, not your people. Internal commercial material such as discount limits, partner terms, and margin notes. And anything restricted in the system it lives in today, because copying a locked file into an index strips the lock. Permissions travel with a document inside your drive, not into a retrieval index unless somebody builds that path.
The usual arrangement is separate indexes per audience: the public agent reads the public corpus, the internal agent your staff uses reads a wider one. It fails in the safe direction, since a misfiled document is invisible rather than exposed. Finer-grained access is a design question for the custom build.
Then gate additions. One named person approves anything entering the customer-facing corpus, against one test: would you be comfortable with this text appearing word for word in a chat window at two in the morning with nobody watching.
FAQ
Can an AI support agent read our internal wiki and PDFs?
Yes, provided the text is machine-readable. A wiki, exported help articles, and text-based PDFs all index cleanly. A PDF that is a scan of a printed page is an image to the agent and retrieves nothing until character recognition runs over it.
How does the agent decide which document is right when two disagree?
By rules you set, not by judgment. Every document carries an effective date and a type rank, so a signed agreement outranks a published policy, which outranks an internal macro, and the later date wins within a rank. Genuine ties get flagged for a person.
What does the agent do when the answer is not in our documents?
It says so and hands off. Below a relevance threshold the agent is not permitted to compose an answer, so it opens a ticket, attaches the transcript, names the person picking it up, and tells the customer when to expect them. No invented answer, no dead end.
Should customer records go into the agent's document set?
No. Personal data about named individuals stays out of a customer-facing index, because anything in it is reachable by anyone who phrases a question well. If the agent needs account-specific facts, it reads them through an authenticated lookup for the verified customer.
Most of the work in a grounded support agent is not the model, it is the corpus behind it. We assemble your documents out of the systems they already live in, set the precedence rules, and build the handoff so the agent passes a question to a person rather than guessing.