Simulator

How a Telegram agent stack is wired

Simulated router
Simulated failover
In-memory session
Fake Telegram UI

Click a scenario. The page walks the usual stages: inbound message, session, intent, a specialist, a reply that looks like Telegram. Routing here is keyword matching. There is no live bot, no LangGraph process, and no LiteLLM proxy on this demo.

Stages a real Telegram agent stack often uses
WALKTHROUGH
Stage 01
Inbound message
In production this is a webhook. Here the page just accepts the text you typed.
Stage 02
Intent router
In production this might be a graph supervisor. Here it is keyword matching.
Stage 03
Specialist workers
SQL, research, memory, actions. On this page they return canned examples.
Stage 04
Model routing
In production, a proxy such as LiteLLM. Here the failover toggle only changes labels.
Stage 05
Reply
A fake Telegram pane. Nothing is sent to Telegram.
Interactive Scenario Selector
Live Controller
Pick a scenario
Simulate primary model failure Flips the canned provider string from the primary to a fallback. No real API call is made.
Execution Results & Telemetry
1. What this page is
A click-through of the stages. Session memory here is a Python dict. Intent is keyword matching. Replies are templates. That is enough to show the shape of the work, not enough to call it a bot.
2. What a production build would add
A real webhook, a real supervisor (often a graph), a model proxy with failover, and a store that survives a restart. Those pieces are not running behind this demo.
3. Telegram itself
Telegram is picky about rate limits and Markdown. A real dispatcher has to deal with that. This pane only looks like a chat.