Building a Bridge for Two Telegram Bots in One Group Chat: Delivery Semantics Over HTTP

Connecting two independent Telegram bots in the same group chat is harder than it sounds. A developer on r/openclaw details their experience building a bridge layer because Telegram does not reliably deliver messages from one bot to another in a group — even though humans can see both messages.
The Core Problem
Telegram does not deliver updates to Bot B when Bot A sends a message to the group. So the team built a small bridge around Telegram's limitations:
- Bot B → Bot A: Bot B posts through an HTTP endpoint (tailgate) to reach Bot A.
- Bot A → Bot B: Bot A exposes selected outbound messages through a controlled feed that Bot B polls.
- Messages carry metadata:
source,direction,chat ID,nonce, and asafe_to_bridgeflag. - ACKs: Bot B can ACK a specific message, confirming at least one hop worked.
- The shared feed only contains bridge-safe group context — no private DMs or unrelated traffic.
- Bot B's local poller filters out old/debug/protocol/status messages, deduplicates events, and only lets fresh conversational turns through.
Lessons from the First Version
The initial implementation was too loose: raw Telegram context leaked into the shared feed, causing confusing "how did the other bot know that?" moments. The fix was to move from raw shared logs to explicit bridge-safe events only.
Current state works in controlled tests:
- Bot B → Bot A via relay
- Bot A → Bot B via feed
- ACKs flow through the relay path
- Safe auto-mirror for messages clearly addressed to one bot
Desired Flow
The target conversation loop:
- Human or Bot A writes something addressed to Bot B.
- Bridge mirrors it safely.
- Bot B sees it once, replies once.
- Reply is mirrored back if safe and relevant.
- No duplicates, stale backlog, private DM leak, debug echo, or bot loop.
Architecture Direction
The author suggests treating the bridge like a small event bus rather than a chat hack:
- Strict message IDs and nonces
- ACKs, deduplication, checkpointing
- Scoped feeds with hard separation between private and group-safe context
The hard part is delivery semantics — freshness, dedupe, ACKs, and deciding when a bot should auto-respond without causing infinite loops.
📖 Read the full source: r/openclaw
👀 See Also

You Can Run OpenClaw: Three Paths to an AI Agent (No Terminal Required)
OpenClaw's one-liner installer, managed platforms, and local ollama models remove the technical barrier. Pick your path and start with boring tasks.

Cut Token Costs by 95% with OpenClaw's Seven Optimization Techniques
A comprehensive guide detailing seven techniques to reduce AI agent token consumption by 95%+, including tree-structured boot files, AI auto-compression, local model offloading, and cron-based CPU tasks.

How to avoid unexpected OpenRouter costs in OpenClaw automation
A developer team accidentally spent $750 in 3 days on OpenRouter by defaulting to Claude Sonnet 4.6 ($3/M tokens) across all automation tasks. They reduced costs by 97% by changing default models, locking cron jobs and subagents to cheaper options, and reserving expensive models only for sensitive work.

Running Qwen3.6 27B and 35B on 6GB VRAM with ik_llama: Practical Configs and Benchmarks
A user shares detailed ik_llama configs and performance numbers for running Qwen3.6 27B and 35B A3B models on an RTX2060 mobile (6GB VRAM, 32GB RAM), with prefill speeds of 40-100 t/s and generation up to 11 t/s.