Loading
A general chatbot that has never seen your price list, your policy manual or your order history can only guess. Retrieval-augmented generation is the unglamorous fix: find the right passage in your own material first, then let the model answer from it and show which passage it used. Novamind builds those assistants over the documents and systems you already have, in Arabic and English, and every answer carries a citation you can open.
Teams who answer the same questions from the same documents all day, and whose documents are too many, too long or too often revised for a person to hold in their head.
The strongest cases are internal before they are customer-facing. A support team searching a policy manual that changes quarterly. A sales team quoting from a price list with a hundred variants. An operations lead asking what the contract says about a delay penalty. A new joiner asking the question everybody else learned by asking a colleague.
The second group is customer-facing, but through a person: an agent who gets a drafted answer with the clause it came from, reads it, and sends it. That is slower than a bot replying alone and it is the right trade in any business where a wrong answer costs more than a slow one.
If what you want is a bot answering customers directly on WhatsApp or your website, that is our conversational AI service rather than this one, and the two are priced and scoped separately.
Four pieces. Most engagements need the first two; the third and fourth depend on where your material lives.
Your PDFs, policies, contracts, manuals and spreadsheets, split sensibly rather than every thousand characters, indexed so a question finds the passage that answers it. Arabic and English in the same index, since a Gulf business rarely has its material in only one. Permissions are enforced at retrieval, so a question cannot surface a document the person asking is not allowed to read.
Every answer shows the passages behind it, with a link to the source document and the section. That is the single most useful property of a retrieval system: the person reading can check it in a few seconds, which is what makes the output usable in a business rather than interesting in a demo.
Questions like what a customer ordered last quarter are answered from your systems rather than from a document. We build a defined read layer over the database, ERP or API, with the queries written and reviewed rather than generated loosely, and read-only access throughout.
A written set of real questions with the answers your experts agree are correct, run against the assistant on every change so a prompt or model update that makes things worse is caught before release. It transfers to you with the rest of the work, and it is what turns "it seems better" into something you can check.
Grounding an answer in your material reduces invention substantially. It does not eliminate it, and a vendor who tells you otherwise is selling you a problem.
Retrieval attacks the main cause of confident nonsense, which is a model answering from nothing. Given the right passage, the answer is usually right and always checkable. That is a real and large improvement.
Three failure modes survive, and we design around all three rather than denying them. Retrieval can fetch the wrong passage, which is why the citation is shown and why the evaluation set exists. The model can misread a passage it was given, which is why high-consequence answers go to a person before a customer. And your documents can contradict each other or be out of date, which retrieval will faithfully reproduce, so part of discovery is finding out which of your material is actually authoritative.
We will not quote you an accuracy percentage. We have not measured one on your data, and a number from someone else’s benchmark tells you nothing about your contracts. What we will do is build the evaluation set with your experts and show you the real figure on your own questions before go-live.
We do not build agents that take consequential action on their own. That is a position, not a limitation we are working around.
Our own products are built this way and it is not an accident. In Ignis the AI drafts a caption or a reply and a person always sends it. Where an assistant reads business data, it reads: it does not post a journal entry or change an order.
An assistant that drafts, suggests, retrieves and ranks makes a team faster with a failure mode that costs a few seconds of review. An agent that acts has a failure mode that costs a customer. In a small business with no second line of defence, the first is worth building and the second is worth refusing.
Where a workflow genuinely should run unattended, we build it as ordinary automation with defined rules, logging and alerts, which is the thing people usually mean when they ask for an agent and is considerably more reliable than a model deciding.
Answered before you ask, because for most GCC businesses this is the question that decides the project.
The documents you index and the questions people ask are processed by a model provider. Which provider, which region, and what they retain are decisions made in discovery and written into the agreement rather than left to a default.
We can build against a provider with no-retention terms, and where the material cannot leave your infrastructure at all, against an open-weight model you host. That second option costs more and usually answers slightly less well, and it is the correct choice for some documents.
The per-country data protection rules for Kuwait, the UAE, Oman, Saudi Arabia, Qatar and Bahrain are set out on our conversational AI page with sources, and the same rules govern this work.
The honest list, including the thing most AI pages leave out: we have not shipped one of these for a client yet.
A published case study. We run large language model features in our own products in production, and we have not yet published a retrieval project for a client. That is the state of it today.
An accuracy guarantee or a quoted accuracy percentage. We build the evaluation set with your experts and show you the measured figure on your own questions instead.
Agents that take consequential action without review. We build drafting, retrieval and ranking, and ordinary rule-based automation where something must run unattended.
Training or fine-tuning a model on your data as the default approach. Retrieval solves most of what people ask fine-tuning for, at a fraction of the cost and without baking last quarter into the weights.
Voice, telephony or IVR.
A promise about which model you will be running in a year. The field moves; the retrieval layer, the evaluation set and the citations are the parts built to outlast any particular model.
No client retrieval case study yet, so here is the production language model work we can actually point at.
Ignis, our own social media platform, runs large language model features in production: it drafts captions and replies, picks a model per feature server side rather than exposing that choice to the client, bands those models by cost, and meters usage against a credit balance with idempotent debiting. That is the unglamorous engineering a production AI feature needs, and it is live.
Our conversational AI service covers Arabic and English chatbots on WhatsApp, web and in-app, with the per-country data protection position documented and sourced. That page is equally frank that no chatbot case study is published yet.
If a published client case study is what you need before committing, say so and we will tell you honestly where we are rather than describing a project in the abstract.
The questions we hear before a ai agents and rag project starts.