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:
import Fuse from 'fuse.js'
const fuse = new Fuse(searchablePhrases, {
includeScore: true,
threshold: 0.35,
keys: ['text'],
})
Then:
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.
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:
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:
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. 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.