OpenClaw Agent Relay Plugin Fixes Telegram Delivery in Multi-Agent Setups

A developer has released openclaw-agent-relay, a plugin that solves the problem where sessions_send in multi-agent setups fails to deliver responses to Telegram users.
The Problem with sessions_send
When using sessions_send to pass messages between agents, the target agent's response goes to channel=webchat (an internal channel) instead of reaching the user on Telegram. This happens because sessions_send preserves session and conversation history but doesn't properly handle delivery. The issue is documented in closed ticket #13374 marked as NOT_PLANNED. Additionally, it can corrupt the session's delivery context, flipping it from telegram to webchat permanently (referenced in #44153 and #31671).
Existing Workarounds and Their Limitations
Developers have tried two main approaches:
- Explicit message tool usage: The target agent calls message with channel: "telegram" and explicit to/threadId, then returns ANNOUNCE_SKIP. This is documented in #47971 and #28603. Problems include needing to embed delivery instructions in every sessions_send payload and agents forgetting to use the workaround, especially in longer sessions.
- Relying on announce step: Using timeout=0 to get an announce step where the agent can write a user-facing response. However, models tend to return ANNOUNCE_SKIP instead of writing content (#43295). Announce delivery also has issues: drops threadId for Telegram topics (#47971, #45878), silently fails with multi-channel setups (#47524), and ANNOUNCE_SKIP text can leak to users (#45084).
The Solution: openclaw-agent-relay
The plugin bypasses both sessions_send and announce entirely. It uses the same gateway WebSocket RPC that subagents use internally (callGateway({ method: "agent" })) to trigger an agent turn in the existing session with deliver: true. The agent responds normally without special instructions, ANNOUNCE_SKIP, or message tool workarounds, and the response goes directly to Telegram.
How to Use It
Two methods are available:
- Tool wake_agent: Any agent can call it to wake another agent in their session:
wake_agent({ sessionKey: "agent:my-agent:telegram:direct:123456", message: "Hey, remind the client about the contract" }) - HTTP POST /notify: For cron jobs, scripts, or external triggers:
curl -X POST http://127.0.0.1:18790/notify \ -H "Authorization: Bearer your-secret-token" \ -H "Content-Type: application/json" \ -d '{"sessionKey":"agent:my-agent:telegram:direct:123456", "message":"Reminder: client asked for the contract"}'
Installation
Install with: openclaw plugins install openclaw-agent-relay
The developer notes that implementing the gateway RPC authentication involved working with Ed25519 device identity, challenge-response protocols, and undocumented protocol quirks.
📖 Read the full source: r/openclaw
👀 See Also

Measuring Off-Task Token Spend in Claude Code: The 'Undeclared-Intent' Metric
A developer built a metric to quantify compute spent on unintended execution paths in Claude Code sessions, finding that 22.8% of tokens went to off-task work.

sandboxd: Open-Source Tool to Run Multiple Claude Code Agents in Isolated Containers
sandboxd is an open-source (MIT) tool that runs each Claude Code project in its own Docker container with isolated workspace, Claude Code session, and preview URL. It supports parallel agents, auto-sleep, and keeps API keys out of containers.

OpenClaw Memos Plugin Addresses Memory Handoff Issues in AI Coding Agents
A Reddit user shares how the Claude code leak highlighted problems with memory handoff in AI coding agents, where bloated transcripts cause issues during model switching. They implemented the memos plugin in OpenClaw with selective recall strategy to compress recent work and drop stale tool calls.

CC-Wiki: Turn Claude Code Sessions into a Shareable Quartz Knowledge Base
CC-Wiki converts your ~/.claude session history into a Quartz-based knowledge base. One command installs it; running /cc-wiki inside a Claude Code session packages the conversation.