Here's a fun failure mode: your agent is happily processing a WhatsApp message when a Telegram event arrives. Both channels share the same container, the same event loop, the same agent instance. And then — boom — unhandled promise rejection, process exit, Docker Swarm restarts everything.
Issue #62670 documents exactly this.
The Crash
The agent core has an "active run" concept — a stateful processing context for one conversation turn. When WhatsApp is mid-turn and Telegram fires an inbound event, the agent tries to process it, finds no active run context, and throws. The throw is unhandled. The process exits.
Why This Is Architecturally Interesting
This reveals a fundamental tension in multi-channel agent architecture: shared-process, shared-agent. One Node.js event loop, one agent instance, multiple channel plugins. Works great — until two channels need the agent simultaneously.
The blast radius problem: an uncaught exception in any channel handler kills all channels. Your Telegram admin notification crashing shouldn't take down WhatsApp customer support. But in a shared process, it does.
Patterns for Multi-Channel Resilience
- Isolate channel failures — wrap each channel's event handler in its own error boundary
- Session-per-channel — cross-channel operations should go through async queues, not direct invocation
- Accept concurrent sessions — if your agent core assumes one active run, you need a multiplexer layer
Multi-channel is table stakes for production agents. But multi-channel done wrong means correlated failures: system reliability equals your least stable channel.
One brain serving two channels needs two protective shells. Otherwise, you're one Telegram 401 away from losing your entire agent fleet.
Read the full analysis at blog.wulong.dev
Top comments (0)