From Facebook Messenger to Telegram: Building a Shared AI Gateway for MyZubster
We recently completed a production bridge between Facebook Messenger, MyZubster and Zorgax, and we are now extending the same architecture toward Telegram.
The key idea is simple:
don’t build one AI bot per platform. Build one shared conversational core, then connect multiple channels to it.
Our current Messenger architecture is:
Facebook User
↓
MyZubster Community Page
↓
Meta Webhook
↓
Validation / Normalization / Deduplication
↓
Zorgax or Deterministic Router
↓
Marketplace · Seller · Metaverse
LIFE Pilot · Community · Comic Universe
↓
Meta Send API
↓
Messenger
The important part is what happens in the middle.
We learned quickly that a production AI messaging bridge needs more than an LLM call.
We had to handle:
webhook verification
HMAC signature validation
is_echo protection
event deduplication
quick replies
postbacks
attachments
short-term conversation context
media delivery
commercial grounding
runtime observability
serverless async execution
One of the biggest lessons came from live testing.
Zorgax once correctly remembered that a user was asking about Seller onboarding, but generated unsupported assumptions about pricing and fees.
In another test, the generic AI path incorrectly said that the Comic Universe was not publicly available.
But MyZubster already knew those facts.
That led us to formalize this rule:
Application Truth Before Generative Output
If the application already knows the truth, the model should not improvise it.
So known facts such as pricing, canonical URLs, resource availability and public media routes are now grounded or handled deterministically.
Zorgax remains responsible for language, explanation, guidance and conversational flow.
That separation made the architecture much more reliable.
Now we are applying the same principle to Telegram.
The target architecture is:
MyZubster
│
Zorgax
│
Shared Channel Core
/ | \
/ | \
▼ ▼ ▼
Messenger Telegram Future
Telegram should only own Telegram-specific behavior:
webhook validation
update_id deduplication
chat_id / user_id
commands
callback queries
sendMessage
sendPhoto
inline keyboards
Telegram API errors
The shared core should own:
canonical destinations
Seller grounding
Metaverse routing
Comic Universe semantics
Culture/Subculture routing
LIFE navigation
application truth
AI safety rules
This also supports a wider MyZubster vision.
A physical event can become the starting point of a longer community journey:
Event
↓
People / music / art
↓
Recycling / local action
↓
QR code
↓
Messenger or Telegram
↓
Zorgax
↓
Culture / Subculture
↓
Metaverse / LIFE / Community
↓
Next real activity
The digital layer doesn’t replace the event.
It helps preserve the connections created during it.
We also documented the architecture and operations publicly.
Messenger architecture guide
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/META_MESSENGER_ZORGAX_BRIDGE.md
Messenger operations runbook
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/META_MESSENGER_OPERATIONS_RUNBOOK.md
Telegram bridge plan
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/TELEGRAM_ZORGAX_BRIDGE_PLAN.md
Main repository
https://github.com/MyZubster-Ecosystem/myzubster
MyZubster Metaverse
https://www.myzubster.com/metaverse
MyZubster Comic Universe
https://www.myzubster.com/fumetto
The main takeaway from this work is that the real challenge in multi-channel AI systems is not “how do I connect an LLM to another API?”
It’s deciding:
what belongs to the model, what belongs to the application, what must be deterministic, what must be grounded, and how to keep those rules consistent across every channel.
That’s the direction we’re taking with MyZubster and Zorgax.
