OpenClaw Slack Multi-Agent Playbook

When To Use This Skill

Activate this page when the user wants a real OpenClaw multi-agent setup on Slack, not just a conceptual explanation. The default example team is one orchestrating main agent plus three specialists: research, coding, and product-manager.

Use it when

The task is to generate agent config, create workspaces, bind Slack, verify the gateway, and teach the user how to dispatch work with sessions_spawn.

Do not use it when

The user only wants a single-agent setup, only wants architecture advice, or already has a working setup and merely needs a narrow fix. In those cases, audit first before proposing structural edits.

Default team shape

main owns Slack and delegation. research gathers evidence. coding implements and verifies. product-manager turns requests into scope, milestones, and acceptance criteria. Keep technical agent ids role-based; use IDENTITY.md for optional human-facing names and persona traits.

Execution Contract

These rules are mandatory. Treat them as the operating contract for any agent using this page.

Ask about the user’s real agent roles before generating config.
Back up ~/.openclaw/openclaw.json before modifying it.
Cross-check every operational instruction against official OpenClaw docs.
Confirm each phase before execution rather than applying all changes at once.
Do not invent undocumented commands, bindings, or Slack behavior.
Treat Slack tokens and signing secrets as sensitive. Prefer local configuration steps over asking the user to paste secrets into chat.
Keep agent ids stable and role-based. Put optional persona names and characteristics into IDENTITY.md, not into core routing ids.
Whenever main should delegate to named specialists, configure subagents.allowAgents explicitly.
Prefer OpenClaw commands and the configuration wizard over manual edits to openclaw.json. Only edit files directly when there is no clean command path.

Operator Boundaries

Separate user input, agent actions, and Slack-side confirmation clearly. This keeps the runbook executable instead of conversationally vague.

Ask

What the agent must ask the user first

Ask about the desired roles, Slack mode, routing pattern, secret-handling preference, optional persona names, and any Slack destination preferences for the verification greeting that cannot be inferred locally.

Run

What the agent should do directly

Use commands for local discovery, agent creation, bindings, validation, health checks, and outbound greeting tests. Infer existing setup state locally instead of asking the user when that information is already on disk. Write workspace files directly when needed. Avoid hand-editing config if openclaw configure or config commands can express the change.

Confirm

What the user must verify in Slack

The user should confirm whether the greeting message arrived in the expected Slack destination and whether the agent’s identity response matches the intended role and persona.

Decision Rules

The page supports two Slack routing patterns. The choice should be explicit, not implicit.

Option A

Choose this when simplicity matters most

Use a single Slack app or account bound to main when the user wants the easiest setup and one public-facing bot. If the user is unsure, recommend this first. In this path, main still needs an explicit subagents.allowAgents list if it should delegate to specialists.

Option B

Choose this when specialists must be directly reachable

Use multiple Slack accounts only when the user wants direct routing to specialists. In HTTP mode, every account must have a unique webhookPath.

If unsure

Default recommendation

Start with Option A, verify the agent boundaries and workflow, and move to Option B only if the user needs specialist agents to be addressed directly in Slack.

Phase 1: Intake

Do not write config first. Start by collecting the minimum information needed to choose a topology and assign roles correctly.

Ask how many agents the user wants and what each one should do.
Ask whether the user wants one public Slack bot or direct access to specialists.
Ask whether they want Slack Socket Mode or HTTP Events API mode.
Ask whether they are willing to provide Slack credentials directly, or prefer to configure them locally with commands.
Ask whether they want optional human-facing agent names or persona traits for Slack presentation.
If the verification destination cannot be inferred from the configured Slack routing, ask which Slack destination should receive the outbound greeting test.
Confirm the final role list, Slack mode, secret-handling path, any required verification destination, and any optional persona names before moving to config generation.

Phase 2: Choose Routing Pattern

Once the intake is complete, make the routing choice explicit and explain why.

Choose Option A for one Slack app/account routed to main.
Choose Option B for multiple Slack accounts with distinct accountId values.
Choose Socket Mode when the gateway is not exposed over HTTPS and the user can configure appToken plus botToken.
Choose HTTP mode when Slack can reach the gateway over HTTPS. HTTP mode needs botToken, signingSecret, and Slack Request URLs that match the configured webhookPath.
If Option B uses HTTP mode, assign a unique webhookPath to every Slack account.
Confirm the chosen routing pattern before editing any config.

Phase 3: Generate Config

Back up config first, then generate the agent list and binding-related config for the chosen routing pattern.

Credential intake

Ask for the right Slack secrets only after mode selection

Socket Mode requires xapp-... app token plus xoxb-... bot token. HTTP mode requires xoxb-... bot token plus Slack signing secret. If the user does not want to paste secrets into chat, instruct them to use local configuration commands or the interactive openclaw configure wizard instead.

Command first

Use commands before touching config files

First try openclaw configure --section channels, openclaw agents add, openclaw agents bind, and config CLI commands. Only patch ~/.openclaw/openclaw.json when the needed setting cannot be expressed safely through the CLI.

Delegation allowlist

