Subagents

Subagents are scoped helpers owned by an agent config: a slice of the workload with its own instructions, operating under the same isolation, approval, and audit guarantees as every governed session. The subagents surface is /ai/subagents. The list shows the candidates the per-agent Subagents picker pulls from: name, description, type, model, runs, status, owner. Any Agent Ops agent listed here can be allow-listed as a delegate on another agent’s Subagents tab. What follows is operating discipline; treat the product UI as the source of truth for fields this page does not name.

Scope each subagent to one slice: named systems, named data, one kind of output. A subagent that can reach everything is an agent with a second name.
Subagents inherit governance. Isolation, approval gates, and the recorded outcome apply; nothing about delegating removes the human gate on risky actions.
One goal per run holds for subagents too. A wandering subagent means the scope was too broad; end, narrow, restart.
Name the approver role for each subagent’s risky actions before it runs. “Service lead on duty” survives rotations; a named person does not.
Review subagent output like any draft: what, on-what, why, blast radius. Then allow or deny deliberately.

Subagents list: candidate agents with type, model, runs, status, and owner

Treat /ai/subagents as the source of truth for subagent surfaces. Before adding one, read When to build an agent: most workloads need a narrower scope or a better skill, not another agent.