AI bot in Telegram: five requirements that fail
Briefs for bots with artificial intelligence are increasingly written with the help of artificial intelligence. From the outside such a document looks solid: sections, a database schema, a system prompt. Inside are requirements that cannot be met, or that contradict each other two pages later. Below are the five clauses that appear most often in such briefs, and what we offer instead.
Requirement 1: messages typed out character by character
The first clause reads: "messages are typed character by character, with a delay of 20 to 40 ms per character". Telegram has no mechanism that types text out letter by letter. There is a "typing" indicator, and there is editing an already sent message, but frequent edits run into platform limits. On top of that, this requirement usually sits next to another one: "the answer must arrive within five seconds". Typing out a 400-character answer character by character would take twelve seconds for the output alone, so the clause breaks itself.
The working replacement is livelier than the original. First the "typing" indicator appears, then the answer arrives in pieces as the model generates it. The person sees movement a second after their message instead of waiting in silence while the server thinks.
Requirement 2: RAG for conversation memory
The second clause asks to "implement RAG for conversation memory". Almost always the same paragraph describes something entirely different: keeping recent messages in a fast cache and compressing the history when it grows. That is not RAG, that is a context buffer, and it is built far more simply. Real RAG is needed when the bot answers from your knowledge base, meaning your policies, catalogue or documentation. For "remembers what we talked about yesterday" a vector database means extra weeks of work and an extra service in the infrastructure.
Requirement 3: free messages every day
The third clause states that "the user gets ten free messages a day". It sounds like marketing, but it is a cost line, because you pay for every message, not the user. A thousand people who bought nothing turn into a daily bill for model calls. It matters to work this out in advance and build that bill into the subscription price, otherwise your most active users end up being your least profitable.
Caching everything repeatable cuts the cost sharply. Daily forecasts, horoscopes and standard selections only need generating once for a group of users, with the personal part filled in from the profile on the bot's side. Instead of a thousand model calls every morning you get about ten, and the user notices no difference.
Requirement 4: taking payment through a payment provider and Telegram Stars
The fourth clause asks for "payment through a payment provider and Telegram Stars". These are two different routes with different consequences. Stars are the built-in way to sell subscriptions inside Telegram, they require nothing from the owner beyond deciding the prices, and they open access immediately after payment. However, when a user buys stars inside a mobile app, Apple and Google keep around 30 percent, and withdrawal is delayed. A card payment provider takes cards directly without that loss, but connecting one requires a registered business entity.
In practice we build both entry points into the code and launch on Stars. That way sales start on handover day rather than after the owner has finished dealing with a payment provider.
Requirement 5: a set of character animations
The fifth clause asks for "a set of character animations". Drawing and animation are an illustrator's work and should not land in a developer's estimate. Often they do not need paying for at all: if the character already lives in Telegram as stickers, the existing files are wired straight to the bot's events. It is worth commissioning one or two scenes that were missing, not the whole set from scratch.
Where the work actually is
Once all the impossible clauses are struck out, the real body of work remains, and it is not where people expect. Connecting a conversation with a model is quick. Time goes on everything around it: subscription state with renewal and expiry, limits and resetting them, how the bot behaves the moment an external service returns an error or goes silent, taking a payment and reliably opening access. Then, separately, moving all of it onto a server so that it survives a restart.
This is why a bot with AI, a subscription and payments takes 2 to 3 weeks, and the price is quoted by scope of work. If someone offers you the same thing for a fraction of that, it is worth asking what exactly is included. Ask what happens when the model errors, who cancels the subscription when it expires, how limits are reset and who pays for the AI calls. The difference between quotes almost always hides in those answers rather than in the ability to write code.