Setting Up Multiple Concurrent OpenClaw Agents with Separate Memory | Friends of the Crustacean 🦞🤝 | Page 1

frail fox Feb 12, 2026, 10:32 AM

#

The Goal
I want to run multiple OpenClaw agents simultaneously, each with their own independent memory and context. These aren't sub-agents of a main agent - they're separate agents running in parallel. I need to figure out the best architecture for:

Calling/triggering agents separately
OR having a main orchestrator bot that delegates to specialized agents
Monitoring status and conversations between agents

Current Understanding
I'm trying to decide between two approaches:
Approach 1: Direct Agent Calls

Call each specialized agent directly when needed
Each agent maintains its own memory/context
I manually route tasks to the appropriate agent

Approach 2: Orchestrator Pattern

One main "router" agent that analyzes requests
Main agent delegates to specialized agents
Agents can communicate with each other through the orchestrator
I can observe the multi-agent conversation flow

Questions for the Community

What's the recommended pattern for running multiple concurrent agents in OpenClaw? Is there built-in support for agent orchestration?
Memory isolation: How do I ensure each agent maintains completely separate memory/context? Do I need separate instances, sessions, or configuration files?
Inter-agent communication: If I go with the orchestrator approach, what's the best way to:

Have agents pass information to each other
Track conversation chains between agents
Prevent infinite loops or circular delegations

Status monitoring: How can I:

See which agents are currently active/idle
View the conversation history between agents
Debug when agents aren't communicating properly

Best practices: Has anyone successfully implemented a multi-agent system with OpenClaw? What worked well and what pitfalls should I avoid?

hushed quiverBOT Feb 12, 2026, 10:32 AM

#

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

fringe pumiceBOT Feb 12, 2026, 10:35 AM

#

frail fox The Goal I want to run multiple OpenClaw agents simultaneously, each with their ...

OpenClaw actually has a first-class “multiple independent agents in one Gateway” mode — you don’t need to fake it with sub-agents.

1) Recommended pattern: Multi-Agent Routing (built-in)

If what you want is “separate brains” (separate memory, auth, sessions, workspace), the intended architecture is:

One Gateway process
Many agents (agents.list[])
Deterministic routing of inbound messages to an agent via bindings

Docs: https://docs.openclaw.ai/concepts/multi-agent

Create agents with:

openclaw agents add work
openclaw agents add home
openclaw agents list --bindings

#

Docs: https://docs.openclaw.ai/cli/agents

This maps cleanly to your “Approach 1: Direct Agent Calls” and keeps things simple/observable.

2) Memory isolation: how to make it truly separate

An “agent” in OpenClaw is isolated by design:

Separate workspace (where memory/ + MEMORY.md live)
Separate agentDir (per-agent auth profiles, etc.)
Separate session store (chat history)

Docs:

Memory model: https://docs.openclaw.ai/concepts/memory
Workspace layout: https://docs.openclaw.ai/concepts/agent-workspace

Key rule: don’t share workspace or agentDir between agents (that’s where collisions happen).

#

If you need even stronger isolation (separate config/state/ports, “rescue bot”, etc.), run multiple Gateways with profiles:
https://docs.openclaw.ai/gateway/multiple-gateways

3) Inter-agent communication / orchestrator pattern

There are two good options:

A) “Orchestrator” agent that messages other agents (opt-in)

OpenClaw has agent-to-agent messaging, but it’s disabled by default and allowlisted when enabled:

tools: {
  agentToAgent: {
    enabled: false,
    allow: ["home", "work"],
  },
},

#

(From config docs: https://docs.openclaw.ai/gateway/configuration )

Under the hood, this uses session tooling like sessions_send, and there are built-in guardrails (see below).
Docs: https://docs.openclaw.ai/concepts/session-tool

B) Don’t orchestrate; route instead

In practice, routing is often cleaner than orchestration:

Put each specialist agent behind its own “entry point” (Discord channel/thread, Telegram chat, specific peer/group)
Let the human (or automation) choose where to talk

This avoids “agents chatting with agents” complexity.

4) Preventing infinite loops / circular delegations

If you enable agent-to-agent messaging, OpenClaw includes a built-in “ping-pong” limiter:

agentToAgent.maxPingPongTurns (0–5, default 5)
Agents can stop the loop by replying REPLY_SKIP

#

Docs (session tools): https://docs.openclaw.ai/concepts/session-tool

Best practice: make the orchestrator do one-hop delegation (router → specialist → result), and avoid “specialist delegates again” unless you really need it.

5) Status monitoring / debugging

See active/idle sessions

openclaw sessions --active 120
openclaw sessions --json

Docs: https://docs.openclaw.ai/cli/sessions

View what’s happening live

Control UI:
```
openclaw dashboard
```

#

