How to Run Multiple OpenClaw Agents as Slack Teammates

One Bot Is Not Enough

At some point, a single OpenClaw bot in Slack starts feeling like a Swiss Army knife you're using to build a house. It can do everything but it's doing too many things. Your sales team wants it to track deals and draft follow-ups. Support wants it to triage tickets and pull customer context. Engineering wants it to manage PRs and run standups. The bot's SOUL.md becomes a contradictory mess of competing instructions.

The better approach: run multiple agents, each with its own personality, skills, and channel scope. Think of them as Slack teammates who happen to be AI. A sales bot that lives in your sales channels. A support bot in your support channels. An ops bot watching your infrastructure channels. Each one tuned for its job.

How This Works Technically

Each agent is a separate OpenClaw instance with its own Slack app. Yes, that means creating multiple Slack apps. It sounds like a pain, and it kind of is, but it's the cleanest architecture. Here's why: each Slack app gets its own bot user, its own avatar, its own name. When your sales bot posts in #deals, it shows up as "SalesBot" with a green avatar. When your support bot posts in #support-escalations, it shows up as "SupportBot" with a blue one. People know who they're talking to.

The setup for each agent follows the same process as a single agent (see our setup guide). The key difference is that each agent gets its own:

• Slack app (with its own bot token and app token)
• OpenClaw instance (with its own config directory)
• SOUL.md file (defining its personality and purpose)
• Skills set (only the skills relevant to its role)
• Channel scope (only invited to relevant channels)

Configuring SOUL.md for Each Agent

SOUL.md is where OpenClaw gets its personality and instructions. For a single all-purpose bot, it's usually generic. For specialized agents, you want to be specific. Here's what a sales bot's SOUL.md might look like:

# Sales Agent - SOUL.md

You are SalesBot, the sales team's AI assistant.

## Your Role
- Track deal pipeline and update CRM (HubSpot)
- Draft follow-up emails after sales calls
- Pull customer data when asked
- Generate weekly pipeline reports

## What You Don't Do
- You don't handle support tickets (direct to @SupportBot)
- You don't manage code or deployments
- You don't access engineering channels

## Tone
- Professional but casual
- You can use sales jargon; the team speaks that language
- Be concise in channel messages, detailed in DMs

And here's a support bot's:

# Support Agent - SOUL.md

You are SupportBot, the customer support team's AI assistant.

## Your Role
- Triage incoming Zendesk tickets by priority
- Pull customer account info from Salesforce when asked
- Summarize customer interaction history
- Draft response templates for common issues
- Escalate urgent tickets to #support-escalations

## What You Don't Do
- You don't update sales pipeline data (direct to @SalesBot)
- You don't have access to engineering repos

## Tone
- Empathetic when discussing customer issues
- Direct when sharing ticket data
- Flag emotional customers explicitly

The "What You Don't Do" section matters. Without it, people will ask the wrong bot for help and get confused when it tries to do everything. Telling the agent its boundaries is just as important as telling it its job.

Running Multiple Instances

If you're running on a single server, you'll need each instance in its own directory with its own environment file. Something like:

/opt/openclaw/sales-bot/
  .env
  SOUL.md
  skills/
  MEMORY.md

/opt/openclaw/support-bot/
  .env
  SOUL.md
  skills/
  MEMORY.md

/opt/openclaw/ops-bot/
  .env
  SOUL.md
  skills/
  MEMORY.md

Each .env has its own Slack tokens, its own API keys for connected services, and its own OpenClaw configuration. Start each one as a separate process:

cd /opt/openclaw/sales-bot && openclaw start --slack &
cd /opt/openclaw/support-bot && openclaw start --slack &
cd /opt/openclaw/ops-bot && openclaw start --slack &

In production, use a process manager like systemd or PM2 to keep them running and restart on failures. Docker Compose is even better; each agent gets its own container. We'll cover Docker setups in more detail in our Docker deployment guide.

Resource Considerations

Each OpenClaw instance uses roughly 200-400MB of RAM depending on how many skills are loaded and how active the conversation context is. Three agents on a 2GB VPS will work but you'll be tight. Budget about 512MB per agent and you'll be comfortable.

CPU usage is mostly idle with spikes when the agent is processing a message or running a skill. A 2-core VPS handles three agents fine for a team of up to 50 people. Beyond that, you probably want dedicated hardware per agent.

Cross-Agent Communication

Here's where it gets interesting. Your agents can talk to each other through Slack. When SalesBot encounters a support question, it can tag @SupportBot in a message. SupportBot sees the mention, picks it up, and handles it. To the people in the channel, it looks like two teammates handing off work.

This requires that each agent's SOUL.md knows about the other agents and when to hand off. Don't skip this part. Without clear handoff instructions, agents will either try to handle everything themselves or get into weird loops where they keep tagging each other.

One thing to watch out for: make sure agents don't trigger each other in loops. If SalesBot is configured to respond to any @mention in #sales, and SupportBot tags SalesBot in #sales, SalesBot will respond, which could trigger SupportBot again. Add explicit rules: "Don't respond to messages from other bots" or "Only respond when tagged by a human."

When This Makes Sense

Multi-agent setups make sense when you have at least three distinct teams using OpenClaw for different purposes and the overlap is causing confusion. For smaller teams (under 20 people), a single well-configured bot is usually fine.

If managing multiple OpenClaw instances sounds like too much overhead (and honestly, it is a lot of overhead), SlackClaw supports multi-agent configurations out of the box. You define personas in the dashboard, assign channels, and the platform handles the infrastructure. Same concept, less ops work. Check our integrations page to see which tools each agent can connect to.