Subagents & orchestration

Subagents are short-lived background agents that run in parallel to your main conversation. Use them to research, prototype, or investigate something without blocking your current work.

Ask in any chat session:

• "Research these three options in parallel and recommend one."
• "Check my open CRs, the pipeline status, and whether the deploy landed — all at once."
• "In parallel, run this test in 6 languages."

Crew spawns isolated subagents and brings their results back into your conversation. You don't need to invoke any command — the agent decides when parallel work makes sense.

You can also watch running subagents in the Activity panel: each one shows its task, elapsed time, and a Stop button.

kirocrew spawn run "check my open CRs"        # blocking — waits for the result
kirocrew spawn run --async "check CRs"        # fire-and-forget
kirocrew spawn list                           # see running subagents

When subagents are running:

• The Activity panel shows each one with its task description, elapsed time, and status (running / done / failed / stalled)
• When a subagent finishes, its result is injected into your conversation — the agent summarizes it in its next response
• For a batch of parallel work, results arrive incrementally as each subagent completes

You don't need to poll or check back — results come to you.

Each subagent gets its own independent session with full memory injection (your preferences, lessons, project context). It does not see your current conversation's in-progress work — this keeps your main session lean and prevents subagents from interfering with each other.

• Stop one — click the Stop button on its row in the Activity panel
• Stop all — header Stop-all control in the Activity panel
• Retry a failed one — click "Retry" on a failed subagent's row (spawns a fresh attempt with the same task)

Stopping is neutral — partial output is preserved and marked as "stopped by user," not as a failure.

Agent-facing run controls are scoped to the session that started the subagent. A session can list, inspect, steer, continue, retry, release, or delete only its own runs. The dashboard Activity panel remains the owner control surface for every run. An internal caller with no session identity can see or control only parentless CLI runs; run kirocrew doctor if a session reports an identity gap.

• Concurrency: Crew auto-sizes the concurrent cap from available host memory and CPU. A configured ceiling can narrow it further. resource_status reports the live cap that is currently in force.
• Live headroom: resource_status reports available memory, CPU load, the current posture, and the subagent cap currently enforced. It is advisory and reserves nothing.
• Timeout: each subagent can run for up to three hours and make up to 1000 tool calls. See Configuration for the related settings.
• Stall detection: a row that stops producing activity is marked stalled so you can inspect or stop it; Crew does not treat silence alone as proof that useful work ended.

Check resource_status before a wide fan-out or expensive build. When the posture is tight or critical, reduce parallelism or defer the heavy step rather than competing with work already running. Under memory pressure, a spawn is refused as back-pressure — that refusal is a signal to take the lighter path, not a transient error to retry.

Crew writes accepted subagent work into a durable task queue before acknowledging it. Queued work survives a Gateway restart and re-enters scheduling when capacity is available after startup. A recovered entry is reconciled conservatively so work with uncertain side effects is not silently repeated.

Use multiple subagents for independent work that can run in parallel. A single subagent adds a context hop without parallelism, so spawn_run refuses one-task delegation unless it names a genuinely different agent, model, or Crew, or supplies one of these reasons:

• parent_parallel: the parent keeps a separate ready workstream while this asynchronous child runs
• bulk_data: a large input needs isolated distillation
• fresh_context: an independent review or clean reproduction must not inherit the current reasoning
• specialist: the child has a specific capability the parent lacks
• user_requested: the user explicitly asked for an isolated worker

The model value auto is not a different-model justification. Reasons that depend on context also require concrete details and are retained in the run record as the model's claim, not as proof of authorization.

Crew members can dispatch worker sessions from their own thread on the Claude Code and KAS backends. Each worker inherits the member's trust posture, so a trusted member's worker does not stop at its first tool call. This session-control capability is on by default. To change it for every agent, see Configuration.

Subagents inherit your session's approval mode:

• Autopilot on — subagent tool calls are auto-approved (deny rules still apply)
• Autopilot off — tool calls that need approval are either denied by default (headless channels) or prompt you (dashboard)

You don't configure approval per-subagent — it follows whatever your main session is set to. When a subagent is waiting for spawn approval, Crew shows that parked state in its running-work views so you can approve it or change the plan.

When a subagent's output is long, your conversation gets a summary. To read the full transcript:

• Click the subagent in the Activity panel to expand its output
• Or ask: "show me the full output from subagent X"

Results are retained for about an hour after delivery, then cleaned up.