RAG architecture grounded in your knowledge base, with human handoff and hallucination testing. Production-ready in 3–4 weeks. $3,999/mo retainer.
- Analyze
- Automate
- Monitor
monthly retainer
Who this is for
CX or support lead whose ticket volume is outrunning headcount. L1 questions flood the queue, generic chatbots hallucinate your own policies, and SLAs slip while agents spend half their shift on password resets.
The pain today
- L1 tickets (password reset, billing basics) consuming senior agent time
- Generic chatbots (Intercom Fin, Zendesk AI) hallucinating your specific policies
- Help center articles exist but users email instead of reading them
- Confident-sounding wrong answers — no signal that the bot is guessing
- Escalation to human means the user restates everything from scratch
The outcome you get
- RAG bot grounded in your actual docs, Notion, Zendesk, and knowledge base
- Source citations on every answer so users can verify what the bot says
- Confidence threshold — bot admits uncertainty and escalates rather than guessing
- Automatic handoff to Intercom or Zendesk with full conversation context attached
- Hallucination test suite run before every knowledge-base update ships
RAG architecture that actually works
RAG (Retrieval-Augmented Generation) keeps an LLM grounded by retrieving relevant documents from your knowledge base and feeding them as context before the model answers. That sounds simple. The failures are in the implementation details.
Done poorly: chunk your docs at fixed character counts, stuff 20 chunks into context, hope for the best. The result is confident-looking garbage. Done right, four decisions matter. Semantic chunking — split documents on meaningful boundaries (section breaks, topic shifts), not arbitrary character limits. Hybrid retrieval — combine semantic similarity search with keyword matching, then re-rank by relevance. Context discipline — give the model 3–5 high-relevance chunks, not everything that vaguely matches. Citation enforcement — the model must point to a specific source or say it doesn't know.
I built this pattern first for Instill, my self-initiated AI product launched Q1 2026, which now serves 30+ active users with 1,000+ skills saved across 45+ projects. Running an AI product through real user load exposed every edge case: sparse retrieval on unusual queries, context window overflow on long documents, embedding model drift after updates. Those lessons are baked into every chatbot engagement I scope now.
RAG bot grounded in your actual docs, Notion, Zendesk, and knowledge base
Where most RAG chatbots fail in production
Two patterns account for most of the failures I've seen when customers bring me in to fix a prior build.
The first is data quality neglect. Most teams treat ingestion as a one-time import and forget about it. Stale docs produce stale answers. Internal drafts that were never finalized get indexed alongside published policy. Low-quality content dilutes retrieval precision — the model finds the closest match, which happens to be an outdated draft from eight months ago. My ingestion pipelines version every source, skip unpublished drafts by default, and log retrieval quality over time so you can see when a doc starts hurting more than it helps.
The second is no evaluation loop. Without a hallucination test suite, you have no idea whether a knowledge-base update improved or degraded the bot until a user complains. I build a test suite of 50–100 adversarial questions with your support leads during week 2 — questions drawn from historically misanswered tickets and policy edge cases. That suite runs in CI. If a change lowers the pass rate, it doesn't ship.
30+: Active users.
Knowledge-source ingestion
Your knowledge lives in multiple systems. Help center articles (Intercom, Zendesk, Confluence, HubSpot). Internal docs (Notion, Google Docs, Slack canvases). Product documentation (GitBook, Docusaurus). Account and billing data from your app's database.
The bot needs to reach the right sources per conversation — not all sources for all users. RBAC matters: an anonymous visitor should never see internal agent notes; an enterprise customer may need access to docs a free-tier user can't reach. I wire ingestion pipelines with role-aware routing built in from the start, not bolted on later.
Schedules vary by source type. Fast-changing help articles refresh daily. Stable product documentation refreshes weekly. Every source is versioned so when the bot's behavior shifts after an update, you can diff exactly what changed.
The technical stack
Vector database: I use Pinecone for most production deployments (managed, scales without ops burden) and Qdrant for on-premise or data-residency-sensitive customers. Embedding model: OpenAI text-embedding-3-small covers most cases at low cost; for multilingual support, multilingual-e5-large. Orchestration: LangChain for most builds; LlamaIndex when the document graph is complex. LLM: Claude (Anthropic) for instruction-following and uncertainty admission; GPT-4o for multilingual or cost-sensitive deployments. I benchmark against your actual support questions in week 1 before committing.
All of this runs on your infrastructure (AWS or Vercel), not mine. The code is yours on day one — Work Made for Hire. I don't hold the keys to your production bot.
Human handoff
Handoff is where chatbots feel like a first line of defense or feel like walls. The technical pieces: when the bot escalates, the full conversation context passes to the human agent automatically. The agent doesn't ask the user to start over. Routing logic assigns tickets by intent (billing vs. technical vs. cancellation) or by SLA tier (enterprise accounts can skip the bot entirely and go straight to a human). A return path lets agents flag resolved conversations with the correct answer, feeding back into the knowledge base.
I integrate with Intercom, Zendesk, Front, and HelpScout. All four have documented handoff APIs. The integration takes about two days on a standard build — it's not the hard part. The hard part is deciding your escalation thresholds in advance, which we do together during kickoff.
Pricing and timeline
Customer support chatbots fit the AI Automation retainer at $3,999/mo. For context: custom-built enterprise RAG systems quoted by agencies typically run $30,000–$150,000 upfront with a months-long build. The retainer model inverts that — lower entry cost, faster first deployment, and ongoing refinement rather than a handoff-and-goodbye.
First-version timeline: 3–4 weeks from kickoff to production deployment. Week 1 covers knowledge-source audit and LLM benchmarking against your real questions. Week 2 covers ingestion pipeline and hallucination test suite. Weeks 3–4 cover RAG core, handoff integration, and production deployment. Retainer continues through knowledge-base tuning, new source ingestion, and guardrail refinement — most customers stay 6–12 months through initial buildout and ongoing iteration. 14-day money-back guarantee. Cancel anytime. LLM API costs (OpenAI, Anthropic) are billed at cost to you — typically $100–500/mo depending on conversation volume.
Recent proof
A comparable engagement, delivered and documented.
An AI knowledge base your whole team uses via MCP
A personal library for Skills, Agents, and Rules, built once, used across Claude, Cursor, and any MCP-compatible AI tool. Save your best workflows once. Run them anywhere.
Read the case studyKeep reading
Frequently asked questions
The questions prospects ask before they book.
I benchmark against your actual support questions in week 1 before committing. That said: Claude (Anthropic) handles most support chatbots well — it follows instructions precisely and admits uncertainty instead of fabricating. GPT-4o is a better fit for multilingual support or cost-sensitive deployments at high volume. Open-source models (Llama via Groq, Mistral) make sense when data residency requirements or very high volume push toward self-hosted. The model choice follows the use case, not a default.
Three layers work together. First, the model is only given retrieved context — it answers from your docs, not from its training data. Second, citation enforcement means it must point to a specific source or declare it doesn't know. Third, a confidence threshold scores retrieval quality; low-quality retrievals trigger escalation instead of a generated answer. No system eliminates hallucinations entirely. The hallucination test suite catches regressions before they reach production.
For well-documented L1 questions (password reset, billing basics, account settings), 30–50% deflection is a realistic range after the first month. The number rises as the knowledge base matures and the test suite catches edge cases. I set up a weekly metrics dashboard showing deflection rate, CSAT on bot interactions, escalation accuracy, and hallucination count so you're not guessing. Deflection claims above 70% for a new deployment should be treated skeptically.
No. It handles L1 and well-documented L2 questions, freeing your team for complex problems. Your agents still handle the hard cases — they're just less buried under easy ones. The right framing is that the bot takes the first pass, so your team's time goes toward work that actually requires human judgment. Most customers don't reduce headcount; they stop the hiring spiral that was caused by volume growth.
Ingestion pipelines run on a schedule — daily for fast-changing help articles, weekly for stable product docs. Every update runs through the hallucination test suite before the new index goes live. If a doc change causes test failures, the deployment holds and I flag it. You get a weekly summary of what changed in the knowledge base and how the test suite scored it.
Enterprise tiers of both Anthropic and OpenAI commit to not training on your data. I configure all deployments with enterprise privacy settings by default. For PII-sensitive conversations, I add a redaction layer before content reaches the LLM. Data processing agreements are standard when your compliance team needs them. The vector database storing your doc embeddings lives on your infrastructure, not a shared tenant.
Intercom Fin and Zendesk AI are good products for teams that want a packaged solution fast. The tradeoffs: you're constrained to their retrieval logic, their confidence tuning, and their handoff flow. A custom build lets you control chunking strategy, retrieval ranking, confidence thresholds, and the exact handoff experience. It also connects sources those platforms can't reach — your app's database, internal Notion docs, custom APIs. The custom route makes sense when the generic tools keep hallucinating your specific policies or can't access the data they'd need.