Do not assume main can target other agents automatically

If main needs to delegate to research, coding, or product-manager, add them to main.subagents.allowAgents. Without that allowlist, the delegation path may not be available even if the agents exist.

Naming

Keep ids functional, make persona names optional

Use role-based ids such as research and coding in config, bindings, and session routing. If the user wants names like Grace or Alice, store those as display identity in IDENTITY.md together with tone, biography, and persona traits.

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak
openclaw agents list
openclaw configure --section channels
openclaw agents add research --workspace ~/.openclaw/workspace-research
openclaw agents add coding --workspace ~/.openclaw/workspace-coding
openclaw agents add product-manager --workspace ~/.openclaw/workspace-product-manager
openclaw agents bindings
openclaw config validate
openclaw status
openclaw channels status --probe

Option A

Single Slack app/account

openclaw agents bind --agent main --bind slack
openclaw agents bindings --agent main

// openclaw.json
{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["research", "coding", "product-manager"],
        },
      },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coding", workspace: "~/.openclaw/workspace-coding" },
      { id: "product-manager", workspace: "~/.openclaw/workspace-product-manager" },
    ],
  },
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: "xapp-...",
      botToken: "xoxb-...",
    },
  },
}

HTTP variant

Single Slack app/account over HTTPS

openclaw agents bind --agent main --bind slack
openclaw agents bindings --agent main

// openclaw.json
{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["research", "coding", "product-manager"],
        },
      },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coding", workspace: "~/.openclaw/workspace-coding" },
      { id: "product-manager", workspace: "~/.openclaw/workspace-product-manager" },
    ],
  },
  channels: {
    slack: {
      enabled: true,
      mode: "http",
      botToken: "xoxb-...",
      signingSecret: "your-signing-secret",
      webhookPath: "/slack/events",
    },
  },
}

Option B

Multiple Slack accounts

openclaw agents bind --agent research --bind slack:research
openclaw agents bind --agent coding --bind slack:coding
openclaw agents bind --agent product-manager --bind slack:pm
openclaw agents bindings

// openclaw.json
{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["research", "coding", "product-manager"],
        },
      },
      { id: "research", workspace: "~/.openclaw/workspace-research" },
      { id: "coding", workspace: "~/.openclaw/workspace-coding" },
      { id: "product-manager", workspace: "~/.openclaw/workspace-product-manager" },
    ],
  },
  channels: {
    slack: {
      enabled: true,
      mode: "http",
      accounts: {
        default: {
          webhookPath: "/slack/main/events",
        },
        research: {
          webhookPath: "/slack/research/events",
        },
        coding: {
          webhookPath: "/slack/coding/events",
        },
        pm: {
          webhookPath: "/slack/pm/events",
        },
      },
    },
  },
}

Phase 4: Create Workspaces

Generate role-specific workspace instructions after the role list is confirmed. Keep them narrow so each agent has a clear boundary. If the user wants persona naming, capture it in IDENTITY.md.

Writing AGENTS.md, SOUL.md, and optional IDENTITY.md is a direct file-edit step. This is the normal place to write those artifacts; do not wait for a config command that does not exist.

# ~/.openclaw/workspace-research/AGENTS.md
You are the research agent.
- Prioritize official docs, primary sources, and dated evidence.
- Return concise findings with source links and explicit uncertainty.
- Do not modify code unless the task explicitly requires repository edits and the caller asked for implementation support.

# ~/.openclaw/workspace-coding/AGENTS.md
You are the coding agent.
- Focus on implementation, debugging, tests, and verification.
- Be explicit about files changed, commands run, and remaining risks.
- Escalate product or scope questions back to the requester instead of inventing requirements.

# ~/.openclaw/workspace-product-manager/AGENTS.md
You are the product manager agent.
- Turn goals into scope, milestones, tradeoffs, and acceptance criteria.
- Clarify ambiguities before coding starts.
- Produce handoff-ready plans for the coding and research agents.

# Example SOUL.md for specialists
Tone: direct, concise, evidence-driven.
Boundary: stay inside your specialty and hand back when another role should decide.

# Optional IDENTITY.md
Name: Grace
Role: research
Voice: calm, precise, evidence-driven
Traits:
- concise
- rigorous
- trustworthy
Purpose: Present the research agent as a human-friendly Slack persona without changing the technical agent id.

Phase 5: Bind Slack

Apply the chosen binding strategy and explain the resulting traffic pattern to the user.

For Option A, bind Slack to main and keep delegation behind the scenes.
For Option B, bind each relevant specialist with slack:<accountId>.
When main should orchestrate specialists, set main.subagents.allowAgents to the exact ids it may target.
For Socket Mode, guide the user through Slack app setup for appToken and botToken.
For HTTP mode, guide the user through Slack app setup for botToken, signingSecret, and matching Request URLs for Events, Interactivity, and Slash Commands.
If using multiple Slack accounts, make the auth model explicit: which account entries share one Slack app context and which require distinct Slack apps, tokens, or request URLs.
Run openclaw agents bindings after changes and confirm the effective map.
Explain that Slack guidance should stay within documented behavior.

