OpenClaw Multi-Agent: How I Set Up My Second Agent

After the initial setup, OpenClaw gives you one agent.

In my setup, that first agent is main: the default top-level OpenClaw agent that talks to me directly in Slack and acts as the orchestrator for everything else.

That agent is useful, but it is still just one generalist. If I wanted a real multi-agent setup, I needed main to do two things reliably:

know which specialist exists
know when to delegate

This note is the second part of my OpenClaw setup.

The first part was getting the system online at all. This part was about turning it into a team.

1. Start by teaching OpenClaw how to create a team

I did not want to freestyle the setup from memory.

So I first pointed OpenClaw at a playbook:

Original reference: cmcm.bot multi-agent guide
My version: OpenClaw multi-agent playbook

Then I gave main a detailed prompt telling it to guide the whole process.

Please help me configure a multi-agent team in OpenClaw.

Reference page:
- Setup guide: <https://playbooks.withus.fun/openclaw-multi-agent>

Please guide me through these steps:

1. First ask me how many agent roles I want and what each one should do.
2. Ask whether I want Slack Socket Mode or HTTP Events API mode.
3. Ask whether I want to provide Slack credentials in chat or configure them locally myself.
4. Ask whether I want optional human-facing names or persona traits for any agent.
5. Based on my answer, generate the agents.list configuration for ~/.openclaw/openclaw.json.
   - If main should delegate to specialist agents, include main.subagents.allowAgents with the exact allowed agent ids.
6. Create a workspace directory for each agent and generate SOUL.md and AGENTS.md for each one, adding IDENTITY.md when needed.
7. Configure Slack bindings and give me two options:
   - Option A: a single Slack app/account bound to main, with main delegating through sessions_spawn to research, coding, and product-manager.
   - Option B: multiple Slack accounts, each with its own accountId and, when using HTTP mode, its own unique webhookPath, bound to specialist agents as needed.
8. Back up openclaw.json before changing it, then run config validate, reload or restart Gateway if needed, and verify health.
9. Finally, teach me how to ask main to delegate work in natural language, and only mention sessions_spawn as the internal mechanism the agent may use behind the scenes.

Important requirements:
- Use Slack as the example.
- Cross-check every instruction against the official OpenClaw documentation before telling me to do it.
- Do not apply sample config blindly. Ask about my actual setup first.
- Confirm each step before executing it.
- Explain which Slack secrets are required for the chosen mode:
  - Socket Mode: app token and bot token.
  - HTTP mode: bot token and signing secret.
- If I do not want to paste secrets into chat, tell me how to configure them locally with openclaw configure or equivalent local commands instead.
- Keep technical agent ids role-based. If I provide names like Grace or Alice, write them and any persona traits into IDENTITY.md instead of replacing ids like research or coding.
- Do not require me to type tool-shaped payloads. User-facing examples should be normal language directed to main.
- Do not assume delegation works automatically. If main needs to orchestrate specialists, configure subagents.allowAgents explicitly.

Please start guiding me now.

The important part here was not just “create more agents.”

It was forcing main to ask about the real setup first, keep role ids technical, configure subagents.allowAgents explicitly, and keep the user-facing workflow in normal language instead of internal tool syntax.

2. For the first pass, only create one subagent

For a first real setup, I think one subagent is enough.

I created only one specialist:

coding

I also kept the channel setup simple:

one Slack app
one Slack account
one Slack channel

That matters because it keeps the routing model obvious. I talk to main, and main decides whether the work should stay local or be handed to the coding specialist behind the scenes.

If I had started by creating five or six agents at once, I would have made the system harder to debug before I even knew whether delegation worked.

3. Give the specialist a real identity

In my case, the coding agent was named Kane.

If you do this yourself, do not stop at the config file. Go look directly inside ~/.openclaw/workspace-coding/.

That workspace is where the agent is actually defined in practice. Files like SOUL.md, AGENTS.md, and IDENTITY.md tell the specialist who it is, how it should behave, and how it fits into the team.

This was the content of IDENTITY.md after creation:

