Every organisation runs on knowledge. Sales needs product detail on demand, support needs the troubleshooting step that actually works, and analysts need to connect ideas across thousands of documents without losing a day to search. Studies put the time knowledge workers spend just looking for information at 20 to 30 percent of the week. In a company with 200 of them, that is tens of thousands of hours a year that never turn into work.
An AI knowledge assistant closes that gap: large language models plus your own data, answering in plain language, so people ask a question instead of guessing where to look. But in our experience, the tool is the easy part. What separates an assistant people trust from one they quietly abandon is not the model name on the box. It is retrieval quality, how the answers are evaluated, how the system connects to the rest of your stack, and how the underlying knowledge is governed. Those are engineering decisions, and they are made by people. This article is about the people we put on them.
What actually breaks in a knowledge assistant, and why is it a people problem?
Most assistants that disappoint do not disappoint because the model is weak. They disappoint because the retrieval returns the wrong passage, the answer sounds confident while being wrong, the integration goes stale, or the source knowledge was never clean to begin with. A strong model on top of a weak retrieval layer produces fluent nonsense, which is worse than no answer at all.
We have found that every one of those failure modes traces back to a decision an engineer either made well or did not make at all. Which is why we do not talk about our assistants in terms of a platform. We talk about the competence of the team that stands them up and keeps them honest.
What competence do LLM and RAG engineers bring?
When we put a team on a knowledge assistant, this is the judgment we are actually selling.
Retrieval that finds the right thing. Keyword search falls apart the moment a question is worded differently from the source. Our engineers design the semantic retrieval layer, choosing how documents are chunked, embedded, and ranked, so the assistant returns relevant material even across different wording, languages, or half-formed questions. Getting retrieval right is most of the battle, and it is where seniority shows.
Answer-quality evaluation. A demo looks good on ten questions. Production means thousands, and someone has to know whether the answers are actually right. We build the evaluation harness: measuring retrieval precision, grounding answers in cited sources, and catching the confident-but-wrong responses before your users do. In our projects this is the discipline that turns a novelty into a system people rely on.
Integration and freshness. An assistant that stands alone goes stale and stops being used. Our engineers connect it to the systems your work already lives in, document platforms, CRMs, ticketing, project tools, so that when a source updates, the assistant’s knowledge updates with it. Context awareness and role-based answers get built here too: a sales rep and a pricing analyst asking the same question should not get the same level of detail.
Data governance and residency. For clients in regulated industries this is not optional. Our people handle access control, data residency, and the audit trail from the start, so the assistant respects who is allowed to see what and can prove it later.
How does our team run the engagement?
We do not hand over a step-by-step manual and wish you luck. We put a team inside the work and run it end to end.
It starts with a knowledge audit. Before anything is connected, our engineers catalogue what you have, where it lives, and how current it is, because feeding a model stale or contradictory content is the fastest way to get confident, wrong answers. From there we define the two or three use cases where faster, accurate retrieval has measurable impact, support deflection, onboarding, internal policy lookup, rather than trying to automate everything at once.
Then we pilot with a real team, not just IT, and instrument it: time-to-answer, resolution rate, escalation frequency, answer-acceptance rate. That phase surfaces most of the integration and content gaps, and our engineers close them before anything scales. Only then do we scale, and we stay to keep the content fresh and the retrieval tuned, because an assistant is a system that needs ownership, not a one-time deployment.
The roles we typically bring to this: a senior LLM/RAG engineer who owns retrieval and evaluation, a data engineer for the integration and governance layer, and a technical lead who keeps the architecture coherent and the answers grounded. Small, senior, accountable.
The proof: UNIQA
We do not ask you to take this on trust. We built and deployed a working knowledge assistant for UNIQA, a regulated insurer where retrieval accuracy, access control, and data residency were entry conditions, not nice-to-haves. That project is not a product we are reselling to you. It is evidence of what our engineers can do with retrieval, evaluation, integration, and governance under real constraints.
Where does the assistant help, and where do your people still decide?
We are clear-eyed about what these systems are for. An AI knowledge assistant is excellent at high-volume, well-defined retrieval: answering the same support question consistently, delivering onboarding information, pulling a specification out of a 300-page manual faster and more reliably than any human. Traditional search returns a ranked list and leaves you to do the work; the assistant interprets intent, synthesises across sources, and gives an answer you can follow up on.
What it does not do is replace judgment. Deep expertise, novel problems, high-stakes and ethical calls stay with your people. In our view the assistant is an amplifier: it clears the repetitive lookup off your experts’ plate so their time and judgment go where they actually matter. Humans decide, the assistant does the volume.
Bring in the people, not just the tool
The technology for knowledge assistants is ready. Success does not hinge on picking the right platform, it hinges on the engineers who make retrieval accurate, answers trustworthy, integrations durable, and governance airtight. That is what we provide: a small, senior team of LLM and RAG engineers you can plug straight into your organisation, proven on work like UNIQA.
Bring in a team of LLM/RAG engineers for your knowledge assistant, augmented by AI → Team augmentation