Phase 6: Verify

Do not claim completion before validation, binding inspection, and channel health checks are complete.

# Doc-backed infrastructure checks
openclaw agents bindings
openclaw config validate
openclaw status
openclaw channels status --probe

# Outbound Slack smoke test
openclaw message send --channel slack --target channel:<CHANNEL_ID> --message "Hello from OpenClaw. Slack delivery test."

# Behavioral smoke test for a newly created agent
# Ask in the relevant Slack chat or routed thread:
Who are you? State your role, boundaries, and when you should delegate.

# Delegation smoke test
# Ask main to delegate to an allowed specialist and confirm the specialist is targetable.

Secret handling

If the user did not want to paste Slack secrets into chat, confirm they were instructed to configure them locally with openclaw configure, config commands, or environment variables.
Do not echo tokens or secrets back into the chat transcript.

Routing and config

Run openclaw agents bindings and confirm every Slack target is mapped where you expect.
Run openclaw config validate before testing inbound traffic.
Use openclaw status to confirm multi-agent session stores are visible.
Verify that main can actually see and target the specialist ids allowed by subagents.allowAgents.

Slack health

Run openclaw channels status --probe for live channel probing.
Send a simple greeting with openclaw message send --channel slack --target ... to verify outbound Slack delivery.
If using multiple Slack accounts in HTTP mode, verify every account has a unique webhookPath.
Remember that most config changes hot-apply, but restart behavior still depends on your reload mode.

Behavioral smoke tests

Ask each newly created agent a simple identity question such as Who are you? State your role, boundaries, and when you should delegate.
Confirm the answer matches the intended role and the workspace instructions in AGENTS.md, SOUL.md, and optional IDENTITY.md.
For directly routed specialist agents, run the prompt in each routed Slack destination. For Option A, ask main to delegate and confirm the result comes back correctly.
Confirm the delegated specialist is one of the ids explicitly allowed under main.subagents.allowAgents.

User confirmations

Have the user confirm that the greeting message arrived in the intended Slack channel, DM, or specialist destination.
Have the user confirm that the visible persona, name, and role behavior match expectations in Slack.

Phase 7: Teach Dispatch

End by teaching the user how to ask main for delegated work in natural language. The user should not need to type tool-shaped payloads. The structured form below is an internal implementation pattern for the agent, not a required user input format.

User-facing natural-language examples:

- "Research the current OpenClaw Slack multi-account requirements and summarize the setup differences for me."
- "Ask the coding agent to implement the approved change and report back with files changed and tests run."
- "Have the product manager agent turn this request into scope, decision points, and acceptance criteria."

Internal agent pattern (not something the user needs to type):

// research pass
sessions_spawn({
  agentId: "research",
  task: "Find the current OpenClaw Slack multi-account requirements. Use official docs first and summarize only the parts relevant to webhook paths, account routing, and bindings.",
})

// coding pass
sessions_spawn({
  agentId: "coding",
  task: "Implement the approved change in the target repo. Return files changed, tests run, and any residual risks.",
})

// product manager pass
sessions_spawn({
  agentId: "product-manager",
  task: "Turn the user's request into scope, decision points, and acceptance criteria before implementation starts.",
})

Teach the user to speak to main in normal task language. The agent decides when to call sessions_spawn behind the scenes and then returns the result in normal assistant voice.

Outputs

A complete run of this skill should end with concrete artifacts, not just advice.

A backup path for the original openclaw.json.
A generated agents.list and any required Slack channel config.
A clear record of whether the user chose Socket Mode or HTTP mode, and which secrets are required for that path.
Created workspace paths for each agent.
Generated AGENTS.md, SOUL.md, and optional IDENTITY.md content for any user-provided names or persona traits.
A generated subagents.allowAgents policy for main when delegation is required.
Binding commands and the verified effective bindings map.
A passed outbound Slack greeting test and a basic identity-response smoke test for the configured agents.
A recorded user confirmation that the Slack-side greeting and persona behavior looked correct.
Validation and health-check results.
At least one natural-language delegation example for the user, plus an internal sessions_spawn pattern for implementation reference.

Self-Review Checklist

Before finishing, review the run against this checklist.

Did you ask about the user’s real agent roles before generating config?
Did you ask whether the user wanted Socket Mode or HTTP mode?
Did you handle Slack secrets safely instead of encouraging plaintext token sharing?
Did you keep technical ids role-based and move optional names into IDENTITY.md?
Did you configure main.subagents.allowAgents whenever main is supposed to delegate?
Did you back up openclaw.json before editing it?
Did you explicitly choose Option A or Option B?
Did you avoid undocumented commands or Slack behavior?
Did you verify both outbound Slack delivery and a simple identity response from the configured agents?
Did you run validation, binding inspection, and health checks?
Did you teach the user how to ask main in natural language, instead of requiring tool-shaped input?

References

These references support the operational steps above. Keep them as backing material, not as a substitute for the execution contract and phase flow.

Slack multi-agent skill for OpenClaw setup, routing, and delegation

Copy Prompt