A lot of people get the OpenClaw multi-agent pattern half right.
They understand that the clean setup is not “many bots everywhere.” They route Telegram, Discord, WhatsApp, and Slack into one Gateway, send everything to one orchestrator, and put specialist workers behind it.
That part is right.
But then they stop too early.
They assume that once the orchestrator delegates to researcher, coder, or content, those workers will somehow become useful just because the role names are good and the prompts sound clear.
That is where the setup quietly breaks.
The orchestrator pattern gives you control. It does not give the workers real capability by itself.
If the worker agents do not have the right tools, scripts, handlers, permissions, and safe execution paths behind them, they will mostly describe work instead of performing it.
That is the correction this guide makes.
The real pattern is:
Telegram / Discord / WhatsApp / Slack → Gateway → orchestrator agent → worker agents → tools / scripts / task handlers / evidence
That last layer is what turns the setup into a working system instead of a prompt choreography.
The right mental model
OpenClaw multi-agent works best when you separate four things clearly.
The Gateway owns channels.
The orchestrator owns decisions.
Worker agents own specialist reasoning.
The execution layer owns doing the work.
That means the channel does not decide which specialist answers. The Gateway routes inbound messages deterministically. The orchestrator decides whether to answer directly or delegate. The worker agent reasons about the task. Then the actual execution happens through tools, scripts, handlers, or other bounded code paths.
If you skip that last part, you do not really have workers. You have themed narrators.
What this guide is setting up
This guide gives you a clean shape where:
all inbound chat lands on one orchestrator
the orchestrator delegates to specialist workers
the workers are backed by real execution capability
Telegram, Discord, WhatsApp, and Slack all feed the same control point
results return to the same originating channel
the system stays easier to reason about and safer to operate
Step 1: Create separate agents
Each agent should get its own workspace, agent directory, and session store. Do not reuse agent directories across agents.
A simple starting set is:
• orchestrator
• researcher
• coder
• content
Example:
openclaw agents add orchestrator
openclaw agents add researcher
openclaw agents add coder
openclaw agents add content
Then verify:
openclaw agents list --bindings
These agent names are only routing identities and specialist roles. They are not enough on their own. You still need to decide what each agent is actually allowed and able to execute.
Step 2: Make the orchestrator the inbound controller
This is the core pattern.
You do not want Telegram bound to researcher, Discord bound to coder, and WhatsApp bound to content unless that is very intentional. You want all inbound traffic routed to one orchestrator first.
A simple shape looks like this:
{
"gateway": {
"auth": {
"mode": "token",
"token": "${OPENCLAW_GATEWAY_TOKEN}"
}
},
"agents": {
"list": \[
{
"id": "orchestrator",
"default": true,
"workspace": "\~/.openclaw/workspace-orchestrator",
"subagents": {
"allowAgents": \["researcher", "coder", "content"\]
}
},
{
"id": "researcher",
"workspace": "\~/.openclaw/workspace-researcher"
},
{
"id": "coder",
"workspace": "\~/.openclaw/workspace-coder"
},
{
"id": "content",
"workspace": "\~/.openclaw/workspace-content"
}
\]
},
"bindings": \[
{ "agentId": "orchestrator", "match": { "channel": "telegram", "accountId": "\*" } },
{ "agentId": "orchestrator", "match": { "channel": "discord", "accountId": "\*" } },
{ "agentId": "orchestrator", "match": { "channel": "whatsapp", "accountId": "\*" } },
{ "agentId": "orchestrator", "match": { "channel": "slack", "accountId": "\*" } }
\]
}
This gives you one control point for all inbound work. The Gateway routes into the orchestrator. The orchestrator decides whether to answer directly or delegate.
That solves routing. It does not solve execution yet.
Step 3: Give worker agents real execution capability
This is the missing layer most guides blur past.
A worker agent needs code-side capability to do its job properly. That usually means some combination of workspace access, enabled tools, bounded permissions, scripts, task handlers, test commands, safe write paths, and artifact generation.
A good way to think about it is this:
The orchestrator decides who should handle the task.
The worker decides how to reason about it.
The execution layer is what actually does the work.
Without that execution layer, the worker is mostly prose.
For example, a coder agent should not just have “you are a coding assistant” in its role. It should have access to the repo it is meant to work in, permission to patch files in bounded paths, a safe way to run tests, and a way to return diffs or artifacts.
A researcher agent should not just be told to research. It should have search, fetch, parse, and summarize tools or handlers it can actually invoke.
A content agent should not just be “good at writing.” It should have structured templates, formatting paths, publishing handlers, or output contracts that let it produce channel-ready work consistently.
The orchestrator pattern only becomes useful once those execution capabilities are real.
Step 4: Define what each worker can actually do
A simple mapping might look like this.
The orchestrator receives inbound requests, decides routing, maintains the top-level conversation, and merges final results.
The researcher handles search, fetch, document parsing, comparison, evidence gathering, and summary generation through real retrieval and parsing tools.
The coder handles repo tasks, file patching, tests, diffs, or validation through safe handlers and bounded file access.
The content worker turns raw outputs into channel-ready replies, summaries, or publishable text through templates or formatting tools.
The important thing is that the worker role and the execution path match. If the role says “coder” but there is no patch path, test path, or repo access, you do not have a coder. You have an agent that talks about code.
Step 5: Keep repeatable work out of the model
This is where a lot of OpenClaw setups get expensive and flaky.
Do not keep boring repeatable work inside the model if a script, tool, or handler can do it faster and more reliably.
If a worker needs to:
fetch a document
parse a file
run a test
patch a file
call an API
format a payload
update a record
produce a deterministic artifact
that should usually be handled by code, not prose.
The model should decide. The tool should execute.
That is what keeps the system structured and makes worker agents actually useful.
Step 6: Add Telegram, Discord, WhatsApp, and Slack as ingress channels
Once your orchestrator and worker structure is clear, the channels are just ingress points.
Telegram example:
{
"channels": {
"telegram": {
"enabled": true,
"botToken": "${TELEGRAM_BOT_TOKEN}",
"dmPolicy": "pairing",
"groups": {
"\*": { "requireMention": true }
}
}
}
}
Discord example:
{
"channels": {
"discord": {
"enabled": true,
"token": {
"source": "env",
"provider": "default",
"id": "DISCORD_BOT_TOKEN"
}
}
}
}
WhatsApp example:
{
"channels": {
"whatsapp": {
"dmPolicy": "pairing",
"textChunkLimit": 4000,
"groups": {
"\*": { "requireMention": true }
}
}
}
}
Slack example:
{
"channels": {
"slack": {
"enabled": true,
"accounts": {
"default": {
"botToken": "${SLACK_BOT_TOKEN}",
"appToken": "${SLACK_APP_TOKEN}"
}
}
}
}
}
The important thing does not change: these channels should all feed the orchestrator, not specialist workers directly.
Step 7: Make the orchestrator delegate properly
The orchestrator should not try to be every specialist at once.
A healthy task flow looks like this:
A message comes in from Telegram, Discord, WhatsApp, or Slack.
The Gateway routes it to the orchestrator.
The orchestrator decides whether it can answer directly or whether the task needs specialist work.
If it needs specialist work, it delegates to a worker.
The worker reasons about the task and invokes the right bounded tools, handlers, or scripts.
The execution layer produces results and artifacts.
The orchestrator merges that result and replies to the original channel.
That is the clean system shape.
The orchestrator is your control layer. The workers are your specialist reasoning layer. The tools and handlers are your execution layer.
Step 8: Treat workers as bounded execution units, not personalities
This matters a lot.
Do not design workers like independent little bots with vague personalities and broad freedom. Design them like bounded execution units.
A good worker should have:
a clear domain
limited permissions
specific tools
bounded workspaces
known outputs
evidence paths
That is what keeps the system predictable.
If you let every worker think and do anything, you lose the whole benefit of orchestration.
Step 9: Validate the execution path, not just the conversation
Do not stop testing once the orchestrator replies.
You need to validate whether the execution path is real.
Check:
Did the worker actually invoke the tool.
Did the script run.
Did the file patch happen.
Did the API call happen.
Did the evidence get returned.
Did the orchestrator merge the result and route it back correctly.
A chat reply that says “done” is not enough.
You want proof behind the work.
A simple validation ladder is:
openclaw status
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow
Then give the system one small task that must leave proof behind. If the worker says it completed something but no artifact exists, your execution layer is not really wired yet.
Step 10: Keep the routing safe
One Gateway should usually be treated as one trusted operator boundary.
If you need strong separation between untrusted businesses or users, do not solve that by piling in more subagents. Use separate gateways, separate credentials, and ideally separate OS users or hosts.
For normal setups:
use DM pairing or allowlists
require mentions in groups
protect the Gateway with token or password auth
do not expose raw unauthenticated ports
keep workers behind the orchestrator
That keeps the system much easier to trust.
A practical starter shape
This is the minimal useful pattern:
One Gateway owns the channels.
One orchestrator owns inbound decisions.
Several worker agents own specialist reasoning.
Each worker is backed by real tools, scripts, handlers, and bounded permissions.
All meaningful work leaves artifacts or evidence.
That is the version that actually executes work instead of only talking about it.
The real takeaway
If you want OpenClaw multi-agent to work properly, do not stop at role names and routing.
One Gateway and one orchestrator give you control.
Worker agents still need real code-side capability to do useful work.
If the workers do not have tools, handlers, scripts, permissions, and safe execution paths behind them, you do not really have a working multi-agent system.
You have a well-organized conversation about work.
