Build an AI Customer Support Bot That Doesn't Hallucinate

Every founder has seen the demo. A chatbot answers three softball questions about pricing and refund policy, the room nods, the contract gets signed. Two weeks after launch the same bot is telling customers their data is GDPR-exempt because it lives on Mars, the head of support is on Slack at 11pm asking why the deflection rate is 12% and CSAT is down four points, and someone is quietly drafting a procurement memo for Intercom Fin. This post is the architecture that prevents that outcome - the same one I use on every client deployment.

Why most demos fail in production

Naive support bots fail in production for three reasons, and every failure I have debugged in the last 18 months is some combination of these. Knowing the failure modes up front lets you design around them instead of patching after launch.

One: the bot answers without grounding. The model gets a question, has no real context, and generates fluent nonsense because fluent nonsense is what base LLMs are optimized for. A customer asks about the cancellation window for an annual plan, the bot confidently invents 30 days when the real answer is 14, and the support team is now triaging a refund dispute. The fix is structural: never let the generation model see a question without retrieved passages, and refuse to answer when the retriever finds nothing relevant.

Two: the bot has no idea when it is wrong. Without a confidence signal, every answer looks equally authoritative to the downstream system. The bot resolves tickets that should have escalated, escalates tickets it could have answered, and the deflection metric becomes meaningless. Confidence has to come from somewhere measurable - retrieval similarity scores, a reflection step, or both - and feed into a router that decides what to do next.

Three: nobody ran an eval. The bot worked on the demo's twelve questions. The first thousand real conversations contain four hundred questions nobody anticipated. Without a labelled eval set and a regression suite that runs on every prompt change, the team is shipping blind and only finds out about regressions through customer complaints. An eval suite that runs in CI is the single highest-ROI investment in the entire build.

The architecture that ships

The shape of a production support bot is a pipeline with explicit confidence gates. Inbound message hits a webhook from Intercom, Zendesk, or a custom widget. The classifier decides intent and routes - generic FAQ, account-specific query, sales lead, or escalate immediately. RAG retrieves the top passages from the knowledge base with a reranker on top. The generator produces an answer grounded in the cited passages, with a refusal pathway if grounding fails. The confidence router decides whether to auto-resolve, ask a follow-up, or hand off to a human with full conversation context attached.

Every stage has a budget and a fallback. Classifier returns no clear intent? Default to FAQ. Retriever returns nothing above the similarity threshold? Refuse and escalate. Generator output fails the reflection check? Escalate. The system is designed to fail toward a human, not toward a confident wrong answer. That single design choice is what separates production support bots from demos.

Knowledge base

The knowledge base is the upstream input that determines the ceiling on everything downstream. A clean, structured KB with good metadata gives you a bot that resolves 50%+ of tickets. A messy KB of stale Google Docs gives you a bot that hallucinates. The ingestion pipeline pulls from wherever your team actually writes - Notion, Confluence, Zendesk Help Center, Intercom Articles, a folder of markdown in a Git repo - and normalizes everything into a clean schema: title, body, last-updated, source URL, category, and a freshness tag.

Chunking matters more than people admit. Splitting on heading boundaries with 200 to 400 token chunks and 50 token overlap is the 2026 default. Anything bigger loses retrieval precision; anything smaller loses context. The full breakdown lives in my RAG architecture tutorial - the same chunking rules apply to support KBs and they bite hard if you skip them.

Intent classifier

Before any retrieval happens, you need to know what kind of question this is. A cheap fast model (GPT-5-mini, Claude Haiku 4.5, Llama 3.3 8B) classifies the inbound message into a small set of intents - FAQ, account-specific, billing, technical, lead, abuse, escalate-now. Use structured outputs so the response is always a valid enum value. This step costs roughly $0.0005 per call and pays for itself by routing emotional, abusive, or clearly out-of-scope messages directly to a human without burning generation tokens.

RAG layer

The retrieval step is where 73% of bot failures originate. Hybrid retrieval - dense embedding similarity combined with BM25 keyword search - beats dense-only on every support workload I have measured because customers ask in natural language but reference exact product names, error codes, and SKUs. A reranker (Cohere Rerank, Voyage rerank-2, or a custom cross-encoder) on the top 20 hybrid results cuts the input to the top 4 for generation. Citation grounding means every retrieved chunk carries its source URL so the answer can link back.

Generator

The generation model takes the user question, the retrieved passages, and a refusal-first system prompt. The output format is forced - a short answer plus a list of citation IDs that map back to the retrieved chunks. If the model wants to answer but cannot ground in any retrieved passage, the prompt instructs it to refuse and the system escalates. Claude Sonnet 4.6 and GPT-5 both follow this instruction reliably when the prompt is clear; smaller models drift.

