Home / Product development / AI assistant development
Your team looks for answers in a help centre, a contract archive and two business systems, and a chatbot trial answered well only on the questions it was shown. We build assistants that answer from your documents and live systems, show the source, respect each user’s access, and draft the reply or the next step for a person to approve. Coding agents help write the retrieval and the tests; senior engineers decide what each user may see.
A support agent checks the help centre, the order system and an old ticket before replying. An analyst reads a whole lease to find one clause. A new joiner asks the same questions every new joiner asks. An assistant that searches your sources under each user’s access answers with the source attached, says when it does not know, and leaves the decision with the person asking.
Support agents, analysts and the owners of each source often expect different answers to the same question. These six conversations settle what the assistant answers, from where, and for whom.
Who asks, what they ask today, where they look for the answer now, and what a good answer lets them do next, collected as real questions rather than imagined ones.
Which documents, databases and systems hold the answers, how current each one is and who owns it, so an outdated policy is retired at the source, not patched in a prompt.
Whether the assistant searches as the user, under the access they already have in each system, and which sources stay out entirely, such as HR files or board papers.
When it answers, when it shows the passage it relied on, when it says it does not know, and when it passes the question to a named person or team.
What it may draft, such as a support reply or a call summary for the CRM, and the rule that a person reviews and sends every draft. The assistant sends nothing itself.
The measure the assistant is built to change, such as time to first reply or questions escalated to specialists, agreed before the build and checked again after launch.
On an assistant, coding agents take the volume: document parsers, indexing jobs, chat screens and tests. Senior engineers decide which sources it reads, under whose access, and what it says when no source covers a question, because a mistake there shows an employee a salary file or gives a customer a confident wrong answer.
AI-native product developmentBecause agents draft the indexing code quickly, several ways of splitting and searching your documents are compared on questions your users actually ask, and the one that finds the right passage stays.
A working assistant reaches a small group of users early, so the questions it gets wrong come from them rather than from a guess, and each wrong answer becomes a test case.
Senior engineers write the rule that each search runs under the asking user’s own access, so the assistant cannot quote a document that person could not open themselves.
Real questions with expected answers, written with your experts, are rerun on every prompt, model or source change, and a senior engineer reads each answer that changed.
What must never be sent to a model provider, such as personal data or board papers, is listed in discovery and kept out in code a senior engineer reviews, not by a line in a prompt.
Six situations, from an idea with no prototype to an assistant whose bill keeps growing.
We start with your users’ real questions and check that your sources can answer them, then build a narrow first version for one team. If the data cannot answer the questions, you hear that before the build.
The answers exist in articles and old tickets, but customers and agents ask anyway. The assistant answers from those articles with a link to each, and the questions it cannot answer show which article is missing.
A copilot bought with one tool answers only from that tool’s data, while the answer needs the contract, the order and the ticket. We build one assistant over all three, under each user’s existing access.
We score the prototype on a set of real questions and rebuild the parts that fail, usually retrieval, access checks and the reply when no source covers the question. Keeping what works is often cheaper than starting again.
Your customers ask questions about their own data. We add the assistant as a feature of your product, on its sign-in, its data and its release process, and limit every answer to that customer’s records.
Usage grows and so does the model bill. We measure cost and response time per conversation, cache repeated questions, send simple ones to a smaller model and trim what retrieval passes on, and report the cost before and after.
Five stages, ordered so a pilot team asks real questions of real sources before anyone else is asked to switch.
Real questions are collected from the people who ask them and paired with the answers your experts expect, and the answer screen is drawn where users already work.
Figma, evaluation setSources are parsed and indexed, and model calls and access checks are built in sprints. Every sprint ends with the evaluation set rerun on a working build.
Python or Node.js, LLM APIs, vector searchOne team uses the assistant on live questions and rates each answer. Wrong answers become test cases, and missing sources go on the fix list before launch.
Answer ratings, evaluation setLoad, cost and failure tests, a security review and the hand-off to a person are in place before the assistant opens to everyone who will use it.
Load tests, security reviewRatings, unanswered questions and cost per conversation decide what changes next: a new source, a better prompt or another model, each checked on the evaluation set first.
Evaluation reruns, cost reportsSix parts, built around the person asking, because every search, access check and answer is made on their behalf.
In a chat panel, a search box or a form field
As that user, not through one shared account
Your documents and live systems, under that access
From the passages found, with each source attached
It says it does not know and offers a person
Uses the answer, edits the draft or sends it on
Ratings and unanswered questions feed the evaluation set
Parsing and OCR for scanned files, chunking and embeddings, and vector plus keyword search, with a framework such as LlamaIndex only where it removes code we would otherwise write.
Order, ticket and account data read from your CRM, ERP and helpdesk through their APIs at the moment of the question, so the assistant never answers from yesterday’s copy.
Every search runs under the asking user’s access in each source, questions and answers are logged, and model-provider terms are checked for data retention before anything is sent.
GPT, Gemini, Claude or an open-source model such as LLaMA, chosen per task on accuracy, speed, privacy and cost, and kept behind one interface so it can be swapped.
An evaluation set of real questions rerun on each prompt, model or source change, user ratings on every answer, and cost and response time tracked per conversation.
Next.js or React screens, Python (FastAPI) or Node.js services, and your existing database or Supabase, hosted in a cloud account your company controls.
Hire a DevOps engineerA commercial real estate platform with chat over its documents, a sales-call analysis system, and a radiology platform with a chatbot in the doctor’s workflow. Only the first is an assistant in full.
AI and data platformElysium
We took over development and owned the front end, back end, AI pipeline and CI/CD. We added chat history on GPT and Gemini, chat ratings and self-service document upload, and migrated the AI pipeline from OpenAI to Gemini.
Read the Elysium case studyIt depends on how many sources it reads, how strict the access rules are, and whether it drafts replies as well as answering. Start from what the questions cost now: the hours specialists spend answering colleagues and the tickets that wait for them. After discovery you get a written figure for the build and an estimate of the monthly running cost, model calls included, as a separate line.
Use the copilot if your questions are answered from the one tool it sits in. It costs less, and we would rather say so than build. A custom assistant pays off when an answer needs several sources at once, such as a contract, an order and a ticket, or when it has to sit inside your own product for your customers.
By measuring them before launch. Your experts write real questions with the answers they expect, including questions the assistant should decline, and every build is scored on that set. After launch, user ratings and unanswered questions add new cases, and a person reads every answer that changes after a prompt, source or model update.
Not if it searches as them. Every search runs under the asking user’s access in each source, so a person who cannot open a file in your document store cannot have it quoted either. Sources that must never reach a model, such as HR files, are excluded in code. Drafts go to a person to send; the assistant sends nothing itself.
The one that answers your questions best for the money. GPT, Gemini, Claude and open-source models are compared on your evaluation set, and the choice sits behind one interface, so switching later is a change plus a rerun, not a rebuild. Running cost is reported per conversation, repeated questions are cached, and simple ones go to a smaller model.
One team’s questions, from the sources that answer them, with each source shown, a rating on every answer and a hand-off to a person. Drafts saved into other systems, a second group of users, more languages and admin screens wait, because none of them shows whether people use the assistant.
Yes, through their APIs at the moment of the question and under each user’s own access in that system. Read access comes first. Writing back, such as saving a call summary to the CRM, is added as a draft the user confirms, because software that changes records on its own is an agent and needs the approvals that come with one.
The assistant, its search index and its logs run in your cloud account, and which model provider sees which data, on what retention terms, is agreed before anything is sent. An open-source model inside your own infrastructure is an option. IP assignment is part of the contract, so the code, prompts and evaluation set are yours from the first commit.
Your source owners keep documents current, because the assistant is only as right as the files it reads. The named engineer who signed off the launch stays on it: reading low-rated answers, adding sources, adjusting prompts as questions change and rerunning the evaluation when a provider updates its models. Larger additions are scoped and quoted first.
Agents that take the next step themselves, a Claude developer inside your team, and a CRM whose records an assistant can rely on.
Send ten questions your team asked last week and where the answers live, or the prototype you have and the questions it gets wrong.
In the first call we look at who asks, what they ask and which sources answer it. If a simpler automation or a search tool would do the job, we will say so.
We sign an NDA before discussing your data in detail. We reply within 24 hours.
