AI Support Agent: a Telegram bot that answers from your documents and knows when to fetch a human

Your support inbox is the same twenty questions over and over. What are your prices, does it work with X, how do I reset it, where is my order. Somewhere inside that pile are the messages that must reach a person - the refund, the billing dispute, the customer who has had enough.

A bot that answers all of it is dangerous. A bot that answers none of it is pointless. This one answers the twenty and hands the rest to you, with a note explaining what it already said.

It is an n8n workflow, it runs on Telegram, it answers only from documents you have given it, and it is free.

What it is

A support agent with two doors into it.

• A Telegram bot your customers message. It searches your knowledge base before it answers anything factual, replies in the language the customer wrote in, and emails a human when it should not be answering.
• A web form your client fills in themselves to add documents. Upload a price list, a refund policy, a troubleshooting guide - the bot can answer from it about a minute later. No developer, no redeploy.

Everything the bot says is written to a log table with the question, the answer and the execution ID, so a bad answer can be traced back to the document that caused it.

Answering is the easy half

Getting a language model to sound helpful takes an afternoon. The work is in the three places where a support bot usually fails.

It has to look things up, not remember

The knowledge base is a tool the agent is instructed to call before answering any factual question about products, pricing, policies or troubleshooting. Its documents live in Supabase with pgvector, and the top five matching chunks come back on every question.

The instruction that matters more than the retrieval is the one next to it: never invent facts, and if the knowledge base does not contain the answer, say so plainly and escalate. A model with a search tool will still answer from memory if you let it.

Escalating is not the same as replying

This is the detail that separates a handoff that works from one that looks like it works.

When the agent decides a human is needed it sends an email to your support inbox. That email does not reach the customer. So the system prompt is explicit that calling the tool does not reply to anyone, and the agent must still write its own message - telling the customer a person will follow up, and roughly when.

Get this wrong and your bot goes silent at exactly the moment the customer was already frustrated.

The email itself is written by the agent, and it is not a notification. It carries the customer name, their Telegram username, the chat ID, what they asked, what the bot had already told them, and why a human is needed. Your colleague opens it and knows where the conversation is, instead of starting from zero while the customer repeats themselves.

A handoff that makes the customer explain everything again is worse than no bot at all.

And then the bot gets out of the way. The chat is recorded in Supabase as belonging to a human, and the agent is not run again for that customer - everything they send next is emailed onward instead. A bot that carries on answering over the colleague you just called in has not handed anything over; it has sent a notification and kept the conversation. If nobody picks the chat up it returns to the bot after a day, so the customer is never left talking to nothing either.

Your colleague replies from their own Telegram account. This workflow tells them, marks the chat as theirs and steps aside - it does not give them a console to work the conversation from. That is a larger, separate build.

The rules for when it escalates are written into the prompt rather than left to judgement: the knowledge base has no answer, the customer asks for a human, the customer is angry or threatening to leave, or the subject is refunds, billing disputes, cancellations, legal or medical. Those last ones are not about whether the model could produce an answer. It could. It should not.

The reply has to survive the messenger

Telegram rejects malformed HTML with a 400 error, and a model that writes its own HTML will eventually produce something malformed - an unclosed tag, a stray angle bracket inside a quoted price.

So the model is never allowed to write HTML. It uses three markers and nothing else: asterisks for bold, a leading dash for a bullet, a blank line between sections. A code node then escapes every character the model produced, converts those three markers, collapses extra blank lines, and cuts the message on a line break if it exceeds Telegram's 4,096 character limit so a tag is never split in half.

The result is that a customer asking about a product called "Pro <Max>" gets an answer instead of silence.

Keeping what it knows current

Most knowledge base bots are accurate for six weeks. Then the price list changes, nobody updates the index because updating means asking the developer, and the bot starts confidently quoting last quarter.

So the upload path belongs to whoever owns the content. The form is password protected, takes a PDF, a .txt or a .md file, asks for a source name, a category and an email address for the confirmation. The text is extracted, split into chunks, embedded and indexed with its source and category attached as metadata.

The confirmation email tells the uploader what actually happened: the file name, the category, and how many characters were indexed. That character count is there on purpose - it is the fastest way to notice that a forty page PDF somehow contributed nine hundred characters.

Scans are rejected rather than indexed. If less than fifty characters come out of a file, it is almost certainly an image-only PDF with no text layer. The uploader gets an email saying run it through OCR and try again. Nothing reaches the index.

This is the quiet failure worth designing against. An empty document indexes perfectly happily. Nothing errors. The bot simply cannot answer questions about the policy you were sure you had uploaded, and it looks exactly like a bot that is working correctly.

What happens when something fails

Every external call in this workflow has a failure branch, and they all end somewhere a human can see.

• If the model, a tool or Telegram itself fails, the customer gets a short apology saying a colleague has been alerted - and the ops inbox gets an email with the execution ID, the chat ID, the customer name, the question and the error.
• If text extraction fails, the ops team is told the file was probably corrupt or password protected.
• If indexing fails, the alert says explicitly that the document was not added and the uploader has not been told it succeeded.
• If the customer sends a photo or a voice note, they get a polite nudge asking for text, not a crash.
• If the conversation log write fails, the customer still has their answer. Logging is never allowed to break a reply.

No silent drops. That is the whole rule, and it is the difference between a workflow that demos well and one still running in month six.

One node holds every email address

Both triggers pass through a single config node before anything else happens. It holds the sender address, the support inbox where customer escalations go, the ops inbox where failures go, and how many hours a handoff lasts before the chat returns to the bot.

Every email node downstream reads from it. Changing where escalations land is one edit in one place, not nine nodes and a missed one.

What you need

• An n8n instance, self-hosted or cloud
• A Telegram bot token
• An OpenAI API key - it runs on a small model
• A Supabase project: the pgvector schema, plus three small tables - the conversation log, the ingestion log and the handoff state
• An SMTP account for the escalation and alert emails

Supabase is the only real setup step. The schema comes from the official pgvector guide and the three small tables are a handful of columns each.

What it does not do

It does not read images or voice notes. It does not write to your CRM or open tickets. It does not manage a reply queue - escalations arrive as email, and your team replies to the customer themselves, from their own Telegram account. It gives them no console to work from, and it has no way of knowing when they are finished, which is why a handoff lapses on a timer rather than on a signal.

It also will not answer anything you have not given it. That is the design, not a limitation to be fixed: a bot that improvises about a refund policy is the reason people distrust support bots.

If you want this on WhatsApp instead, with a dashboard showing where every answer came from, that is Namici Chatbot and it is a different product.

Get it

AI Support Agent with RAG Knowledge Base and Human Handoff - free

The workflow JSON, the Supabase schema, and sticky notes on the canvas explaining what each branch is for. It is free and complete - nothing in it is crippled or time-limited, and it will not become a paid product later. I would rather you run it than read about it.

There is a larger paid workflow, Human Takeover, where a colleague works the conversation from inside the system - replying, claiming and closing chats without leaving Telegram - rather than being emailed and stepping aside. A different build, not this one with the good parts taken out.

If you would rather have it pointed at your own documents, your own channel and your own escalation rules, that is the work I do - tell me what you need.