Confidence router

Confidence is a composite score: retriever top-1 similarity, reflection check pass or fail, and a classifier-derived risk score for the intent type. Auto-resolve at confidence above 0.85, ask a clarifying follow-up between 0.5 and 0.85, escalate below 0.5. The thresholds are tuned per workload - billing questions need higher confidence than FAQ, and anything touching account state should bias toward escalation by default. The router lives in code, not in a prompt, and is the place where you encode your team's tolerance for false positives.

Human handoff

The handoff path is where most support bots quietly betray their users. A bot that escalates without context forces the human agent to start over, which wastes the customer's time and is actively worse than not having a bot. The pattern that works: the router calls a handoff tool that writes a short conversation summary, classifies the issue type, attaches the full transcript, and creates a ticket through the Intercom or Zendesk API or pings a Slack channel for the on-call agent. The human picks up with full context, the customer sees zero seams.

TypeScript implementation

The rest of the post walks through the actual code. Stack: Node 20, the Vercel AI SDK with Anthropic and OpenAI, pgvector for embeddings, Cohere for reranking. Everything below is shortened for clarity but mirrors what runs in production.

Ingest the knowledge base

The ingestion job pulls from your source of truth, chunks on heading boundaries, embeds with a strong model, and writes to pgvector with metadata. Run it on a schedule (hourly is fine for most teams) and on any KB publish webhook.

// src/ingest.ts
import { embedMany } from "ai";
import { openai } from "@ai-sdk/openai";
import { chunkOnHeadings } from "./chunker.js";
import { db } from "./db.js";

export async function ingestArticle(article: {
  id: string; title: string; body: string; url: string; updatedAt: Date;
}) {
  const chunks = chunkOnHeadings(article.body, { size: 350, overlap: 50 });
  const { embeddings } = await embedMany({
    model: openai.embedding("text-embedding-3-large"),
    values: chunks.map((c) => `${article.title}\n\n${c.text}`),
  });
  await db.kb.deleteMany({ where: { articleId: article.id } });
  await db.kb.createMany({
    data: chunks.map((c, i) => ({
      articleId: article.id, chunk: c.text, heading: c.heading,
      url: article.url, embedding: embeddings[i], updatedAt: article.updatedAt,
    })),
  });
}

Classify intent

The classifier is a single structured-output call with a tight enum. Cheap model, short prompt, never let the classifier hallucinate a new intent type - the schema constrains it.

// src/classify.ts
import { generateObject } from "ai";
import { openai } from "@ai-sdk/openai";
import { z } from "zod";

const schema = z.object({
  intent: z.enum([
    "faq", "account", "billing", "technical",
    "lead", "abuse", "escalate_now",
  ]),
  sentiment: z.enum(["neutral", "frustrated", "angry"]),
  confidence: z.number().min(0).max(1),
});

export async function classify(message: string, recent: string[]) {
  const { object } = await generateObject({
    model: openai("gpt-5-mini"),
    schema,
    system: `Classify the inbound support message into a single intent.
      escalate_now is for any explicit human request, threats, or legal language.`,
    prompt: `Recent turns:\n${recent.join("\n")}\n\nNew message: ${message}`,
  });
  return object;
}

Retrieve and rerank

Hybrid retrieval pulls the top 20 candidates from dense and sparse indices, the reranker cuts to the top 4, and the result carries source URLs so the generator can cite.

// src/retrieve.ts
import { embed } from "ai";
import { openai } from "@ai-sdk/openai";
import { CohereClient } from "cohere-ai";
import { db } from "./db.js";

const cohere = new CohereClient({ token: process.env.COHERE_API_KEY! });

export async function retrieve(query: string) {
  const { embedding } = await embed({
    model: openai.embedding("text-embedding-3-large"),
    value: query,
  });
  const dense = await db.kb.vectorSearch({ embedding, limit: 20 });
  const sparse = await db.kb.bm25Search({ query, limit: 20 });
  const merged = dedupeById([...dense, ...sparse]);

  const reranked = await cohere.rerank({
    model: "rerank-english-v3.0",
    query,
    documents: merged.map((m) => m.chunk),
    topN: 4,
  });
  return reranked.results.map((r) => ({
    ...merged[r.index],
    relevanceScore: r.relevanceScore,
  }));
}

Generate with citations and refusal

The generator gets the retrieved passages and a refusal-first prompt. Structured output guarantees we always get an answer plus citation IDs - or an explicit refusal that triggers escalation. The reflection check after generation is the last line of defence against hallucination.

