Creating 10 Telegram Bots in One Day
If someone asked "what did you do today," my answer would be: "Created 10 Telegram bots." Sounds like bragging, but it literally happened in one day. This post documents the entire process of expanding from 5 to 10 bots, and the maddening configuration details of multi-agent routing.
From 5 to 10
The initial OpenClaw deployment had only 5 agents — sufficient but not granular enough. As projects multiplied, one agent handling too many roles led to context confusion. So we decided to split by responsibility: one bot per clear domain.
The final 10-bot roster:
| Bot Name | Responsibility | Model |
|---|---|---|
| Joe (Main) | Lead manager, coordination | Claude Opus |
| NobData | NobData project development | Claude Opus |
| Flect | Flect project management | Claude Opus |
| Life | Life assistant | Claude Opus |
| Learning | Study notes | DeepSeek |
| Real-estate | Real estate investment analysis | GPT-4o |
| Investment | Investment & finance | GPT-4o |
| Health | Health management | DeepSeek |
| Royal | Royal project | Claude Opus |
| Customer-service | Customer service | Claude Opus |
Model Allocation Strategy
Not every bot needs the strongest model:
Project bots get Opus: Agents involving code development need strong reasoning and long-context understanding.
Utility bots get DeepSeek/GPT-4o: Agents mainly doing information organization and Q&A work fine with cost-effective models.
If all 10 used Opus, API costs would skyrocket. Allocating models by actual needs ensures key agent capabilities while controlling overall spend.
The Creation Process
Creating bots on Telegram is fast — @botfather, /newbot, name it, grab the token. One bot per minute, 10 bots in 10 minutes.
The real time sink is OpenClaw-side configuration. Each bot needs:
- Account entry in gateway config (Telegram token)
- Agent config (model, system prompt, tool permissions)
- Binding config (mapping account to agent)
- dmPolicy setup (controlling who can chat with the bot)
10 bots means 40 configuration items. Any single mistake causes a non-responsive bot or routing error.
Multi-Agent Routing Pitfalls
Pitfall 1: Missing Binding Entries
OpenClaw's routing logic: receive message → find binding by account → find agent by binding. If an account has no corresponding binding entry, the message is silently dropped — no error logs whatsoever.
Lesson: Every time you add a bot, verify three configs simultaneously — account, agent, binding. Missing any one means it won't work.
Pitfall 2: dmPolicy Allowlist
OpenClaw's default dmPolicy rejects all DMs. Forget to set the dmPolicy, and even your own messages get rejected.
A hidden gotcha: the allowlist uses Telegram numeric user IDs, not usernames. I initially used usernames and couldn't figure out why nothing worked.
One Day's Results
From morning planning to all 10 bots responding by evening — a full day:
- 30% planning and design
- 20% creation and basic config
- 50% debugging routing issues
Creation itself is fast; most time was spent on "making them work correctly." This is probably the common trait of all system integration work: connecting is easy, connecting correctly is hard.
Reflections
10 bots follows the same thinking as microservices: rather than one giant bot that does everything, have 10 small bots each with a clear role. Cleaner context, more accurate responses.
Next time we scale to 20 bots, I'll write an automation script first. Repetitive manual work should be automated from the second time onward — that was the day's biggest lesson.
Top comments (0)