telegram-agent-routerlisted

# Telegram Agent Router A Telegram bot with multiple specialists should be designed as a **message router with durable state**, not as one giant prompt. The architecture in this repository optimizes for: - idempotent webhook intake; - prompt response to Telegram while slow work continues asynchronously; - deterministic fast paths before LLM routing; - explicit agent contracts and bounded permissions; - durable PostgreSQL state where it fits the workload; - privacy-aware memory and audit data; - measurable routing quality and failure recovery. ## Core architecture ```text Telegram update → webhook authenticity + update validation → durable dedupe/enqueue → successful acknowledgment → worker → active-session lookup/create → command/callback/session-lock fast path → bounded intent classification only if needed → agent contract → response validation → Telegram send with Retry-After handling → memory/audit writes under retention policy ``` Do not run a slow LLM call as the only work inside the webhook request path. Telegram can retry unsuccessful/interrupted deliveries; deduplicate using `update_id` before executing expensive work. ## Routing order Prefer deterministic routing before an LLM classifier: 1. known command; 2. callback prefix owned by a registered handler; 3. active flow/session lock; 4. high-confidence deterministic intent hints; 5. bounded classifier for ambiguous free text; 6. orchestrator/fallback. Low confidence should not silently become a high-impact