Bot type
An assistant that cites its source, or admits it has none
A retrieval-backed Telegram assistant answers questions from your own documents, quoting the passage it used, and declines when retrieval finds nothing relevant. The refusal behaviour is the product. It does not know anything outside what you give it, and it will not fix documentation nobody maintains.
AI assistants inside Telegram: price, timeline and limits
- Fixed price
- $9,600 USD
- Delivery
- 35 calendar days from kickoff
- Message length
- 4096 characters per Telegram message
- Inference latency
- Seconds, not milliseconds
- Re-embedding
- Required whenever the embedding model changes
- Grounding
- No decoding constraint guarantees an answer stays inside its context
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Almost every organisation has a body of knowledge that exists and is unread: a policy manual, a product specification, four years of support tickets, an operations handbook. The information is there. The cost of extracting an answer from it exceeds the cost of asking a colleague, so people ask the colleague, and the colleague becomes the index.
Retrieval-augmented generation addresses exactly this and is widely oversold. What it does well is find the relevant passage in a corpus and put it into readable language with a citation. What it does badly, unless the build takes it seriously, is decline. An assistant that answers confidently when retrieval returned nothing useful is not a slightly worse assistant — it is actively harmful, because it produces plausible answers to questions your documentation does not cover, and the reader has no way to tell those apart from the good ones.
So the engineering effort concentrates somewhere unglamorous. Chunking documents so a retrieved passage is self-contained. Scoring retrieval so a weak match is recognised as weak. Constraining generation so an answer cannot exceed its sources. And making "I do not have that, here is who does" a first-class outcome rather than a fallback. Teams that skip this ship a demo that impresses in a meeting and loses trust in its third week.
How the build runs
Documents are ingested and chunked deliberately
Chunk boundaries follow the document's own structure — clause, section, ticket — rather than a fixed token count. A passage split mid-argument retrieves as nonsense however good the embedding model is.
webhookA question retrieves candidate passages and scores them
Retrieval returns passages with similarity scores. Below a threshold set during evaluation, the assistant does not attempt an answer. This single threshold does more for trustworthiness than any model choice.
commandsGeneration is constrained to the retrieved material
The model is instructed to answer only from the passages supplied and to say when they are insufficient. This is not a guarantee, which is why the citation is always shown rather than being an optional extra.
commandsThe answer arrives with its source attached
Document, section, and the passage itself. A reader who doubts the answer can check it in one tap, and over time that ability is what makes people trust the answers they do not check.
inline-keyboardRefusal routes to a person rather than ending the conversation
Not "I cannot help with that" but a handover to a human with the question attached. A dead end teaches people to stop asking, which removes the assistant's usefulness faster than a wrong answer does.
forum-topicsBad answers become corpus corrections
Every answer can be flagged in one tap, and flags group by document. The output is a short list of passages that are wrong, missing or ambiguous — which is a documentation backlog, and is usually the most valuable artefact the project produces.
inline-keyboard
What Telegram will and will not let you do
A Telegram message is limited to 4096 characters.
A long answer with citations has to be split or summarised. Splitting mid-citation makes the source unverifiable, so answers are budgeted against this limit at generation time rather than truncated afterwards.
Retrieval quality is bounded by chunking, and chunking is bounded by document structure.
A corpus of scanned PDFs with no headings retrieves badly regardless of model. Assessing the corpus is the first step of the project, and sometimes the honest conclusion is that it needs work before any assistant is worth building.
Language model inference adds latency measured in seconds, not milliseconds.
The bot sends a typing indicator and streams where it can, but an answer takes noticeably longer than a lookup. For questions with a deterministic answer, a lookup is the better tool and is used instead.
Embedding a document set has a one-off cost proportional to its size, and re-embedding is required when the model changes.
Model upgrades are not free. The pipeline is built so re-embedding is a scheduled job rather than a rebuild, but the cost is real and belongs in the year-one budget.
Nothing constrains a language model to its context with certainty.
Citation display is a safeguard, not a proof. Any use where a wrong answer carries legal or clinical consequence needs a human in the loop, and the build says so rather than implying otherwise.
When not to build this
- Your documentation is out of date and nobody owns it. The assistant will retrieve the wrong answer faster and with more authority than a person would have.
- The questions have deterministic answers a database could serve. Retrieval and generation add latency, cost and uncertainty to something a lookup answers exactly.
- A wrong answer carries clinical, legal or financial consequence and there is no human review step. The citation makes checking possible; it does not make it automatic.
- You want it to replace a support team rather than to make one faster. The escalation path is load-bearing, and a build with nobody behind it fails at exactly the questions that mattered.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with streaming answer delivery and citation buttons. |
| Cloudflare Workers AI | current | Embedding and inference at the edge, keeping the corpus in your account. |
| Cloudflare Vectorize | current | Vector index for retrieval, with score thresholds enforced in query. |
| Cloudflare D1 | current | Document metadata, conversation logs and answer feedback. |
| TypeScript | 5.9 | Strict mode, with retrieval results typed so an unscored passage cannot reach generation. |
Questions people ask before committing
What does it do when it does not know?
It says so and hands the question to a person, with the question attached. That path is designed first, not last, because an assistant that answers confidently from nothing destroys trust in every answer it gives, including the correct ones.
How do we know an answer is actually from our documents?
Every answer shows the passage it used and where it came from, checkable in one tap. That is a safeguard rather than a proof — no technique constrains a language model to its context with certainty — which is exactly why the citation is always visible.
Does our documentation need to be good first?
It needs to be current and structured enough to chunk. Assessing that is the first step of the project, and where the corpus is genuinely poor the honest recommendation is to fix the documentation before building anything on top of it.
Where does our data go?
Embedding and inference run in your Cloudflare account rather than being sent to a third-party model provider. For organisations with data residency obligations that is usually the deciding factor, and it is worth confirming against your specific requirements at scoping.
How is it kept current as documents change?
Re-ingestion runs on a schedule or on a change webhook where your source system supports one. A stale index is the most common way these systems quietly degrade, so freshness is monitored rather than assumed.
Can it work in Arabic?
Yes, with the caveat that retrieval quality on Arabic technical documentation is more variable than on English. It is worth evaluating against your own corpus during scoping rather than trusting a general benchmark.
What does the feedback loop actually produce?
A ranked list of passages that generated flagged answers. It is the most useful by-product of the project — a specific, evidence-backed documentation backlog, rather than a general sense that the handbook could be better.