How an AI Support Agent Stays Grounded in Your Help Center and Policies

Two kinds of fact, two sources

A support agent needs two kinds of fact, and grounding means getting both from their real sources rather than the model's memory. Policy and FAQ content — the returns window, shipping rules, sizing — is stable text. Order-specific state — where this order is, whether this return qualifies — is live transactional data. Grounding an AI support agent in your knowledge base is the retrieval half of that; the tool calls are the other half.

The retrieval side

The help center is chunked and embedded. A customer question retrieves the most relevant policy passages, and the agent answers from those. The important detail is a relevance floor: if the best match is weak, the agent should say it doesn't have a confident answer and offer a human, not stretch a thin passage into a definitive-sounding reply.

The consistency trap

A return-eligibility rule lives in the policy corpus. This order's actual return window lives in the orders table. The agent has to cross-reference them — and if policy and order data sit in two separate systems, that check becomes an eventual-consistency problem with a customer's money on the line. On our support agent project the policy knowledge base (a few thousand chunks) and the transactional order data live in the same database, so "is this specific order still returnable" is one query, not a reconciliation across systems.

What to chunk, and how

The unit of retrieval is a chunk, and how you split the help center decides what the agent can cite. Split by topic and sub-topic — one chunk per coherent rule — rather than by fixed character count that slices a sentence in half. Keep each chunk self-contained enough to make sense on its own; a passage that says "in that case, the same window applies" is useless without the paragraph it refers to. Strip boilerplate and navigation. Tag chunks with the section they came from so the agent can point a customer to the right help article, not just paraphrase it.

Content quality is upstream of everything

Retrieval can be perfect and the answer still bad if the source says "returns may be accepted at our discretion." A vague policy produces a vague agent. Grounding doesn't paper over policy gaps — it surfaces them, because now a customer is reading your policy back through the agent every day. Treat the first weeks of transcripts as a policy audit: the questions the agent hedges on are the questions your written policy doesn't actually answer.

Keeping the index fresh

Policy changes — a seasonal returns window, a new carrier, a revised warranty — have to re-embed, or the agent confidently cites last quarter's rule. The re-index path is part of the system, not an afterthought.

Business rules belong in code, not the prompt

"Returns accepted within 30 days" should be enforced by the tool that checks eligibility, not written into the system prompt where the model might paraphrase or forget it. The model decides whether to check eligibility; the tool decides whether this order actually qualifies.

Testing grounding

• A fixed set of real questions with expected, sourced answers — run before and after any change.
• A sample of live transcripts, with every factual claim checked against a source.
• An unsupported-statement rate that should sit near zero by design.

Where this stops being right

• A tiny, stable FAQ may not need retrieval at all — the policy can be inlined in the prompt.
• A purely transactional agent (order status only) barely touches a knowledge base; don't over-build the retrieval layer.
• A very large or multilingual knowledge base changes the retrieval design — chunking, per-language content, and freshness all get harder.

FAQ

Is this just RAG? RAG is the mechanism for the policy half. The order half is grounded by tool calls against live data. A support agent needs both.

How big does the knowledge base need to be? As big as your real policies — a few thousand chunks is common, and a vector index inside your existing database handles that comfortably.

What if our policies are inconsistent? The agent will be too. Fix the source content; grounding makes the inconsistencies visible rather than hiding them.

ISTRALLEN builds support agents grounded in your policy content and your live order data, kept consistent in one place; see AI for E-commerce.