We Built a RAG Chatbot With No Vector Database, On Purpose

By Konstantinos Karamatzianis · Co-Founder, Dabster Labs

Published 7 July 2026 · Client engagement · Centre 8 Education

Ask anyone how you build a RAG chatbot in 2026 and you’ll get the same recipe: crawl the data, chunk it, embed it into a vector store, run similarity search at query time. We built Centre 8 Education’s bilingual sales assistant, “Lampsi”, and used no vector database at all. That wasn’t an oversight. It was the whole design.

Why the standard playbook is wrong here

Embeddings are genuinely the right tool for static prose, a forty-page policy document, a library of archived articles, anything that sits still. They are the wrong tool for structured operational data that changes every day, which is exactly what a live CRM is.

Here’s the problem in one sentence: a course date added at 3pm isn’t searchable in a vector store until the next re-indexing run. In a working training company, that lag is the product. A sales assistant that confidently quotes last week’s schedule isn’t helping anyone. So the question we started from wasn’t “how do we embed this data,” it was “why are we embedding data that’s going to be stale by design?”

What we built instead: retrieval as a live REST call

The model never sees an embedding. It sees four narrow tools that hit the live CRM and return structured JSON, and the “retrieval” is simply a REST call, fresh within milliseconds of the CRM being written to. One tool lists everything coming up. One searches courses by topic word, AML, MiCA, DORA, and so on. One pulls deep detail on a single course. And one fetches narrative content from the public website, allow-listed, and never trusted for dates or prices.

That’s the entire retrieval index. There is no other one. The system prompt is absolute on the point that matters most: answers about dates, prices, or availability never come from the model’s memory. If the agent hasn’t called a tool this turn, it is not allowed to quote a date, and a deterministic check after the model runs is the backup net if it ever tries.

The detail that proves this is real production data

Anyone can make a clean demo work. Real CRM data is partially tagged, because a salesperson adds a new course at the end of a busy day and forgets to apply the topic category. A tag-only search silently misses those courses, and silent misses are the worst kind, because nobody sees them.

So the topic search does two things at once. It matches the topic word to a CRM category and returns the courses filed under it, tagging each result as matched by category. And, separately, it scans every upcoming course title for the keyword as plain text, tagging those as matched by title. The payoff is one almost nobody designs for on purpose: because every result is labelled with how it was found, the sales team can audit their own tag coverage just by watching the ratio in the chat transcripts. As their tagging improves, the fuzzy title-scan fades out on its own. Clean signal first, fuzzy fallback second, that’s what lets retrieval-over-a-CRM survive the imperfect data every real business actually has.

The choices that separate a practitioner from a demo

A few decisions here are the difference between something that demos well and something that runs in production. We used a small, cheap model on purpose, the deterministic safety nets compensate for the occasional paraphrase, so there’s no need to pay for a frontier model just to read a row of JSON. We gave it four narrow tools rather than one broad “ask anything” tool, because small models get lost in a single catch-all and choose reliably from a short menu of non-overlapping options.

Bilingual support was the surprising one. The model routinely ignored a “reply in the visitor’s language” instruction when it was buried in the system prompt. So we detect Greek directly and inject a hard language directive into the user’s turn itself, and inline directives get obeyed where system-level rules get quietly skipped. Language compliance went from roughly seven-in-ten to about ninety-nine-in-a-hundred. And the lead scoring is fully explainable: eight signals, seniority, corporate intent, regulatory topic, funding mention, urgency, email quality, phone, engagement depth, combine into a score and a tier, with every signal written into the ticket by name, so sales sees why a lead is hot, not just that it is.

Built to satisfy the EU AI Act, by construction

Article 50 becomes binding on 2 August 2026, and Lampsi handles it in the widget rather than as an afterthought: a persistent badge stating it’s an AI, a one-click “talk to a human” that raises a high-priority ticket, and a notice that course recommendations are informational and that Centre 8’s staff make every admission and funding decision. That last line isn’t decoration, it’s precisely what keeps the system out of the AI Act’s high-risk category, because the AI informs and humans decide.

When we’d reach for a vector database anyway

An honest boundary, because no pattern is universal: this approach creaks the moment the target is long-form prose, or the question is genuinely unstructured, “tell me about your philosophy of learning.” For Centre 8 that case is rare, since the operational data is all structured, and the one narrative exception is handled by that allow-listed webpage fetch. That’s the only place in the whole system that looks like traditional RAG.

The takeaway

Vector search isn’t wrong. It’s just not the only kind of RAG, and it’s been so thoroughly cemented as “the way” that people reach for it reflexively, even for data it’s actively bad at. For structured, daily-changing data, tool-use retrieval, the model querying a live system through narrow tools, beats it on freshness, on cost, and on how well it survives messy real-world data. The right question isn’t “which vector database,” it’s “does this data even want to be embedded?”

What are you embedding right now that would work better as a live query? Book a free discovery call and we’ll take a look at your setup.