We Built a Chatbot Without an LLM: Here’s How It Works

A developer detailed how they built a deterministic chatbot without an LLM, prioritizing predictability over generative creativity for business-critical answers. The system uses intent matching with normalization, exact phrase matching, and keyword coverage, with responses managed by the business via a CMS like Sanity.

When you hear "chatbot" in 2026, the obvious architecture is something like: For one of our projects, we deliberately didn't do that. The chatbot needed to answer questions about things like: For those kinds of questions, we cared more about predictability than creativity. If the business says: We only work by appointment. we don't want a model to turn that into: Appointments are recommended, but you may be able to come without one. It sounds helpful. It is also wrong. So we built a deterministic chatbot with: No LLM generates the customer-facing answers. Here's how it works. Instead of asking a model: What should I answer? we ask our system: Which known intent does this question most likely belong to? The business controls the actual response. Conceptually: The important part isn't actually Fuse.js. It's everything around it. We didn't want prices, answers, keywords, or conversation options buried inside the application code. An intent can look approximately like this: export interface ChatIntent { id: string title: string phrases: string keywords: string negativeKeywords?: string answer: string priority?: number contextTags?: string requiredContextTags?: string buttons?: ChatButton enabled: boolean } For example: { "title": "Consultation price", "phrases": "How much does a consultation cost?", "What is the price of a consultation?", "What do you charge for a consultation?" , "keywords": "price", "cost", "charge", "consultation", "consult" , "answer": "A consultation costs...", "enabled": true } This separation turned out to be useful. The matcher decides what the user means. The business decides what the answer is. If the business changes a price or opening hour, it can be updated from Sanity without changing the matching algorithm. Real users don't type like your test data. They write: how much consult consultation price??? HOW MUCH how mutch is consultation Or, in Romanian: cat costa consultatia instead of: Cât costă consultația? So before matching anything, we normalize the input. A simplified version: export function normalizeText value: string : string { return value .toLowerCase .normalize 'NFD' .replace /\p{Diacritic}/gu, '' .replace / ^\p{L}\p{N}\s /gu, ' ' .replace /\s+/g, ' ' .trim } Normalization gets rid of a surprising amount of unnecessary complexity. But it isn't enough. Before doing anything clever, check the obvious cases. function exactPhraseMatch message: string, phrases: string , : boolean { return phrases.some phrase = normalizeText phrase === message } If the user asks exactly something we already know, there is little reason to rely on fuzzy matching. We can also look for known phrases inside longer messages: function containedPhraseMatch message: string, phrases: string , : boolean { return phrases.some phrase = message.includes normalizeText phrase } But things become harder when someone writes: Hi, I have a dog and I'd like to know roughly how much it would cost to bring him in for a consultation. That's where multiple signals become useful. An intent about consultation pricing might contain: 'price', 'cost', 'charge', 'consult', 'consultation' We can calculate keyword coverage: function keywordCoverage message: string, keywords: string , : number { if keywords.length return 0 const matches = keywords.filter keyword = message.includes normalizeText keyword return matches.length / keywords.length } But imagine the user only writes: price We might have: consultation price vaccine price subscription price analysis price Technically, they all match. So keywords become another signal rather than the decision. We use Fuse.js to catch approximate wording and typos. Something roughly like: python import Fuse from 'fuse.js' const fuse = new Fuse searchablePhrases, { includeScore: true, threshold: 0.35, keys: 'text' , } Then: js const results = fuse.search normalizedMessage This helps with variations such as: consultation consutation consultaton But this is where one of the more important lessons from the project appeared: The best fuzzy result isn't necessarily a safe answer. Fuse will try to find the nearest thing. Our chatbot needs to decide whether that nearest thing is actually good enough. Conceptually, each candidate gets something like: interface MatchSignals { exactPhrase: number containedPhrase: number keywordCoverage: number fuzzySimilarity: number contextBoost: number priorityBoost: number negativePenalty: number } And those signals can contribute to a score: function calculateScore signals: MatchSignals { return signals.exactPhrase 0.35 + signals.containedPhrase 0.20 + signals.keywordCoverage 0.20 + signals.fuzzySimilarity 0.15 + signals.contextBoost 0.05 + signals.priorityBoost 0.05 - signals.negativePenalty } Those weights are illustrative. The real point is the architecture: Exact phrase + Keywords + Fuzzy similarity + Context + Priority - Negative signals ↓ Confidence No single signal gets complete control. Consider: consultation price cancel consultation Both contain consultation . For the pricing intent we might have: keywords: 'price', 'cost', 'charge' but also: negativeKeywords: 'cancel', 'cancellation', 'reschedule' If someone writes: How do I cancel my consultation? the word consultation helps both candidates, but cancel actively hurts the pricing candidate. Sometimes knowing what an intent isn't is almost as useful as knowing what it is. Suppose our matcher returns: { intent: 'consultation-price', score: 0.81 }, { intent: 'subscription-price', score: 0.79 } Technically, consultation-price won. But did it really? The difference is: 0.02 We don't want: return matches 0 Instead, we can use both an answer threshold and an ambiguity margin. js const ANSWER THRESHOLD = 0.75 const AMBIGUITY MARGIN = 0.10 const best, second = matches if best.score < ANSWER THRESHOLD { return fallback } if second && best.score - second.score < AMBIGUITY MARGIN { return clarification } return answer best.intent Again, the numbers are only examples. The idea is much more important: A candidate isn't trustworthy merely because it came first. Instead of: matched not matched we use: type MatchResult = | { type: 'answer' intent: ChatIntent confidence: number } | { type: 'clarify' candidates: ChatIntent } | { type: 'fallback' } User: How much does a consultation cost? Bot: A consultation costs... User: How much does it cost? Bot: Which service would you like the price for? Consultation Tests Subscription User: I have a complicated situation... Bot: I don't have enough information to answer that correctly. Would you like me to send your question to the team? For this project, refusing to answer is a feature . Then we ran into conversations like this: User: How much does the consultation cost? Bot: ... User: And what does it include? Analyzed independently: and what does it include is almost useless. So we keep lightweight conversation context: interface ConversationContext { previousIntent?: string activeTopic?: string contextTags: string } After the first question: { previousIntent: 'consultation-price', activeTopic: 'consultation', contextTags: 'consultation' } Another intent can require: requiredContextTags: 'consultation' and receive a small scoring boost. We don't need an LLM-sized memory system for every type of conversational context. Sometimes remembering what we're currently talking about is enough. The UI doesn't contain the matching logic. It sends the message to an Astro API endpoint: POST /api/chatbot/message For example: { "message": "how much does a consultation cost", "sessionId": "..." } A simplified endpoint: python import type { APIRoute } from 'astro' import { matchMessage } from '@/lib/chatbot/matcher' export const POST: APIRoute = async { request } = { const body = await request.json const result = await matchMessage { message: body.message, sessionId: body.sessionId, } return new Response JSON.stringify result , { headers: { 'Content-Type': 'application/json', }, }, } The frontend receives a predictable result: { "type": "answer", "message": "A consultation costs...", "buttons": { "label": "Book an appointment", "action": "..." } } This also means we can replace or redesign the chat UI without rewriting the matcher. The intents don't change every few seconds. So querying Sanity for every user message would add unnecessary work. Instead, the knowledge base can be cached: js let cachedKnowledge: KnowledgeBase | null = null let expiresAt = 0 export async function getKnowledge { if cachedKnowledge && Date.now < expiresAt { return cachedKnowledge } const intents = await fetchIntentsFromSanity cachedKnowledge = buildKnowledgeBase intents expiresAt = Date.now + CACHE TTL return cachedKnowledge } Sanity remains the source of truth. It doesn't necessarily need to be part of the critical path for every message. Originally, the goal was straightforward: Reduce repetitive customer-support questions. But then we started thinking about the fallback data. Imagine seeing: 37 × "do you provide emergency services?" 21 × "can I pay monthly?" 18 × "are you open on Saturdays?" Those aren't only chatbot failures. They're customer signals. They can indicate: This changed how I think about the system. The chatbot isn't only an answering machine. It can also become a customer research interface . We deliberately avoided generative AI for official answers. But I think AI could be extremely useful one step later. Imagine collecting 500 unanswered questions and asking a model to cluster them. It might identify: Cluster: Emergency availability - do you handle emergencies? - can I come in urgently? - do you offer emergency consultations? - do you accept emergencies at night? Then a human decides: That gives us a separation I like: AI → analysis Deterministic system → official answers It's not really "AI vs no AI." It's about putting each tool in the part of the system where its characteristics are useful. The difficult part of this chatbot wasn't teaching it to answer questions. It was teaching it when not to answer . A fuzzy search system can almost always find something that looks similar. A trustworthy system needs another capability: I found something, but I'm not confident enough to use it. For prices, schedules, policies, service conditions, and similar business information, that behavior can be more valuable than generating a natural-sounding response every time. And the questions it refuses to answer? Those may eventually become the most interesting data in the whole system. If you're interested in the longer implementation guide and the product reasoning behind the experiment, I've documented the project in more detail on the Digital Empr Research & Development site https://digitalempr.ro/cercetare-si-dezvoltare . Unfortunately, the website is currently only available in Romanian, but we’re planning to translate it into English soon. Disclosure: I designed and implemented the system described here. AI tools were used to assist with editing and structuring this article; the technical decisions and project experience are my own.