From hobby bot to customer-facing product.

The crossing

Your Telegram bot works for you. It even works for the friends you've shown it to. But the moment you try to serve five customers from the same process, the assumptions start to crack:

• Sessions collide because they're stored in one directory.
• Memory bleeds because your vector store has no tenant column.
• One customer's API key is now ambient to every conversation.
• Cron jobs you scheduled for yourself run for everyone.
• Cost is opaque — you have one bill from Anthropic, no way to attribute it.

Either you spend the next six weeks adding tenant fields to every table and fixing every code path that assumes one user, or you adopt a primitive that already did that work.

Migration playbook

1. Install OpenClawMU on the same box as your current bot (different port).
2. Create one tenant per existing customer with the CLI.
3. Pair their channel (WhatsApp / Telegram / Slack) under that tenant.
4. Move your custom tools into the tenant's plugins/ directory.
5. Test end-to-end with one tenant; cut the others over channel by channel.
6. Tear down the legacy bot.

Typical migration: a weekend if your bot is <500 lines, a week if it's a real product. The bigger payoff is that adding your sixth, tenth, fiftieth customer is no longer an architectural decision.

What you keep

• Your prompts. Drop them in the tenant's config.yaml.
• Your tools / skills. Drop them in plugins/.
• Your model choice. Set per-tenant or globally.
• Your domain logic. The agent runtime is the same upstream OpenClaw agent runtime, with the tenant boundary added.

What you stop maintaining

• The "user_id everywhere" patches you keep meaning to add.
• The cron-collision bug you've been ignoring.
• The "I should sandbox this" todo on every code-executing tool.
• The make-a-CSV-of-tokens script you'll need eventually.
• The "we should back this up" guilt.