Multi-Agent, Day 15 of the Free Comprehensive OpenClaw Course

How do I run multiple OpenClaw agents at once?

OpenClaw multi-agent is the pattern that scales a single agent into a team. The shape: one gateway process accepts incoming messages from your channels, looks at who sent them and what they are about, and routes the message to the right specialist agent. Each specialist has its own SOUL.md, MEMORY.md, AGENTS.md, and tool grants. They share nothing by default.

The minimum viable setup is two agents and a gateway. Most production deployments end up with three to seven agents. More than that and you should ask whether you really need separate agents or whether you should be using sub-agents inside one richer agent.

The gateway lives in its own folder with a routing config. The routing config picks the right agent based on channel (Slack vs Telegram vs WebChat), sender (the founder vs the team vs a customer), or content (a tag in the message, a prefix, the topic detected by a small classifier). Routing rules are evaluated top to bottom, first match wins.

Multi-agent architecture patterns that work

Three architecture patterns I see in production. The first, role-based split. One agent per real-world role: a "founder assistant" agent that knows the business, an "ops monitor" agent that watches systems, a "customer support" agent that handles inbound from end users. Each agent has a focused MEMORY.md and a narrow tool grant. Routing is by sender or by channel.

The second, capability-based split. One agent per major capability: a "writer" agent that drafts content, a "researcher" agent that gathers information, a "coder" agent that ships PRs. Routing is by intent, the gateway looks at the message and decides which capability is needed. Often paired with a "dispatcher" agent that triages incoming messages and forwards to the right specialist.

The third, tier-based split. A cheap small "front" agent that handles 80 percent of routine traffic and a smart big "back" agent that handles the hard 20 percent. The front agent decides whether to handle the message itself or escalate to the back agent. This is the pattern from openclaw cost optimization on day 4, applied at the agent level rather than the prompt level. Cuts cost dramatically for support-style workloads with a long tail of routine queries.

Example gateway routing config

A real routing config for a three-agent setup, in the gateway's config.yaml:

routing:
  rules:
    # Anything from the founder's Telegram, route to the assistant
    - if:
        channel: telegram
        sender_username: "@founder_handle"
      route_to: founder-assistant

    # Anything in the #ops Slack channel, route to the monitor
    - if:
        channel: slack
        slack_channel: "#ops"
      route_to: ops-monitor

    # Anything from external Slack DM (customer support inbound)
    - if:
        channel: slack
        sender_is_external: true
      route_to: customer-support

    # Default: route to founder assistant
    - default: founder-assistant

  internal_channels:
    - name: agent-bus
      members: [founder-assistant, ops-monitor, customer-support]
      rate_limit: 60_per_minute

The gateway evaluates the rules top to bottom, first match wins. The internal channel "agent-bus" is the path agents use to delegate work to each other. Rate limiting on the internal channel prevents the runaway delegation loops described later.

How do agents talk to each other in OpenClaw?

Through scoped channels, never through the same channels users use. The pattern: the gateway sets up an internal channel that only specialist agents can write to. When the planner needs the executor to do something, the planner posts to the internal channel, the executor reads it, the executor posts the result back. The user never sees the internal channel.

The reason this is its own pattern (rather than just "have agents call each other directly") is the audit trail. Every agent-to-agent message is a normal channel message in the runtime's logs. You can read it, you can replay it, you can debug a chain of delegation by reading the channel history. Direct calls would be invisible.

The other thing the channel pattern gives you is rate limiting. If the planner goes into a loop and posts 200 messages a second to the executor, the gateway's rate limiter on the internal channel catches it. Direct calls would just spin until something else broke.

When should I split work across agents instead of using sub-agents?

Sub-agents (openclaw agents.md) are spawned by a parent agent for a single task and torn down when the task is done. Specialist agents in a multi-agent setup are long-running, they have their own memory, their own personality, their own continuous existence.

The rule of thumb. If the work is one-off ("plan this feature", "research this question"), use a sub-agent inside the parent. If the work is a continuous role ("the customer support agent", "the email triage agent"), use a separate specialist. Sub-agents are cheaper to spin up and harder to coordinate, specialists are more expensive to run continuously and easier to reason about.