Docs: https://docs.openclaw.ai/cli/dashboard

Tail logs:
```
openclaw logs --follow
```
Docs: https://docs.openclaw.ai/cli/logs

Trigger a specific agent directly (great for automation)

openclaw agent --agent work --message "Summarize today’s alerts"

Docs: https://docs.openclaw.ai/cli/agent

Practical recommendation

If your priority is clean isolation + parallelism: use Multi-Agent Routing (Approach 1).
Add an orchestrator only when you have a real need for automated delegation, and keep agent-to-agent tightly allowlisted + bounded.

#

If you tell me which channel(s) you’re using (Discord only? Discord+Telegram? multiple accounts?), I can suggest a concrete bindings layout (e.g. “one Discord channel per agent” vs “route DMs by sender id” vs “route by accountId”).

frail fox Feb 12, 2026, 10:43 AM

#

@fringe pumice I am using telegram

fringe pumiceBOT Feb 12, 2026, 10:47 AM

#

frail fox <@1457407575476801641> I am using telegram

If you’re using Telegram, the cleanest way to get truly separate concurrent agents (separate workspace + memory + sessions) is:

Option A (best UX): multiple Telegram bots (multi-account) → one agent each

Create multiple bots with BotFather (e.g. @mybot_home, @mybot_work, @mybot_ops), then wire them up as Telegram accounts and bind each accountId to an agentId.

{
  agents: {
    list: [
      { id: "home", workspace: "~/.openclaw/workspace-home" },
      { id: "work", workspace: "~/.openclaw/workspace-work" },
    ],
  },

  channels: {
    telegram: {

#

      accounts: {
        homebot: { botToken: "123:AAA..." },
        workbot: { botToken: "456:BBB..." },
      },

      // (optional but recommended) lock DMs down
      dmPolicy: "allowlist",
      allowFrom: ["802798418585190410"] // <- Telegram user ID (numeric) or @username
    },
  },

  bindings: [
    { agentId: "home", match: { channel: "telegram", accountId: "homebot" } },
    { agentId: "work", match: { channel: "telegram", accountId: "workbot" } },
  ],

#

Now you just DM different bots to “call” different agents. This is the closest match to “separate agents running in parallel” on Telegram.

Docs:

Telegram channel: https://docs.openclaw.ai/channels/telegram
Multi-account pattern: https://docs.openclaw.ai/gateway/configuration (see channels.telegram.accounts)
Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent

Option B: one bot, multiple Telegram groups (bind each group to a different agent)

If you want to keep a single bot, create separate private groups like “Home Agent”, “Work Agent”, add the bot to each, then bind by peer:

bindings: [

#

  { agentId: "home", match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } } },
  { agentId: "work", match: { channel: "telegram", peer: { kind: "group", id: "-1009999999999" } } },
]

This works well, but it’s “different chats” rather than “one chat with many agents”.

Telegram-specific gotcha (important)

Telegram DMs collapse into the agent’s main session (“one DM thread → one agent session”). So if you want multiple independent agents from your perspective, you’ll generally want Option A (multiple bots) or Option B (multiple groups).

Getting your Telegram user id for `allowFrom`

channels.telegram.allowFrom is the human sender’s Telegram user ID (numeric) or @username (not the bot username). Safest way: DM your bot, run:

openclaw logs --follow

…and read from.id.

#

FAQ section: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom

Tell me which UX you want:

multiple bots you DM, or
one bot + multiple groups, or
one bot + an orchestrator agent (single chat, router delegates).

frail fox Feb 12, 2026, 10:56 AM

#

@fringe pumice what is the best option for me. My goal is have multiple agent do multiple work. i can call one bot to do spesific task

main bot can call other bot. I can monitor there work

make spesific team for spesific task remport me back what the best way to monitor and keep it clean

fringe pumiceBOT Feb 12, 2026, 10:57 AM

#

frail fox <@1457407575476801641> what is the best option for me. My goal is have multiple ...

For Telegram, I’d do one “front door” bot + one Gateway + multiple internal agents, with a router/orchestrator agent that delegates work to specialist agents and then reports back once.

That hits all your goals: “call one bot”, “multiple agents do work in parallel”, “I can monitor”, “keep it clean”.

Recommended setup (Telegram)

1) One Telegram bot account (what you DM) → bind it to agent router
2) Add specialist agents (research, coder, ops, etc.) with their own workspaces/memory
3) Enable agent-to-agent messaging so router can call specialists
4) Keep output clean: specialists return results to router, and specialists should reply ANNOUNCE_SKIP (so they don’t spam Telegram directly)

Docs:

Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent
Session tools + agent-to-agent behavior: https://docs.openclaw.ai/concepts/session-tool

Minimal config shape:

#

