docs/tools/subagents.md
Sub-agents are background agent runs spawned from an existing agent run.
They run in their own session (agent:<agentId>:subagent:<uuid>) and,
when finished, announce their result back to the requester chat
channel. Each sub-agent run is tracked as a
background task.
Primary goals:
Use /subagents to inspect or control sub-agent runs for the current
session:
/subagents list
/subagents kill <id|#|all>
/subagents log <id|#> [limit] [tools]
/subagents info <id|#>
/subagents send <id|#> <message>
/subagents steer <id|#> <message>
/subagents spawn <agentId> <task> [--model <model>] [--thinking <level>]
Use top-level /steer <message> to steer the current requester session's active run. Use /subagents steer <id|#> <message> when the target is a child run.
/subagents info shows run metadata (status, timestamps, session id,
transcript path, cleanup). Use sessions_history for a bounded,
safety-filtered recall view; inspect the transcript path on disk when you
need the raw full transcript.
These commands work on channels that support persistent thread bindings. See Thread supporting channels below.
/focus <subagent-label|session-key|session-id|session-label>
/unfocus
/agents
/session idle <duration|off>
/session max-age <duration|off>
/subagents spawn starts a background sub-agent as a user command (not an
internal relay) and sends one final completion update back to the
requester chat when the run finishes.
- `Result` — latest visible `assistant` reply text, otherwise sanitized latest tool/toolResult text. Terminal failed runs do not reuse captured reply text.
- `Status` — `completed successfully` / `failed` / `timed out` / `unknown`.
- Compact runtime/token stats.
- A delivery instruction telling the requester agent to rewrite in normal assistant voice (not forward raw internal metadata).
Native sub-agents start isolated unless the caller explicitly asks to fork the current transcript.
| Mode | When to use it | Behavior |
|---|---|---|
isolated | Fresh research, independent implementation, slow tool work, or anything that can be briefed in the task text | Creates a clean child transcript. This is the default and keeps token use lower. |
fork | Work that depends on the current conversation, prior tool results, or nuanced instructions already present in the requester transcript | Branches the requester transcript into the child session before the child starts. |
Use fork sparingly. It is for context-sensitive delegation, not a
replacement for writing a clear task prompt.
sessions_spawnStarts a sub-agent run with deliver: false on the global subagent lane,
then runs an announce step and posts the announce reply to the requester
chat channel.
Availability depends on the caller's effective tool policy. The coding and
full profiles expose sessions_spawn by default. The messaging profile
does not; add tools.alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"] or use tools.profile: "coding" for agents that should delegate
work. Channel/group, provider, sandbox, and per-agent allow/deny policies can
still remove the tool after the profile stage. Use /tools from the same
session to confirm the effective tool list.
Defaults:
agents.defaults.subagents.model (or per-agent agents.list[].subagents.model); an explicit sessions_spawn.model still wins.agents.defaults.subagents.thinking (or per-agent agents.list[].subagents.thinking); an explicit sessions_spawn.thinking still wins.sessions_spawn.runTimeoutSeconds is omitted, OpenClaw uses agents.defaults.subagents.runTimeoutSeconds when set; otherwise it falls back to 0 (no timeout).When thread bindings are enabled for a channel, a sub-agent can stay bound to a thread so follow-up user messages in that thread keep routing to the same sub-agent session.
Discord is currently the only supported channel. It supports
persistent thread-bound subagent sessions (sessions_spawn with
thread: true), manual thread controls (/focus, /unfocus, /agents,
/session idle, /session max-age), and adapter keys
channels.discord.threadBindings.enabled,
channels.discord.threadBindings.idleHours,
channels.discord.threadBindings.maxAgeHours, and
channels.discord.threadBindings.spawnSessions.
| Command | Effect |
|---|---|
/focus <target> | Bind the current thread (or create one) to a sub-agent/session target |
/unfocus | Remove the binding for the current bound thread |
/agents | List active runs and binding state (thread:<id> or unbound) |
/session idle | Inspect/update idle auto-unfocus (focused bound threads only) |
/session max-age | Inspect/update hard cap (focused bound threads only) |
session.threadBindings.enabled, session.threadBindings.idleHours, session.threadBindings.maxAgeHours.See Configuration reference and Slash commands for current adapter details.
If the requester session is sandboxed, sessions_spawn rejects targets
that would run unsandboxed.
Use agents_list to see which agent ids are currently allowed for
sessions_spawn. The response includes each listed agent's effective
model and embedded runtime metadata so callers can distinguish PI, Codex
app-server, and other configured native runtimes.
agents.defaults.subagents.archiveAfterMinutes (default 60).sessions.delete and renames the transcript to *.deleted.<timestamp> (same folder).cleanup: "delete" archives immediately after announce (still keeps the transcript via rename).runTimeoutSeconds does not auto-archive; it only stops the run. The session remains until auto-archive.By default, sub-agents cannot spawn their own sub-agents
(maxSpawnDepth: 1). Set maxSpawnDepth: 2 to enable one level of
nesting — the orchestrator pattern: main → orchestrator sub-agent →
worker sub-sub-agents.
{
agents: {
defaults: {
subagents: {
maxSpawnDepth: 2, // allow sub-agents to spawn children (default: 1)
maxChildrenPerAgent: 5, // max active children per agent session (default: 5)
maxConcurrent: 8, // global concurrency lane cap (default: 8)
runTimeoutSeconds: 900, // default timeout for sessions_spawn when omitted (0 = no timeout)
},
},
},
}
| Depth | Session key shape | Role | Can spawn? |
|---|---|---|---|
| 0 | agent:<id>:main | Main agent | Always |
| 1 | agent:<id>:subagent:<uuid> | Sub-agent (orchestrator when depth 2 allowed) | Only if maxSpawnDepth >= 2 |
| 2 | agent:<id>:subagent:<uuid>:subagent:<uuid> | Sub-sub-agent (leaf worker) | Never |
Results flow back up the chain:
Each level only sees announces from its direct children.
<Note> **Operational guidance:** start child work once and wait for completion events instead of building poll loops around `sessions_list`, `sessions_history`, `/subagents list`, or `exec` sleep commands. `sessions_list` and `/subagents list` keep child-session relationships focused on live work — live children remain attached, ended children stay visible for a short recent window, and stale store-only child links are ignored after their freshness window. This prevents old `spawnedBy` / `parentSessionKey` metadata from resurrecting ghost children after restart. If a child completion event arrives after you already sent the final answer, the correct follow-up is the exact silent token `NO_REPLY` / `no_reply`. </Note>maxSpawnDepth >= 2): gets sessions_spawn, subagents, sessions_list, sessions_history so it can manage its children. Other session/system tools remain denied.maxSpawnDepth == 1): no session tools (current default behavior).sessions_spawn is always denied at depth 2. Cannot spawn further children.Each agent session (at any depth) can have at most maxChildrenPerAgent
(default 5) active children at a time. This prevents runaway fan-out
from a single orchestrator.
Stopping a depth-1 orchestrator automatically stops all its depth-2 children:
/stop in the main chat stops all depth-1 agents and cascades to their depth-2 children./subagents kill <id> stops a specific sub-agent and cascades to its children./subagents kill all stops all sub-agents for the requester and cascades.Sub-agent auth is resolved by agent id, not by session type:
agent:<agentId>:subagent:<uuid>.agentDir.The merge is additive, so main profiles are always available as fallbacks. Fully isolated auth per agent is not supported yet.
Sub-agents report back via an announce step:
ANNOUNCE_SKIP, nothing is posted.NO_REPLY / no_reply, announce output is suppressed even if earlier visible progress existed.Delivery depends on requester depth:
agent call with external delivery (deliver=true).deliver=false) so the orchestrator can synthesize child results in-session.For top-level requester sessions, completion-mode direct delivery first resolves any bound conversation/thread route and hook override, then fills missing channel-target fields from the requester session's stored route. That keeps completions on the right chat/topic even when the completion origin only identifies the channel.
Child completion aggregation is scoped to the current requester run when building nested completion findings, preventing stale prior-run child outputs from leaking into the current announce. Announce replies preserve thread/topic routing when available on channel adapters.
Announce context is normalized to a stable internal event block:
| Field | Source |
|---|---|
| Source | subagent or cron |
| Session ids | Child session key/id |
| Type | Announce type + task label |
| Status | Derived from runtime outcome (success, error, timeout, or unknown) — not inferred from model text |
| Result content | Latest visible assistant text, otherwise sanitized latest tool/toolResult text |
| Follow-up | Instruction describing when to reply vs stay silent |
Terminal failed runs report failure status without replaying captured reply text. On timeout, if the child only got through tool calls, announce can collapse that history into a short partial-progress summary instead of replaying raw tool output.
Announce payloads include a stats line at the end (even when wrapped):
runtime 5m12s).models.providers.*.models[].cost).sessionKey, sessionId, and transcript path so the main agent can fetch history via sessions_history or inspect the file on disk.Internal metadata is meant for orchestration only; user-facing replies should be rewritten in normal assistant voice.
sessions_historysessions_history is the safer orchestration path:
<relevant-memories> / <relevant_memories> scaffolding stripped; plain-text tool-call XML payload blocks (<tool_call>, <function_call>, <tool_calls>, <function_calls>) stripped, including truncated payloads that never close cleanly; downgraded tool-call/result scaffolding and historical-context markers stripped; leaked model control tokens (<|assistant|>, other ASCII <|...|>, full-width <|...|>) stripped; malformed MiniMax tool-call XML stripped.[sessions_history omitted: message too large].Sub-agents use the same profile and tool-policy pipeline as the parent or target agent first. After that, OpenClaw applies the sub-agent restriction layer.
With no restrictive tools.profile, sub-agents get all tools except
session tools and system tools:
sessions_listsessions_historysessions_sendsessions_spawnsessions_history remains a bounded, sanitized recall view here too — it
is not a raw transcript dump.
When maxSpawnDepth >= 2, depth-1 orchestrator sub-agents additionally
receive sessions_spawn, subagents, sessions_list, and
sessions_history so they can manage their children.
{
agents: {
defaults: {
subagents: {
maxConcurrent: 1,
},
},
},
tools: {
subagents: {
tools: {
// deny wins
deny: ["gateway", "cron"],
// if allow is set, it becomes allow-only (deny still wins)
// allow: ["read", "exec", "process"]
},
},
},
}
tools.subagents.tools.allow is a final allow-only filter. It can narrow
the already-resolved tool set, but it cannot add back a tool removed
by tools.profile. For example, tools.profile: "coding" includes
web_search/web_fetch but not the browser tool. To let
coding-profile sub-agents use browser automation, add browser at the
profile stage:
{
tools: {
profile: "coding",
alsoAllow: ["browser"],
},
}
Use per-agent agents.list[].tools.alsoAllow: ["browser"] when only one
agent should get browser automation.
Sub-agents use a dedicated in-process queue lane:
subagentagents.defaults.subagents.maxConcurrent (default 8)OpenClaw does not treat endedAt absence as permanent proof that a
sub-agent is still alive. Unended runs older than the stale-run window
stop counting as active/pending in /subagents list, status summaries,
descendant completion gating, and per-session concurrency checks.
After a gateway restart, stale unended restored runs are pruned unless
their child session is marked abortedLastRun: true. Those
restart-aborted child sessions remain recoverable through the sub-agent
orphan recovery flow, which sends a synthetic resume message before
clearing the aborted marker.
Automatic restart recovery is bounded per child session. If the same
sub-agent child is accepted for orphan recovery repeatedly inside the
rapid re-wedge window, OpenClaw persists a recovery tombstone on that
session and stops auto-resuming it on later restarts. Run
openclaw tasks maintenance --apply to reconcile the task record, or
openclaw doctor --fix to clear stale aborted recovery flags on
tombstoned sessions.
/stop in the requester chat aborts the requester session and stops any active sub-agent runs spawned from it, cascading to nested children./subagents kill <id> stops a specific sub-agent and cascades to its children.maxConcurrent as a safety valve.sessions_spawn is always non-blocking: it returns { status: "accepted", runId, childSessionKey } immediately.AGENTS.md + TOOLS.md (no SOUL.md, IDENTITY.md, USER.md, HEARTBEAT.md, or BOOTSTRAP.md).maxSpawnDepth range: 1–5). Depth 2 is recommended for most use cases.maxChildrenPerAgent caps active children per session (default 5, range 1–20).