Building Multi-Agent Workflows in OpenClaw

A single agent can do a lot. But some problems are better solved by splitting work across multiple agents — each with its own session, model, and focus. OpenClaw has first-class support for this through its session management tools.

This guide covers the four tools that make multi-agent workflows possible: agents_list, sessions_spawn, sessions_send, and sessions_list.

Why Multi-Agent?

Not every task needs multiple agents. But when you're dealing with:

• Long-running research that shouldn't block your main conversation
• Parallel workstreams (write an article while checking emails while deploying code)
• Cost optimization (delegate simple tasks to cheaper/free models)
• Isolation (keep sensitive operations in separate sessions)

...then multi-agent becomes the right call.

The Tools

agents_list — See What's Available

Before you can spawn a sub-agent, you need to know which agent IDs are available. agents_list returns the IDs your current agent is allowed to target.

This is a discovery tool. It checks the configured allowlists and tells you what you can work with. In most single-agent setups, you'll see your own agent ID (typically main). In multi-agent configurations, you'll see every agent you have permission to spawn sessions for.

sessions_spawn — Delegate Work

This is the core of multi-agent workflows. sessions_spawn creates a new isolated session, runs a task in it, and announces the result back to the parent.

Key parameters:

• task (required) — What the sub-agent should do. Be specific. This is the only instruction it gets.
• model — Override the model for this session. Use cheaper models for simple tasks (llama for free-tier work, for example).
• agentId — Target a specific agent configuration. Defaults to the current agent.
• label — Human-readable name for the session. Helps when tracking multiple sub-agents.
• cleanup — Set to "delete" to remove the session after completion, or "keep" to preserve the transcript.

Example use case: You need to research a topic and write an article. Instead of doing it inline (blocking your main session for minutes), you spawn a sub-agent:

sessions_spawn(
  task: "Research OpenClaw webhooks from the docs at docs.openclaw.ai. Write a 1000-word practical guide and save it to /workspace/articles/webhooks.md",
  model: "llama",
  label: "webhook-article"
)

The sub-agent runs independently. When it finishes, you get a summary delivered back to your session.

sessions_send — Talk to Running Sessions

Sometimes you need to communicate with a session that's already running. sessions_send lets you inject a message into any session you have access to.

Use cases:

• Steering a sub-agent mid-task ("Focus on the API examples, skip the theory")
• Providing additional context that wasn't in the original task
• Coordinating between agents in complex workflows

You identify the target by sessionKey or label.

sessions_list — Monitor Everything

sessions_list shows you all active sessions with optional filters. Use it to:

• Check which sub-agents are still running
• See the last few messages from each session
• Filter by session type (e.g., only sub-agents, only cron sessions)

Parameters like activeMinutes and messageLimit help you narrow the view.

Patterns That Work

The Dispatcher Pattern

Your main agent acts as a coordinator. It breaks down a complex request into sub-tasks, spawns a sub-agent for each one, and assembles the results.

1. User asks: "Prepare a weekly report"
2. Main agent spawns:
   - Sub-agent A: "Pull this week's git commits and summarize changes"
   - Sub-agent B: "Check email for any support tickets from this week"
   - Sub-agent C: "Get calendar events from this week"
3. Results flow back to main agent
4. Main agent compiles the final report

The Specialist Pattern

Different sub-agents use different models optimized for their task:

• Research tasks → Free-tier models (Llama, Qwen) — they can handle document lookup and summarization without burning credits
• Writing tasks → Mid-tier models for quality prose
• Code generation → Your best model for accuracy

The Background Worker Pattern

Spawn long-running tasks that report back when done. Your main session stays responsive for conversation while work happens in parallel.

This is especially useful for cron-triggered workflows where a scheduled job spawns sub-agents to handle periodic tasks like monitoring, reporting, or content generation.

Practical Tips

Be explicit in task descriptions. Sub-agents don't inherit your conversation history. They only know what you put in the task parameter. Include file paths, expected output formats, and specific instructions.

Use labels. When you have multiple sub-agents running, labels make it trivial to identify which is which in sessions_list output.

Match the model to the task. Don't burn expensive tokens on tasks a free model can handle. Simple file operations, lookups, and basic summarization work fine on smaller models.

Check on long-running agents. Use sessions_list and sessions_history to monitor progress. If something is stuck, you can send a follow-up message via sessions_send.

Clean up when done. Use cleanup: "delete" for throwaway tasks. Keep transcripts only when you need to audit or reference the work later.

When Not to Use Multi-Agent

• Simple, fast tasks — If it takes 10 seconds, just do it inline
• Tasks requiring conversation context — Sub-agents don't see your chat history
• Highly interactive work — If the task requires back-and-forth with the user, keep it in the main session

Wrapping Up

Multi-agent workflows in OpenClaw aren't a gimmick — they're a practical way to parallelize work, optimize costs, and keep your main session responsive. Start with sessions_spawn for background tasks, and build up to more complex orchestration patterns as your needs grow.

The key insight: treat sub-agents like you'd treat a colleague. Give them clear instructions, the right tools, and check in on their progress. The session tools make this natural.