{
  agents: {
    list: [
      { id: "router", default: true, workspace: "~/.openclaw/workspace-router" },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coder", workspace: "~/.openclaw/workspace-coder" },
    ],
  },
  bindings: [
    { agentId: "router", match: { channel: "telegram" } },
  ],
  tools: {
    agentToAgent: { enabled: true, allow: ["router", "research", "coder"] }
  }
}

#

How to “call a specific team / agent”

In Telegram, you just message the router like:

research: find X and summarize
coder: write Y
team: release-check (research + ops + coder)

Router turns that into sessions_send calls to the right agents, then combines results.

Monitoring (best tools)

Control UI: openclaw dashboard (best overall “what’s running / what replied”)
https://docs.openclaw.ai/cli/dashboard
See activity quickly: openclaw sessions --active 120
https://docs.openclaw.ai/cli/sessions
Debug comms: openclaw logs --follow
https://docs.openclaw.ai/cli/logs

Keeping it clean (practical tips)

#

Make router the only agent that talks to Telegram.
Put a rule in each specialist agent’s AGENTS.md: “When invoked by another agent, return a short structured result and reply ANNOUNCE_SKIP.”
Give specialists tighter tool access (e.g. research = web only, coder = files, etc.) so they stay “in their lane”.

One important note: Telegram does not have the WhatsApp-style “broadcast groups” feature (that one is WhatsApp-only), so on Telegram the clean pattern is router + delegates, not “everyone replies in the same chat”.

If you tell me what your specialist list is (e.g. research/coding/trading/monitoring/etc.), I can suggest a clean “team command” scheme and which agents should be sandboxed/read-only.

frail fox Feb 12, 2026, 11:05 AM

#

@fringe pumice IS there way i can make a nice dashboard where i visually see all the agents and there config like profile which telelgram they are connected and everyhting.

channel or ai token
there profile behaviour

for to make such a live time dashboard can you help me build this with clawdbot

help me with the promot so i can have option to change it from the dashboard and it's update the json directy.

I can tlak to him form there and all other options

fringe pumiceBOT Feb 12, 2026, 11:07 AM

#

frail fox <@1457407575476801641> IS there way i can make a nice dashboard where i visually...

Yes — you don’t need to build a new dashboard from scratch for this. OpenClaw already ships a live Control UI (dashboard) that can:

show sessions (active/idle-ish), chat history, abort runs
show channels status (Telegram connected, etc.)
show/edit config (including agents.list, bindings, channels.telegram.accounts)
run config.set / config.patch / config.apply (validate + restart)
tail logs in realtime

Docs: https://docs.openclaw.ai/web/control-ui

1) The “nice dashboard” you want = the built-in Control UI

Open it:

openclaw dashboard
# or just visit http://127.0.0.1:18789/

#

If connecting from another device/browser, you may need to approve it:

openclaw devices list
openclaw devices approve <requestId>

Security note: this UI is an admin surface (config + exec approvals etc). Don’t expose it publicly; use localhost, Tailscale Serve, or SSH tunnel. (The docs have the safe remote patterns.)

2) Seeing “which Telegram each agent is connected to”

That mapping is defined by:

channels.telegram.accounts.<accountId> (each bot token)
bindings[].match.accountId → routes that Telegram bot/account to an agentId

Control UI can show this because it can display the config (and channel status per account). Relevant docs:

Telegram multi-account pattern: https://docs.openclaw.ai/gateway/configuration (search channels.telegram.accounts)
Routing: https://docs.openclaw.ai/concepts/multi-agent

#

3) Editing config from the dashboard (and updating JSON on disk)

Use Control UI → Config:

config.get shows your current ~/.openclaw/openclaw.json
you can edit and Apply (it validates + restarts)

This is already implemented; you don’t need a special prompt for that part.

4) “Talk to him from there”