// src/generate.ts
import { generateObject } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { z } from "zod";

const schema = z.object({
  answer: z.string(),
  citations: z.array(z.number()),
  refused: z.boolean(),
  refusalReason: z.string().optional(),
});

const SYSTEM = `You are a support agent for Acme. Answer ONLY from the cited
passages below. Each claim in your answer must trace to at least one passage.
If the passages do not contain the answer, set refused=true and explain
briefly. Do not invent prices, dates, policies, or capabilities. Be concise.`;

export async function generate(
  question: string,
  passages: { id: number; chunk: string; url: string }[]
) {
  const passageBlock = passages
    .map((p) => `[${p.id}] (${p.url})\n${p.chunk}`)
    .join("\n\n");
  const { object } = await generateObject({
    model: anthropic("claude-sonnet-4-6"),
    schema,
    system: SYSTEM,
    prompt: `Passages:\n${passageBlock}\n\nQuestion: ${question}`,
  });
  return object;
}

Confidence route and Slack handoff

The router consumes the retrieval scores, the generator output, and the classifier signal, and decides what happens next. Below the threshold, the handoff function writes a summary to Slack with the full transcript attached and the original ticket URL.

// src/route.ts
import { WebClient } from "@slack/web-api";

const slack = new WebClient(process.env.SLACK_BOT_TOKEN);

export async function route(ctx: {
  intent: string; topScore: number; result: any; transcript: string[];
}) {
  const confidence = ctx.result.refused ? 0 : ctx.topScore;
  if (ctx.intent === "escalate_now" || confidence < 0.5) {
    await slack.chat.postMessage({
      channel: "#support-handoff",
      text: `Escalated: ${ctx.intent}\nReason: ${ctx.result.refusalReason ?? "low confidence"}`,
      blocks: buildSummaryBlocks(ctx.transcript),
    });
    return { action: "escalate" };
  }
  if (confidence < 0.85) return { action: "clarify" };
  return { action: "auto_resolve", reply: ctx.result.answer };
}

Eval strategy - the part nobody does

The eval suite is what separates a bot that ships once from a bot that improves every week. The starting point is a labelled set of 100 real tickets sampled across your intent distribution - not synthetic, not curated demos. For each ticket, label the correct resolution path: auto-resolve with the right answer, escalate, or ask a follow-up. This takes a support lead one afternoon and is the cheapest, most valuable thing you will do on the entire project.

Run four metrics on every release. Resolution rate: what percentage of auto-resolvable tickets did the bot actually resolve correctly. Escalation rate: of tickets that should have escalated, what percentage did the bot correctly route to a human. Citation correctness: for resolved tickets, does the cited passage actually support the answer (LLM-judge with a strong model works well here). Time-to-first-response: end-to-end latency from inbound message to first agent reply.

Wire the eval into CI so every prompt change, retriever tweak, or model swap runs the full suite before merge. The full eval framework comparison (DeepEval, Braintrust, RAGAS) lives in my RAG architecture tutorial - for support workloads I default to Braintrust because the labelled-dataset UX is the best of the three.

Hallucination control

Three layered controls bring hallucination rate from ~12% on naive RAG to under 2% on production deployments. First, the refusal-first system prompt instructs the model to prefer refusal over invention and the structured output schema makes refusal a first-class branch of the response, not an exception. Second, the citation requirement forces every claim to trace to a retrieved passage; the post-hoc validator can check this mechanically because the citation IDs map to known chunks.

Third, a cheap reflection model (GPT-5-mini or Claude Haiku 4.5) reads the question, the passages, and the proposed answer, then scores whether the answer is supported. If the reflection score is below threshold, the system either retries with a stronger model or escalates. The reflection step adds 300 to 600ms of latency and roughly $0.002 per conversation; it is the single highest-ROI defence against the kind of hallucination that ends in a refund dispute.

Intercom and Zendesk integration patterns

The integration story is the same on both platforms: webhook for inbound, REST API for replies and ticket creation, conversation threading by external ID. The Intercom Conversations API and the Zendesk Sunshine Conversations API both expose the primitives you need. For Intercom specifically, register your bot as a custom AI agent so it can coexist with Fin or replace it entirely.

The conversation-context handoff is the part that matters most. When the router decides to escalate, do not just close the bot session - write a structured note to the ticket with the bot's summary, the detected intent, the confidence score, and the reason for escalation, then assign to the appropriate team. The human agent sees the bot's reasoning and the customer's full history in one view. Zendesk supports this via internal notes on the ticket; Intercom via conversation notes and custom attributes. The result is a handoff that feels seamless to the customer, which is the only metric that matters for CSAT.

Lead capture from chat

