AI chatbot development
AI chatbots that answer from your data, not from guesswork
A useful chatbot is grounded in documents you control and honest about what it does not know. We build customer support assistants, internal knowledge bots, and WhatsApp agents on OpenAI and Anthropic Claude, from Colombo.
Capabilities
Chatbots we build
Four patterns cover most of what businesses actually need. The engineering difference between them is smaller than it looks; the difference in how you evaluate them is not.
Customer support assistants
Answers drawn from your product documentation, policies, and past tickets, with a clean handover to a human the moment the question goes outside what the assistant can support.
Internal knowledge assistants
A way for staff to ask questions of the material the company already has — procedures, contracts, historical records — without knowing which document holds the answer or who to ask.
WhatsApp and messaging bots
Conversational access on the channel customers already use, wired into the same grounded retrieval as everything else rather than a separate set of scripted replies.
Document Q&A over private data
Upload a corpus and ask questions of it, with answers that cite the source passage so a person can verify the claim instead of taking it on faith.
Why grounding matters more than the model
A language model on its own will answer confidently from its training data, which does not include your prices, your policies, or your product. Retrieval-augmented generation fixes this by finding the relevant passages in your own documents first and instructing the model to answer only from those. The model supplies the language; your documents supply the facts.
This is the single decision that separates a chatbot people trust from one that quietly invents a refund policy. It also makes the system maintainable — when a policy changes you update the document, not a prompt buried in code.
Practically, it means a document pipeline: content is split into passages, converted to embeddings, and stored in a vector index. At query time the closest passages are retrieved and passed to the model along with the question. We use pgvector where PostgreSQL is already in play, which avoids adding a database to your estate for no reason.
Knowing when to say I don't know
An assistant that declines to answer is more valuable than one that always produces something. Confident wrong answers destroy user trust quickly and are difficult to detect at scale, because nothing errors — the output looks exactly like a correct answer.
We build in explicit fallbacks: a confidence threshold below which the assistant hands off rather than guesses, escalation into a human queue, and citations on answers so a reader can check the source. Where the stakes justify it, we log every exchange so you can review what the assistant is actually telling people.
Choosing a model, and changing your mind later
We build against OpenAI and Anthropic Claude, and against open-source models where data residency, cost at volume, or offline operation make a hosted API the wrong fit. The right choice depends on the task, not on which vendor is currently ahead on benchmarks.
More importantly, we keep the model behind an interface. Model quality and pricing in this field move faster than any procurement cycle, and a system welded to one provider's API is a system you will pay to rebuild. Swapping the underlying model should be a configuration change and an evaluation run, not a project.
Evaluating before you launch
Chatbots need a test set the same way any other software needs tests — a fixed list of representative questions with known-good answers, run on every change. Without one, you are shipping on vibes, and quality regressions from a prompt tweak are invisible until a customer finds them.
We build that set with you from real questions your customers and staff already ask. It is also the artefact that makes the launch decision objective rather than a matter of nerve.
Stack
What we build on
Models
- OpenAI
- Anthropic Claude
- Open-source models
Retrieval
- LangChain
- pgvector
- Hugging Face
Application
- Python
- FastAPI
- Node.js
- Next.js
Infrastructure
- AWS
- GCP
- Docker
- PostgreSQL
FAQ
Questions we get asked
What is the difference between this and a scripted chatbot?
A scripted bot follows decision trees somebody wrote by hand — it handles the paths that were anticipated and fails on everything else. An LLM assistant grounded in your documents answers questions nobody wrote a branch for, in the user's own phrasing, and can be updated by editing a document rather than rewiring a flow.
Does our data get used to train the model?
Not under the standard enterprise API terms of the major providers, which exclude API traffic from training. Where that assurance is not sufficient — regulated data, or a policy that private information may not leave your infrastructure — we build on open-source models you host yourself.
Can it work over WhatsApp?
Yes, and for many Sri Lankan businesses that is the channel that matters most. The messaging integration is a thin layer over the same grounded retrieval system, so the assistant behaves identically whether it is reached through WhatsApp, your website, or an internal tool.
What if it gives a customer the wrong answer?
You reduce the odds with grounding and citations, and you contain the consequences with design: confidence thresholds that trigger human handover, scoping the assistant away from commitments it should not make, and logging every exchange so problems are found by you rather than reported by a customer.
Can you add a chatbot to software we already have?
Usually, yes. Most assistants are added to an existing product rather than built alongside a new one. What matters is whether your content exists in a form that can be retrieved — documentation, a knowledge base, structured records — and whether there is a sensible place in your interface to put it.
Which languages can it handle?
The major hosted models handle English strongly and have meaningful Sinhala and Tamil capability, though quality varies by task and should be tested against your actual content rather than assumed. We evaluate this explicitly during the test-set stage instead of discovering it after launch.
Tell us what you are trying to build
Describe the problem and we will come back with an approach, an honest assessment of the hard parts, and what we would need from you.
Get in touch