Control UI includes chat (WebChat) via the Gateway WebSocket, so yes — you can chat from the dashboard. (You can also use the TUI if you like: https://docs.openclaw.ai/web/tui)

If you still want a custom “multi-agent manager” UI

Best path is to fork/extend the existing Control UI, because it already has:

auth/pairing
websocket client
RPC plumbing

#

config schema rendering

Docs show how to run it locally:

pnpm ui:dev and point it at your gateway URL (described here): https://docs.openclaw.ai/web/control-ui#debuggingtesting-dev-server--remote-gateway

Then you’d add a page that calls RPC like:

config.get / config.schema (render agent list + bindings nicely)
channels.status (show Telegram account state)
sessions.list (show active sessions)
logs.tail (debug panel)

“Prompt” to keep config changes clean (recommended pattern)

Even if you use the built-in UI editor, you can keep your router agent disciplined with an instruction like:

When the user asks to change OpenClaw config, do NOT guess.
Output: (1) a JSON5 config.patch snippet, (2) what it changes, (3) whether restart is required, (4) rollback steps.
Never print secrets (tokens). Ask for confirmation before any breaking change.

#

If you tell me whether you’re going with one Telegram bot + router or multiple Telegram bot accounts, I can suggest the cleanest layout for agents.list + channels.telegram.accounts + bindings, so the dashboard view stays readable.

split granite Feb 12, 2026, 6:15 PM

#

Can I create a telegram group, add separate bot accounts for each agent to the group and have all 3 of us message each other in that group?

fringe pumiceBOT Feb 12, 2026, 6:18 PM

#

split granite Can I create a telegram group, add separate bot accounts for each agent to the g...

Yes — Telegram allows multiple bots in one group, and OpenClaw can run multiple Telegram bot accounts in one Gateway, each routed to a different agentId.

How to set it up (3 bots → 3 agents → same Telegram group)

Create 3 bots in BotFather → 3 tokens
Configure them as Telegram accounts and bind each account to an agent:

{
  agents: {
    list: [
      { id: "agent1", workspace: "~/.openclaw/workspace-agent1" },
      { id: "agent2", workspace: "~/.openclaw/workspace-agent2" },
      { id: "agent3", workspace: "~/.openclaw/workspace-agent3" },
    ],
  },

#


  channels: {
    telegram: {
      accounts: {
        a1: { botToken: "123:AAA..." },
        a2: { botToken: "456:BBB..." },
        a3: { botToken: "789:CCC..." },
      },

      // Allow the group (this becomes an allowlist if you set it)
      groups: {
        "-1001234567890": { requireMention: true }
      },

      // IMPORTANT for “keep it clean”: only let *humans* trigger group runs

#

      groupPolicy: "allowlist",
      groupAllowFrom: ["802798418585190410"] // your Telegram user id
    },
  },

  bindings: [
    { agentId: "agent1", match: { channel: "telegram", accountId: "a1" } },
    { agentId: "agent2", match: { channel: "telegram", accountId: "a2" } },
    { agentId: "agent3", match: { channel: "telegram", accountId: "a3" } },
  ],
}

In the group, you “talk to a specific agent” by mentioning its bot (or using a command). Each bot speaks with its own identity (since it’s a different Telegram account).

#Setting Up Multiple Concurrent OpenClaw Agents with Separate Memory

1) Recommended pattern: Multi-Agent Routing (built-in)

2) Memory isolation: how to make it truly separate

3) Inter-agent communication / orchestrator pattern

A) “Orchestrator” agent that messages other agents (opt-in)

B) Don’t orchestrate; route instead

4) Preventing infinite loops / circular delegations

5) Status monitoring / debugging

See active/idle sessions

View what’s happening live

Trigger a specific agent directly (great for automation)

Practical recommendation

Option A (best UX): multiple Telegram bots (multi-account) → one agent each

Option B: one bot, multiple Telegram groups (bind each group to a different agent)

Telegram-specific gotcha (important)

Getting your Telegram user id for `allowFrom`

Recommended setup (Telegram)

How to “call a specific team / agent”

Monitoring (best tools)

Keeping it clean (practical tips)

1) The “nice dashboard” you want = the built-in Control UI

2) Seeing “which Telegram each agent is connected to”

3) Editing config from the dashboard (and updating JSON on disk)

4) “Talk to him from there”

If you still want a custom “multi-agent manager” UI

“Prompt” to keep config changes clean (recommended pattern)

How to set it up (3 bots → 3 agents → same Telegram group)

Two Telegram gotchas

#Setting Up Multiple Concurrent OpenClaw Agents with Separate Memory

1) Recommended pattern: Multi-Agent Routing (built-in)

2) Memory isolation: how to make it truly separate

3) Inter-agent communication / orchestrator pattern

A) “Orchestrator” agent that messages other agents (opt-in)

B) Don’t orchestrate; route instead

4) Preventing infinite loops / circular delegations

5) Status monitoring / debugging

See active/idle sessions

View what’s happening live

Trigger a specific agent directly (great for automation)

Practical recommendation

Option A (best UX): multiple Telegram bots (multi-account) → one agent each

Option B: one bot, multiple Telegram groups (bind each group to a different agent)

Telegram-specific gotcha (important)

Getting your Telegram user id for allowFrom

Recommended setup (Telegram)

How to “call a specific team / agent”

Monitoring (best tools)

Keeping it clean (practical tips)

1) The “nice dashboard” you want = the built-in Control UI

2) Seeing “which Telegram each agent is connected to”

3) Editing config from the dashboard (and updating JSON on disk)

4) “Talk to him from there”

If you still want a custom “multi-agent manager” UI

“Prompt” to keep config changes clean (recommended pattern)

How to set it up (3 bots → 3 agents → same Telegram group)

Two Telegram gotchas

Getting your Telegram user id for `allowFrom`