How to build an AI assistant bot on Telegram
By the Botable team
A Telegram AI assistant bot answers questions in a chat, keeping enough conversation history to follow up. Describe its subject, its tone, and what it should refuse, and Botable builds and hosts it with those boundaries in place.
What is a ai assistant bot?
An AI assistant bot on Telegram is a conversational endpoint with three things a raw model call does not have: memory, boundaries, and cost control. Memory means keeping the last several turns so "and the second one?" resolves to something; storing the whole history forever is both expensive and worse, because stale context drags answers off-topic. Boundaries mean a defined subject and an explicit refusal behaviour — an assistant that will answer anything is impossible to trust in a support or product context. Cost control means a per-user rate limit and a cap on reply length, because an unbounded assistant in a busy group is an unbounded bill. The most useful variant is not a general chatbot but a narrow one: an assistant that only answers questions about your product, your documentation, or your data, and says so plainly when a question falls outside that.
What commands does it have?
| Command | What it does |
|---|---|
/ask <question> | Answers using the assistant's subject knowledge |
/reset | Clears the conversation memory |
/mode | Switches between concise and detailed replies |
/history | Shows what the assistant currently remembers |
/limit | Tells the user their remaining quota |
What do you need before you start?
- A Telegram bot token from @BotFather
- A subject and a tone — the narrower, the more useful
- A refusal rule for anything outside the subject
How do you build it?
How much conversation should the assistant remember?
The last handful of turns, not everything. Say the window when you describe the bot. Long memory sounds better and behaves worse: old context pulls answers off-topic and every extra turn costs more to process.
How do you keep the assistant on topic?
Define the subject and state the refusal explicitly — "if a question is not about X, say so and point to the help link". An assistant with no boundary drifts, and a drifting assistant in a support channel gives answers you will have to retract.
How do you stop it becoming expensive?
Rate-limit per user, cap reply length, and keep the memory window short. Ask for all three when you describe the bot; they are far easier to set at build time than to retrofit after a busy week.
Can it answer from your own documents?
It can fetch from any endpoint you name, so a public docs URL or an internal API can be the source. Grounding answers in your own content is what turns a generic chatbot into something worth deploying.
A prompt you can use as-is
Paste this into Botable and adjust the details. It is specific on purpose — a vague description produces a vague bot.
Build an AI assistant bot for questions about my product. /ask answers in a friendly, concise tone, remembering the last 6 turns of conversation per user. If a question is not about the product, say so in one line and link to my support chat instead of guessing. Cap replies at about 120 words, limit each user to 20 questions an hour and tell them their remaining quota with /limit. /reset clears the memory.
Who is this bot for?
- Product teams putting a documentation assistant where users already are
- Communities that want a knowledgeable bot rather than a generic one
- Anyone replacing a repetitive human answer with a consistent one
What goes wrong with this kind of bot?
- Unbounded memory degrades answers and inflates cost — cap the window
- An assistant with no refusal rule will confidently answer things it should not
- Rate-limit before launch, not after the first group with a thousand members finds it
Questions about ai assistant bots
Does it work in group chats?
Yes, and in a group it should only respond when mentioned or replied to. An assistant that answers every message in a busy group is unusable; say this when you describe the bot.
Can it hand over to a human?
Yes — that is usually the right ending for a question it cannot answer. Combine it with the support flow so the conversation escalates rather than dead-ends.