Grounded in your documents and data, citing the source it answered from, scoped to the topics you choose, and handing over to a human with the full conversation attached. Deployed to your own infrastructure with your own model keys.
The assistant is grounded in your documents, help centre, product data and policies through retrieval — so answers reflect how your business actually works rather than what a general model assumes. Every answer can cite the source it came from, which is what makes it checkable.
The failure that costs you customers is not silence, it is a confident wrong answer. Retrieval confidence thresholds, scoped topics and explicit refusal behaviour are configured deliberately, and anything below the bar escalates rather than improvises.
Escalation is designed in from the start — with the full conversation handed over, not a "please repeat your issue". Most support automation fails on this handoff rather than on the answers, so it is scoped as a first-class feature.
Deflect the repetitive questions that fill your inbox, and escalate the rest with full context attached.
Answer specification, pricing-model and availability questions at the moment someone is deciding.
HR policies, IT procedures and onboarding, answered from your handbook instead of interrupting someone.
A search box that answers in sentences and cites the page, rather than returning twenty results.
Qualify visitors, route them to the right page or person, and capture the enquiry properly.
The same assistant on the channel your customers already use, with human handover intact.
These get briefed as the same project and are not. A chatbot answers questions. An agent is given a goal and a set of tools and goes and does the work — booking the appointment, issuing the refund, updating the record. The difference decides the scope, the risk, and the price, and conflating them is the single most common reason an AI project disappoints the person who paid for it.
You want a chatbot if…
The value is in someone getting a correct answer quickly, and a human still takes any action that follows.
You want an agent if…
The value is in the work being done without anyone touching it, and the answer is only a by-product.
Often the answer is both
An assistant that answers most questions and can take two or three well-guarded actions. That is a normal scope.
AI agent development covers the other side — tool design, guardrails, approval steps and what it costs to run.
Everything needed to run it without us.
Stated plainly, so nothing is a surprise later.
Want it to take actions as well as answer? That is entirely buildable — it just makes it an agent rather than a chatbot, with a different scope and different guardrails. Most projects end up as a blend, and we scope it around what you actually need rather than which word you started with.
You hold the model account directly, so usage is billed to you rather than marked up — and switching provider later is a configuration change, not a rebuild.
It can, and any supplier who tells you otherwise is either misinformed or hoping you are. Language models generate plausible text, and plausible is not the same as correct. What a well-built assistant does is make it rare and make it visible. Answers are grounded in retrieved passages from your own content rather than the model's general knowledge, so there is a real source behind them. Every answer can cite that source, which lets a user check it in one click. Topics are scoped, so questions outside the defined area get a refusal rather than a guess. And a confidence threshold routes weak retrievals to a human instead of a fluent invention. The realistic goal is an assistant that is right the large majority of the time and honest about the rest — not one that is never wrong.
It hands over, and the quality of that handover is what most people actually judge the system on. The assistant recognises when retrieval has returned nothing useful, when a question falls outside its scope, or when the user is frustrated or has asked twice — and escalates. What matters is that the conversation goes with it: your agent sees the full history, what the assistant already tried, and the account context, so the customer is not asked to start again. Escalation routes wherever your team already works, whether that is a helpdesk, a shared inbox or Slack. We treat this as a core feature rather than a fallback, because a bot that deflects well but hands over badly produces angrier customers than no bot at all.
For a lot of businesses it genuinely is not, and you should use those. If you need a support widget over a help centre, with billing and reporting included and no engineering involved, an off-the-shelf product will be live sooner and cost less. It is a good answer and we would rather say so than take the project. A custom build starts to make sense when the assistant needs to read data those tools cannot reach — a live database, an internal system, per-customer records; when the conversation must trigger something in your own systems; when data residency or model choice is a real constraint rather than a preference; or when per-seat pricing at your volume has passed the cost of building it. The deciding question is usually whether the answers live in documents or in your systems.
Whatever already documents how your business works: help centre articles, PDFs, policy documents, product data, past support tickets, or a website we can crawl. There is no minimum, but quality dominates quantity — a small, accurate, current set produces a noticeably better assistant than a large contradictory one, and the most common cause of bad answers is contradictory source material rather than the model. The unglamorous part of the project is usually deciding which of three conflicting documents is authoritative. Simple deployments over an existing knowledge base move quickly; ones needing live data from your systems take longer, since each connection is a real integration. The timeline is agreed in writing with the quote.
Less than people expect for the content, more than they expect for the edges. If the assistant reads from a knowledge base your team already maintains, updates flow through automatically and there is nothing extra to do — which is why we connect it to a living source rather than a one-time snapshot. What does deserve attention is the conversation log, particularly in the first weeks: it shows the questions you did not anticipate, the places retrieval is weak, and the topics worth scoping in or out. We hand over an evaluation set so a prompt or content change can be checked against known-good answers before it goes live, rather than discovered by a customer. Everything runs in your infrastructure with your model keys, so you can operate it entirely without us.
The engineering detail behind retrieval, prompts and guardrails is in LLM integration done right. For assistants that answer strictly from your own documents, see RAG and knowledge bases.