OpenClaw sub-agents and multiple agents

OpenClaw has two answers to the question of more than one agent, and the docs keep them apart. Sub-agents are background runs spawned from an existing run, each in its own session, announcing the result back to whoever asked and tracked as a background task; multiple agents are separately configured agents with their own workspaces and routing. Here is what a sub-agent is and costs, how deep the nesting goes and how results come back, the tools a child can never have, and where the other kind of multiplicity lives.

Sub-agents are background agent runs spawned from an existing agent run.

What a sub-agent is

• Its own session key under the parent agent, an announce back to the requester by default for review, and a background task record for every run; the goals are parallel research and slow tool work without blocking the main run, isolation by session and optional sandbox, and a tool surface that is hard to misuse.
• Its own context and token usage: the docs’ cost note says to set a cheaper model for sub-agents and keep the main agent on the better one, and to fork the requester’s transcript into a child only when it genuinely needs it.
• A run ends, a session does not: a finished run is view-only in the Control UI with a way back to the parent, and a persistent visible session is created only when the user asks for one, not because a task was long or produced a report.

Nesting and how results return

By default sub-agents can delegate recursively to depth five, with knobs for the spawn depth, one to five, the active children per agent, five by default and up to twenty, a global concurrency lane cap of eight, a default run timeout and an announce timeout. The main agent sits at depth zero, orchestrators below the cap can spawn, and a leaf at the cap cannot. Results climb one level at a time: a descendant announces to its parent, the parent synthesizes its children before announcing upward, and the main agent delivers to the user. The docs tell agents to wait for completion events rather than poll, and to answer a late completion with the silent no-reply token.

The tools a child never gets

• Always lost, whatever the depth: the gateway tool, agents list, session status, progress cards, cron, message, sessions send and the conversation tools. It is a hard deny derived from the sub-agent session envelope on every turn, and ordinary allow lists cannot override it.
• At the depth cap, also lost: the sub-agent tools, sessions list, sessions history and spawn, so a leaf’s only way to talk is the announce chain.
• The sub-agent tool policy can deny more or set a final allow-only filter, but that filter cannot add back a tool the tool profile removed; the coding profile’s missing browser is the docs’ example.

OpenClaw automations covers the scheduled runs that often spawn these, and OpenClaw sandboxing explained the isolation a child can inherit.

Multiple agents versus sub-agents

Several configured agents live under the per-agent entries of the config, each able to override the defaults where the schema allows, with channels and rooms routed to them; the Discord and Matrix pages both mention mapping guilds and rooms to agents. Sub-agents are temporary children of a single run, spawned by a tool rather than declared in a file. The OpenClaw config file explains the two buckets the entries sit in.

On Diali

On Diali each assistant is its own isolated instance, so multiple agents means several assistants, each with its own channels and workspace, and sub-agents stay inside one assistant’s run with the same depth and tool rules. Hosted OpenClaw on Diali is the assistant and Diali pricing shows how assistants are counted.

• A child runs in its own session and announces upward.
• Depth five by default; a leaf cannot spawn.
• Cron, message, gateway and session tools are never a child’s.