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

How OpenCLAW Memory Actually Works: Fixing Agent 'Forgetting'
OpenCLAW agents don't have persistent memory between conversations - they reconstruct context from files like SOUL.md, USER.md, and MEMORY.md each time. Common 'forgetting' issues stem from old sessions, unstructured memory files, and storing important info in chat history instead of permanent files.

OpenClaw Multi-Agent Playbook: 7 Isolated Agents for 5/Month
Complete architecture guide for running specialized AI agents with focused memory, least-privilege permissions, and smart model routing.

ClaudeBusiness Repo: Patterns for Running Real Businesses with Claude Code
A GitHub repo collecting practical patterns, frameworks, and guardrails from 35+ Reddit threads of founders using Claude to run service agencies and solo SaaS businesses.

Optimizing GLM-4.7-Flash on M4 Mac Mini with 24GB RAM
A developer shares specific configuration details for running GLM-4.7-Flash on an M4 Mac Mini with 24GB RAM, including Q3_K_XL quantization, 32k context size with MLA, and memory allocation realities for Metal.