The same architecture handles lead capture with one extra branch. When the classifier returns intent=lead, the bot switches into qualification mode - a short prompt that asks two or three contextual scoring questions (company, current tooling, timeline) and pushes the qualified result to your CRM via webhook. Done well, the lead data is significantly higher quality than a generic web form because the conversation feels natural and the questions are contextual.

Keep the support and sales prompts distinct. The fastest way to damage CSAT is to have the bot try to upsell a customer who is reporting a broken integration. The classifier is the gate; once a conversation lands in support mode it stays there until the human agent picks up. Architecturally this is no different from the pattern I cover in my AI chatbot for website post - the lead-capture branch is a sibling to the support branch, not a successor.

Real metrics from a shipped deployment

Numbers from a recent B2B SaaS client deployment, three months in-production, around 12,000 tickets per month across web chat and email. Pre-launch they were running a scripted decision tree with a 9% deflection rate and a 3.8 CSAT.

The deflection rate of 47% landed after two months of eval-driven iteration. The biggest single improvement was switching from dense-only retrieval to hybrid retrieval plus a Cohere reranker, which moved resolution rate from 31% to 44% overnight. The second biggest was adding the reflection step, which dropped hallucination rate from 4.2% to 1.4% with a 0.4s latency cost.

Cost per conversation

A 4-turn conversation on the custom stack runs $0.02 to $0.08 fully loaded. The breakdown is predictable and the only variable that swings widely is generation model choice. Claude Sonnet 4.6 sits at the upper end; GPT-5-mini at the lower end with a small accuracy penalty.

At three traffic tiers: 1,000 conversations per month is $20 to $80 in inference cost; 10,000 conversations is $200 to $800; 100,000 conversations is $2,000 to $8,000. Caching the system prompt cuts the generator cost by roughly 60% on Anthropic and 50% on OpenAI - see my OpenAI API cost breakdown for the caching mechanics across providers. At 100K conversations a month the caching savings alone pay for the engineering ops time to maintain the system.

When NOT to build vs buy Intercom Fin or HubSpot AI

The build-versus-buy decision turns on three variables: monthly resolution volume, customization needs, and how much of the stack you need to own. Below the crossover point, the SaaS path always wins. Above it, the markup makes custom the rational choice.

The crossover where custom wins economically is around 5,000 to 20,000 resolutions per month. Below that, the SaaS path almost always wins on speed and total cost. Above 20K resolutions, custom wins decisively on cost, and the per-resolution markup of a SaaS bot at 100K resolutions is large enough to fund a full-time engineer. The exception is anything that needs strict data residency, a specific brand voice, or integration with proprietary systems - those land in custom from day one regardless of volume.

The 7 anti-patterns I see weekly

Every audit I run on a struggling support bot surfaces some combination of the same seven anti-patterns. None of these are novel; all of them keep showing up because the SaaS marketing layer hides them and most teams ship without an eval.

• The too-confident bot. No refusal pathway in the prompt and no confidence gating in the router. The bot answers everything with the same fluency whether it knows or not, and the first regulatory complaint arrives in week three.
• No citation requirement. The model generates plausible answers from training data instead of the KB. Looks correct in 80% of tests, hallucinates in the other 20%, and the team has no mechanism to detect which is which.
• No escalation path. The bot tries to resolve everything because there is no handoff tool. Customers end up in a clarification loop, abandon the chat, and the deflection metric incorrectly counts them as resolved.
• Hardcoded answers in the prompt. The team discovers the bot is wrong about the cancellation policy and patches it in the system prompt instead of fixing the KB. Three months later the prompt is 4K tokens of brittle rules nobody can audit.
• No eval set. Every change to the prompt or retriever is shipped on vibes. Regressions are discovered through customer complaints, which is the most expensive feedback loop possible.
• No monitoring. Token usage, hallucination rate, latency p95, escalation rate, and CSAT delta are not tracked. The team finds out about a model regression when the monthly invoice arrives.
• No fallback. The model provider has a 30-minute outage and the entire support flow goes down because there is no provider failover and no graceful degradation to a static FAQ.

The companion patterns to fix each of these - fallback model routing, hallucination-aware human-in-the-loop gates, eval-in-CI, prompt versioning, observability - are the same patterns I cover across the agentic RAG architecture post. A support bot is just a focused agent with a narrow tool surface; the production discipline is identical.

If you are scoping a support bot build and want a senior engineer who has shipped this exact architecture in production, my AI integration and AI agent development practices cover exactly this scope. I work with teams worldwide and you can also hire an AI developer in Kosovo directly. Same person who built Caldra AI and Lindi AI.

Frequently asked questions