AI assistants
An assistant that answers from your documents
These are retrieval-backed assistants: the question is matched against your own indexed documents, and the model answers from what it retrieved, with a reference to the source. That constraint is the product. An assistant that answers from general knowledge is a liability in a business where the answer has to be your answer.
Retrieval-backed assistant builds: what this section covers
- Answer source
- Your indexed documents, with a reference returned alongside
- Largest cost line
- Corpus preparation, not the model
- Latency
- Seconds, not milliseconds — inference dominates
- Re-embedding
- Required whenever the embedding model changes
- Message ceiling
- 4096 characters per Telegram message
- Grounding guarantee
- None absolute. Retrieval constrains the answer; it does not prove it
As of 2025-10-01, Telegram Bot API 13.4
Why this tier is priced apart
The premium tier of this catalogue, and the one with the shortest path from a problem everyone recognises — documentation nobody reads, the same twelve questions arriving daily — to something measurable. It is also the tier where the gap between a demonstration and a production system is widest, which is why these pages spend more time on failure modes than on capability.
The architecture is unglamorous and it is where the cost sits. Documents are chunked, embedded and indexed; a question is embedded and matched; the retrieved passages are handed to a model with an instruction to answer from them and to say so when they do not contain an answer. The interesting engineering is almost entirely in the first step, because retrieval quality is bounded by chunking and chunking is bounded by how your documents are structured.
What Telegram adds is the absence of an adoption problem. A knowledge base behind a login gets used by the people who remember it exists; an assistant in a chat your staff already have open gets used by everyone. That is the entire reason this tier is worth more inside Telegram than as a web widget.
What gets built
The two builds in this catalogue where a language model is doing the work, and the multilingual case where it is doing a narrower job than people expect.
The full specification, including what happens when retrieval returns nothing useful, is
Where the languages matter more than the reasoning, the better fit is
For a conversation that needs to be predictable rather than clever, see
Where the answers come from
Where a corpus actually lives. The integration decides how much of the budget goes on preparation rather than on retrieval, and the differences are larger than they look.
For teams whose knowledge already lives in a block structure that chunks cleanly, see
Where the corpus is a wiki with macros that render as placeholders, read
For the tenant and conditional-access questions that decide the timeline, see
For a corpus of documents in shared drives, with the ownership traps that come with it, read
Where retrieval is the wrong answer
The comparison that talks a meaningful share of readers out of this tier, and the constraints that decide it.
The argument for spending far less, and the certainty you buy by doing so, is in
If the requirement is really agent tooling rather than answers, read
What it costs to run
What it costs to build and what it costs per month afterwards — the second being the number that surprises people.
The effort breakdown, with corpus preparation as the largest line, is in
For re-embedding, content drift and the monthly cost of keeping answers current, see
What people ask before funding a retrieval project
Can you guarantee it will not make something up?
No, and any vendor who guarantees it is describing something other than a language model. Retrieval narrows the input and a citation makes an unsupported answer visible, which together move the failure rate a long way. They do not move it to zero. Where a wrong answer is genuinely unacceptable, a scripted bot that can only say what it was told to say is the better engineering decision, and the comparison page argues that case properly.
How good do our documents have to be?
Better than most teams expect, and this is where budgets go. Retrieval quality is bounded by chunking, and chunking is bounded by document structure: a well-headed knowledge base chunks cleanly, while a folder of scanned PDFs and a decade of email threads does not. The audit that establishes which of those you have happens before anything is quoted.
What does it cost per month to run?
Three things that are not the build: model usage, which scales with questions asked; hosting, which is small; and content upkeep, which is the one people forget. An assistant answering from documentation that stopped being true six months ago is worse than no assistant, because it is confidently wrong at scale.
Does the Arabic caveat change what we should budget for?
Yes, with a caveat worth stating before you budget: machine translation and model quality for Gulf Arabic dialect are materially worse than for Modern Standard Arabic. If your customers write the way they speak, that gap is the risk in the project, and it is better handled by a reviewed answer set in the languages that matter than by trusting the model to bridge it.
Who processes the question, and under what data terms?
Documents are embedded and stored in an index you own, under your own accounts. Which model provider processes a question, and under what data terms, is a decision made at scoping rather than a default — for a regulated firm it is frequently the decision that shapes the whole architecture.
Why inside Telegram rather than a web widget?
Because a knowledge base behind a login is used by the people who remember it exists, and an assistant in a chat your staff already have open is used by everyone. The retrieval architecture is identical; the adoption difference is the entire value.
Related reading
For the other twenty-three builds, with exact figures and delivery windows, see the full catalogue.
Where an answer needs an interface rather than a paragraph, the other in-chat surface is Telegram Mini Apps.
Every knowledge source above has its auth model, quota and failure modes documented in the integration pages.
For the message length and formatting limits an assistant answer has to fit inside, read the Bot API reference.