The other deciding factor is memory. Specialists need durable, separate memory because they are long-running. Sub-agents inherit context from the parent and discard it when done. If the work needs a separate memory that survives the task, it is a specialist. If the work just needs the parent's context for one task, it is a sub-agent.

Agent coordination examples, the patterns that hold up

Three coordination patterns that work in real deployments. Request-response delegation. Agent A needs something Agent B can do, posts a structured request to the agent-bus channel addressed to B, waits for B's reply on the same channel. Simple, debuggable, the canonical default. Use for "founder assistant needs the ops monitor to confirm deploy status".

The second, broadcast-and-aggregate. A coordinator agent posts a question to multiple specialists, collects all the replies, synthesises an answer for the user. Useful when the user's question genuinely needs multiple perspectives, "what should we do about the security incident" might want input from the ops, security, and founder agents simultaneously.

The third, handoff with context. Agent A is mid-conversation with the user but realises Agent B is better suited to continue. Posts a handoff message to the user channel ("transferring you to our customer-support specialist") plus a context summary to the agent-bus, B picks up the conversation in the user channel. Common in customer-support deployments where the front agent triages and the specialist resolves.

Per-agent isolation

The whole point of multi-agent is that each agent has its own permissions, memory, and tool grants. A compromised customer-support specialist cannot read the founder-assistant's MEMORY.md. The sandbox is at the runtime level, not at the prompt level, no amount of prompt injection can break it.

The default isolation is strict. Each agent's workspace is its own folder, the gateway has no shared filesystem with the specialists, the specialists have no shared filesystem with each other. Channels are the only communication path, and channels go through the rate-limited gateway. If you want to relax isolation (a shared knowledge base, for example), you do it deliberately by mounting a read-only volume into multiple agents.

Multi-agent failure modes

Three failures that show up in real deployments. The first, delegation loops. Agent A asks Agent B for something, B asks A for clarification, A asks B for clarification, the loop never terminates. Mitigation: the gateway tracks delegation depth, refuses any new delegation past depth 5, surfaces the loop to the user for resolution.

The second, routing rule conflicts. Two rules both match a message, the first-match-wins ordering picks the wrong one. The user's message goes to the wrong specialist, the wrong specialist gives the wrong answer. Mitigation: read the routing rules out loud during setup, walk through five real example messages and confirm each routes where you expected.

The third, cost concentration on one agent. One specialist gets 90 percent of the traffic, blowing past its spending cap, while the other agents sit idle. Mitigation: monitor per-agent spending separately, alert on imbalance, consider whether the busy agent should be split into two or whether the routing should be adjusted.

When multi-agent is overkill

The honest case against splitting. Most personal-agent users do not need multi-agent. One well-tuned agent with a good MEMORY.md, a focused SOUL.md, and a few sub-agents for specific delegable tasks (research, planning, coding) handles 90 percent of the use cases. Multi-agent adds operational complexity, cost concentration risk, and a coordination layer that itself can fail.

The signs you are not yet ready for multi-agent. You have not yet hit a real conflict between two roles in your one agent. You have not yet wished you could keep two memory contexts strictly separate. You have not yet had a moment where you wanted "this person should not be able to ask the agent about that". If none of those are true, stay on one agent.

The signs you are ready. You catch yourself constantly switching the agent's persona between contexts. You have customer-facing traffic that should not see your private memory. You have multiple humans using the agent and they should not see each other's history. Now multi-agent earns its complexity.

How this connects to your full agent

Multi-agent is the most advanced pattern in the runtime. Most personal-agent users never need it, one well-tuned agent does the job. The pattern starts to matter when you have multiple distinct roles (founder plus team plus customers) or multiple distinct capabilities (writing plus research plus coding) that benefit from separate memory and separate permissions.

The dependencies are heavy. Openclaw agents.md on day 9 (each agent needs its own gates), openclaw vps deployment on day 13 (multi-agent typically wants more than a $5 VPS), openclaw docker on day 12 (each agent in its own container is the canonical isolation). Get those in place before splitting one agent into many.