Skip to content
EXP-02ActiveWorkflow Automation

Telegram AI agent workflows

Using Telegram as the interface for small AI workflows, with a webhook that answers fast and a worker that does the slow, retryable part.

Fig. 01/Architecture
messageupdateenqueueclaimpromptYouTelegram appTelegramBot APIWebhookverify, ack fastJob queueSQLiteWorkerretries, timeoutsModelLLM API
Sample design. The webhook only verifies and enqueues, so Telegram gets an immediate answer. A separate worker makes the slow model call, retries safely and replies through the Bot API.

Parts

  • YouTelegram app
  • TelegramBot API
  • Webhookverify, ack fast
  • Job queueSQLite
  • Workerretries, timeouts
  • ModelLLM API

Objectives

  • Use Telegram as the interface for small AI workflows: quick questions, summaries of links, and notes that turn into tasks.
  • Answer every message exactly once, even when Telegram redelivers an update.
  • Keep slow model calls away from the webhook, so it always answers in time.
  • Make failures visible and replayable.

Architecture

Telegram delivers updates to a webhook that verifies the secret token, stores the update in a job queue keyed by update_id, and returns immediately. A separate worker claims queued jobs, calls the model with a timeout, and replies through the Bot API. The queue table doubles as the run log.

Implementation notes

The full pattern, with code, is in the journal article Building Reliable Telegram AI Workflows. Points that came up while building it:

  • Registering the webhook with allowed_updates keeps unused update types from ever arriving.
  • Using update_id as the primary key makes duplicate deliveries harmless: the second insert is simply ignored.
  • A typing chat action at the start of each job makes slow answers feel intentional rather than broken.
  • Long replies are split at line breaks below the 4,096 character limit, and HTTP 429 responses are retried after the retry_after delay Telegram provides.

Results

Sample entry. Record observations as the workflows run: how often updates were redelivered, how long typical jobs take end to end, and which failures needed a manual replay.

Limitations

  • A single worker processes jobs one at a time. That is fine for one person, and would need BEGIN IMMEDIATE claims and more workers for a group.
  • Webhooks need a public HTTPS endpoint, which adds a moving part compared with long polling.
  • Model answers are only as good as the prompt and the model. The queue makes delivery reliable, not the content.

Future improvements

  • Per-chat rate limiting, so one busy conversation cannot starve the others.
  • A small dashboard over the job table showing failures and replay buttons.
  • Structured commands for the most common workflows, so they skip the model entirely.

Source code and references

  1. [1]Telegram Bot API reference
  2. [2]setWebhook and secret_token

More from the lab

Full log