#How does openclaw determines where to deliver the response?

1 messages · Page 1 of 1 (latest)

golden zodiac
#

I access the same agent from both local webUI and telegram group.
When sending prompts to the agent from local webui, most of the times, any response will not be delivered to the group. Only if the agent calls any subagent, and the reply afterwards will be delivered to telegram group.
The desired delivery behaiour is:
prompts received from local UI are considered GM discussion. Replies to GM discussion will not be sent to the telegram group topic 3233, unless specifically required by DM through message.send command.
prompts received from telegram group topic 3233 are considered players inquires, reply to those will be posted directly into telegram group. However you are only allowed to reply to inquiries about rules, game states, and lores. You will not update plot or scene at players' requests.
Is this feasible?
Krill can you explain the delivery behaviour and comment on the feasiblity of desired behaviour?

uncut jasperBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

deft estuaryBOT
#

Delivery is determined by the session key (what chat/thread/topic the run is happening in) + whether that session has provider transport (Telegram/Discord/etc) attached.

How OpenClaw decides where replies go

  • If the prompt comes from Telegram topic 3233: the run is in that Telegram-topic session key (Telegram forum topics append :topic:<threadId>), so the reply is delivered back to that same topic automatically.
  • If the prompt comes from the Control UI / local web UI: you’re still sending into some session. If that session is a “local” session, the reply stays in the UI. If that session is actually the Telegram topic session, then you’re effectively “talking inside the Telegram topic from the UI”.

Also important:

Why you only see Telegram delivery after subagents

Sub-agents always do an announce step that posts the result back to the requester chat channel.

From the docs: sub-agents run in agent:<id>:subagent:<uuid> and then announce back to the requester; top-level announces use external delivery (deliver=true). That means:

  • If you spawned the sub-agent while your UI was pointed at the Telegram topic session, the announce will go to Telegram even if your UI session had delivery otherwise “off”.

Docs: https://docs.openclaw.ai/tools/subagents (see “Announce”)

#

Is your desired behavior feasible?

Yes — but the cleanest way is to separate GM vs Players at the session/agent level, not hope the UI magically “knows” intent.

Recommended setup (robust): route the Telegram topic to a dedicated “players” agent

Telegram supports per-topic agent routing:

channels.telegram.groups.<chatId>.topics.<threadId>.agentId

Docs: https://docs.openclaw.ai/channels/telegram (Forum topics → “Per-topic agent routing”)

Example (you’ll need your real chatId like -100...):

{
  agents: {
    list: [
# 
      { id: "gm" },
      { id: "players" }
    ]
  },
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "3233": {
              agentId: "players",
              systemPrompt: "You are the players-facing rules assistant. Only answer rules, game state, and lore. Do not advance plot or change scenes at player request."
            }
          }
        }
# 
      }
    }
  }
}

Then:

  • Use the GM agent from the web UI (private, no Telegram delivery unless you explicitly message.send).
  • Use the Players agent in Telegram topic 3233 (auto-delivery to that topic).
  • You can keep the players agent more locked down (even disable cross-context sending) so players can’t trick it into messaging elsewhere.

“Single agent” setup (works but easier to mess up)

If you insist on one agent, you can still do it by keeping two separate sessions:

  • GM chat in a local/main session in the UI
  • Players chat in the Telegram topic session