#multi-agent setup on telegram

1 messages · Page 1 of 1 (latest)

glass idol
#

Hi,
I want to make a multi-agent setup on a Telegram group.

My goal is to add my main bot and all worker bots in one place in t he telegram bot.

The task is to talk to the main bot, who asks tasks to the other bot, who has specific knowledge for those jobs.

Once the job is done, he will take the main bot or the sub bot, and they all finish the job together.

For this setup, how to move the flower?

latent domeBOT
#

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

unique belfryBOT
# glass idol Hi, I want to make a multi-agent setup on a Telegram group. My goal is to add...

You probably mean “move the flow” (not “flower”) — and yes, OpenClaw can do this.

There are two ways to build what you described on a Telegram group:

Option A (recommended): 1 Telegram bot in the group + internal “worker” sub-agents

This gives you the UX you want (“one place”), without needing multiple Telegram bot accounts.

How it works

  • You talk to the main bot in the Telegram group.
  • The main bot delegates work using Sub-Agents (sessions_spawn) in the background.
  • Sub-agents “announce” results back into the same group/thread, and the main bot integrates the final answer.

Docs:

Why this is best

#
  • Much simpler than coordinating multiple Telegram bots
  • Cleaner conversation (one identity)
  • Parallel work is built-in and observable via /subagents …

Option B: multiple Telegram bot accounts in the same group (main + workers)

If you really want separate bot identities (each with its own @username), OpenClaw supports multi-account Telegram via channels.telegram.accounts, and you can route each account to a different agent using bindings.

Key docs:

Reality check: this is more complex and usually not necessary—Telegram bots + privacy mode + who receives what can get fiddly.

What you likely want (practical setup)

  1. Run 1 Telegram bot in the group
#
  1. Configure the group so the bot responds only when mentioned (default), or always respond:
    • channels.telegram.groups["<groupId>"].requireMention
  2. Create specialized workers as either:
    • sub-agents (same agentId, different tasks), or
    • separate agentIds (each with its own workspace/skills), and allow spawning into them with:
    • agents.list[].subagents.allowAgents

Quick questions so I can point you to the exact config snippet

  1. Are you using one Telegram bot or do you want multiple bot usernames in the group?
  2. Are you running OpenClaw already? If yes, what does openclaw --version show?
  3. Will the group have just you, or multiple people (important for groupPolicy / allowlists)?
glass idol
# unique belfry 2) Configure the group so the bot responds only when mentioned (default), or alw...

openclaw version: 2026.2.1

right now using one telegram bot.
I made another worker agent, but I can't connect to both at the same time.

If I make sub-agents, can they have separate knowledge of their task?

What happens is that the more I use the main agent, the more the bot forgets what we are even doing, which affects the sub-agents as well.

That's why I was thinking if this is multiple agents and all separate, that would be the best move.

unique belfryBOT
#

With one Telegram bot in one group, OpenClaw will route that group’s messages to exactly one agent (bindings are deterministic). So you can’t “be connected to two agents at the same time” in the same chat in the sense of: both agents receiving the same inbound messages and both replying independently.

What you can do (and what usually works best) is:

1) Use 1 “coordinator” agent in the group, and spawn worker agents behind the scenes

Do sub-agents have separate knowledge?

  • A plain sub-agent run is a fresh session (so it doesn’t inherit the whole long chat history)… but it only knows what you put in the task you give it, plus the agent’s workspace/instructions.
  • If you want truly specialized knowledge + separate memory/files, you should spawn the sub-agent under a different agentId (a worker agent with its own workspace).

That’s exactly what sessions_spawn(agentId: "...") is for, gated by agents.list[].subagents.allowAgents.

Docs:

Minimal config pattern (coordinator + workers)

# 
{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        // allow main to spawn into these worker agents
        subagents: { allowAgents: ["research", "coder"] },
      },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coder", workspace: "~/.openclaw/workspace-coder" },
    ],
  },

  // route the Telegram group to the coordinator agent
# 
  bindings: [
    {
      agentId: "main",
      match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } },
    },
  ],
}

Then your main agent can delegate like:

  • spawn worker: sessions_spawn with agentId: "research" / "coder"
  • integrate results back into the group reply

(You don’t manually “connect” to the worker in Telegram; the coordinator orchestrates it.)

2) About “the more I use it, the more it forgets”

#

That’s normal: you’re hitting context limits and/or compaction, and long group threads get noisy fast. Multiple agents helps isolation, but it doesn’t create infinite memory inside one conversation.

What actually helps in practice:

A) Split work into separate Telegram topics (if your group is a forum)

Each topic becomes its own isolated session key in OpenClaw (so “Project A” doesn’t pollute “Project B”). This is often the biggest win for Telegram groups.

B) Externalize state into a file

Have the coordinator maintain a short STATE.md / PROJECT.md in its workspace and re-read it when continuing. That makes “what are we doing?” resilient even when chat history gets long.

C) Turn on tool-result pruning (reduces token bloat from tool outputs)

Config:

{
  agents: {
    defaults: {
# 
      contextPruning: { mode: "adaptive" }
    }
  }
}

This doesn’t delete history on disk; it just prunes old tool-result bulk from what’s sent to the model.
Docs: https://docs.openclaw.ai/concepts/session-pruning

If you paste your current bindings + agents.list (redact tokens), I can tell you exactly what to change so:

  1. the Telegram group stays on main, and
  2. main can spawn into your worker agent(s) with separate workspaces.
#

Yep — what you’re seeing is expected.

1) Why you “can’t connect to both at the same time”

A single Telegram group chat can only be routed to one OpenClaw agent (bindings are deterministic). So with one Telegram bot in one group, you’ll always be talking to whichever agent that group is bound to.

If you want to talk directly to a worker agent in the same group, you need either:

  • a second Telegram bot account (another BotFather token) added to the group and routed to the worker agent via channels.telegram.accounts + bindings (more setup), or
  • keep one bot and use sub-agents (recommended): the coordinator talks, workers run in the background and report back.

2) “If I make sub-agents, can they have separate knowledge?”

Yes — with an important distinction:

  • Sub-agent runs are separate sessions, so they don’t inherit the whole long chat history (good).
  • To give them separate “knowledge/persona/files/memory”, spawn them under a different agentId (a worker agent with its own workspace), not just a same-agent sub-run.

That’s the sweet spot: 1 coordinator in the group, multiple worker agentIds behind it.

#

Config shape (core idea):

{
  agents: {
    list: [
      { id: "main", default: true, subagents: { allowAgents: ["research", "coder"] } },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coder", workspace: "~/.openclaw/workspace-coder" },
    ],
  },
  bindings: [
    {
      agentId: "main",
      match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } },
    },
# 
  ],
}

Then in the Telegram group you ask the main agent to delegate (it will call sessions_spawn internally). You can inspect with /subagents list.
Docs: https://docs.openclaw.ai/tools/subagents

3) Why “forgetting” happens (and why it affects delegation)

This is almost always context window + compaction. Once the main chat gets long, the model literally can’t “see” everything anymore, so it gets fuzzy on the goal — and then it gives the worker a bad/underspecified task.

Multiple agents help isolation, but they don’t magically make one chat infinite. What helps most:

  • Use Telegram forum topics (each topic = separate session key, much less cross-contamination)
  • Periodically /compact (or start a new session with /new when switching projects)
  • Keep a short “source of truth” file (e.g. STATE.md) that the coordinator updates and re-reads