Home / Blog / How to give your AI assistant its own Telegram bot

How to Give Your AI Assistant Its Own Telegram Bot (Not a Phone Number)

Two things sound identical and are not. A Telegram phone number for your AI — a real SIM logged in as a real account — is the movie version. A Telegram bot for your AI — a small identity from BotFather, addressable by @username — is the version that actually works, is legal, and takes ten minutes to set up.

What people usually mean when they ask this

«Give my AI a Telegram number» rarely means a SIM card. It means let me talk to it in Telegram like a person. Same interface I already use for family and work. Same forwarding, same voice messages, same file drop. Just point that address at my assistant instead of a human.

Telegram gives you two doors for that. Only one of them is honest for a personal assistant.

The two doors, side by side

Door one — the userbot. Log a real Telegram account into an automation library (Telethon, MTProto, TDLib). It shows up in your app as an ordinary contact, sees the same message history you see, and can do anything a person can do. Powerful. Also: needs a real SIM to register, breaks Telegram's Terms of Service the moment it does anything obviously automated, gets flagged and locked when the pattern detector notices, and mixes your assistant's activity into the same folder as your private chats. This is the door you take if you are building surveillance tooling or you are OK with the account dying every few weeks. For a personal AI, it is the wrong door.

Door two — the bot. Open a chat with @BotFather, run /newbot, pick a display name and a username, receive a token. That token is a first-class Telegram identity of its own — not a person, a bot. Addressable by @your_bot_name. Works inside official contracts: bots cannot start conversations with strangers, cannot silently harvest history, cannot pretend to be a user. Boring, safe, and exactly what a personal assistant needs.

The rest of this piece is door two.

The ten-minute setup

  1. Talk to BotFather. Open @BotFather. Send /newbot. Pick a display name (this is what people see in chat headers). Pick a username ending in bot — this is the permanent @handle. BotFather replies with a token that looks like 1234567890:AA....
  2. Store the token like a password. Drop it into your assistant's .env file on the server that will host the bot. Never in git, never in a screenshot, never pasted in another chat. If it leaks, run /revoke in BotFather and rotate.
  3. Start the process that speaks Telegram. Your assistant needs one running process that opens a long-poll or webhook against the token. One process. Two processes on the same token cancel each other out with 409 Conflict errors from the Telegram API — a classic outage on day one.
  4. Say hi. Message your bot from your own Telegram. It should reply. If it doesn't, the token is wrong, the process is dead, or something else already holds the token.
  5. Turn on the features you want. Back in BotFather: /setuserpic for an avatar, /setdescription for the profile blurb, /setabouttext for the short bio, /setcommands for the slash-command menu, /setprivacy if you plan to use the bot in groups and want it to see all messages instead of only mentions.

What «its own bot» actually gives your AI

What it does not give you (and why that's fine)

A bot cannot cold-DM strangers, cannot read chats it isn't in, cannot see messages sent before it joined a group. Those are Telegram's rules and they exist because the alternative is a spam wasteland. For a personal assistant these constraints are gifts: they mean the bot only ever hears from you, only ever speaks to you, and only ever sees what you deliberately show it.

A bot also has no phone number attached. That is the feature. No SIM to lose, no account to get banned, no «primary device» to keep alive. Just a token and the process running it.

Three common mistakes on day one

  1. Reusing one bot for many jobs. The first bot works so well that people try to bolt every new project onto the same token. Then the auto-transcriber, the trading alerts, the family chat helper, and the sales funnel all live under one name. Split them: one bot per purpose, one token per bot, one process per token. It costs nothing and it keeps the failure surfaces small.
  2. Committing the token. The token is the whole authentication. Anyone who has it becomes the bot. Keep it in .env (which is in your .gitignore) or a secret manager. If it ever appears in a commit, GitHub log, or shared screenshot — revoke and rotate in BotFather immediately.
  3. Running two copies of the bot. Two processes polling the same token race each other and both get 409 Conflict. Symptom: the bot answers your message, then a few seconds later answers it again, then goes silent. Fix: one process, one host. If you deploy a new version, stop the old one first.

Where this fits into a personal AI setup

The bot is the front door. Behind it sits the actual assistant: a model, some memory, a set of skills, a scheduler, and a bit of glue that turns each Telegram update into a real reply. You can build all of that from scratch — the token is standard, the API is documented, the SDKs are mature. Or you can install a system that already comes wired: on Avelina, the installer bot walks you through BotFather, takes your token, deploys the assistant to your own VPS, and hands you back a working chat within an evening. Same door, less glue.

Whichever route you take, the bot is not the assistant — it's the address the assistant answers at. Getting the address right on the first try is worth the ten minutes.

Related reading