# IDENTITY.md - Who Am I?

- **Name:** Kane
- **Creature:** AI coding assistant
- **Vibe:** detail-oriented, quality-focused, precise
- **Emoji:** 🧑‍💻
- **Avatar:**

---

This is the coding agent. When asked, state your role clearly:
- You are Kane, the coding specialist
- You focus on implementation, debugging, testing, and code quality
- You refactor your own code to ensure maintainability
- You should be called through main (the orchestrator), not directly

This is a small file, but it does real work.

It tells the specialist what it is for, what kind of tone to use, and how it fits into the team. The last line is especially important: Kane should be called through main, not treated like a separate public-facing bot.

That keeps the team shape clean.

4. Teach `main` when to use the new agent

Creating a subagent is not enough.

The main agent also needs to remember both:

who the new agent is
when it should delegate to that agent

So I explicitly told main:

remember Kane is the coding agent, you can use `openclaw agents list` to get the roaster of all the agents

And then:

remember when I say something about Codex or programming, ask Kane to execute it

This was the real handoff point.

Without this step, you may have a perfectly configured specialist that almost never gets used. The main agent needs a simple routing rule it can actually apply in conversation.

For me, the routing rule was intentionally broad:

if the request is about Codex
or programming
then send it to Kane

That was enough to make the delegation behavior understandable and predictable.

5. A coding agent is only useful if its environment is ready

Once Kane existed, the next problem was obvious: a coding agent without a coding environment is mostly theater.

So I asked main to send setup work to the new agent:

refer to <https://github.com/obra/superpowers> and install superpowers skills in Codex

Then:

setup playwright MCP in Codex, install chromium as well

This was the first practical test of the team design.

If main understood the routing rule, it should use session_spawn internally, hand the job to the coding agent, and then come back with the result after the specialist finished the work.

That was the outcome I wanted to see:

main stays the orchestrator
Kane does the coding setup work
I do not need to manage the internal delegation mechanism manually

That is the point where “multi-agent” stops being a concept and starts being a workflow.

6. What I wanted to verify

At this stage, I was not trying to build a huge team.

I only wanted to prove a few things:

main can remember the existence and role of a specialist.
main can recognize the kinds of requests that belong to that specialist.
main can call the specialist through session_spawn.
The specialist can complete real setup work and return usable output.

If those four things work, then adding more agents later becomes a design problem instead of a trust problem.

7. Next agents: keep the team small

My current plan is still to keep the team fairly small, probably no more than six agents total.

The next roles I want are:

a research agent to follow trends and research focused topics
an operation agent to monitor websites and submit issues

Those roles feel different enough from coding that they justify their own specialists.

The coding path is about implementation and debugging.

The research path is about finding, comparing, summarizing, and tracking new information.

The operations path is about watching systems, noticing failures, and opening the right issue at the right time.

That separation matters because the best prompt, memory, and tool setup for each role is different.

8. I also need a shared backlog

Once there is more than one specialist, a bigger coordination problem appears.

Not every task should be handled immediately in chat.

Some tasks should be captured, prioritized, assigned, and revisited later. Some should be created by one agent and completed by another.

So I probably need a backlog system with a few basic properties:

all agents can read it
some agents can push new work into it
some agents can pull work from it
completion state is visible to the whole team

I do not think this needs to be complicated at first.

What matters is that the team has one shared queue instead of several hidden personal queues scattered across chats and memory files.

If I do this part well, the system becomes much more durable:

research can create new items
operations can file incidents
coding can pull implementation work
main can stay the front door and traffic controller

That feels like the next real milestone after basic delegation.

9. What I learned from the second note

The biggest lesson here is simple:

do not start by creating many agents. Start by making one delegation path real.

For me, that meant:

one main agent
one coding specialist
one Slack surface
one clear rule for when main should delegate
one real environment setup task to prove the handoff works

Once that works, adding research, operation, and a shared backlog makes sense.

Before that, more agents mostly create more confusion.

So this was my second OpenClaw milestone:

not just “I can run an agent,” but “I can make the main agent call the right specialist for real work.”