Subagents are specialized roles that the main session can temporarily delegate to. The Qoder CN Agent SDK supports two kinds of subagents:
When using a built-in subagent, you don't need to write a subagent definition yourself. You only need to know its name and reference it in the SDK.
Common built-in subagents currently in qodercli:
The list of built-in subagents changes with the qodercli version and current configuration. In the interactive CLI you can type
After an SDK session is initialized, you can use
The list returned by
If you want the entire session to run as a certain built-in subagent's role, you can pass the built-in subagent name directly to
Subagent delegation is done through the built-in
When built-in subagents don't fit your business or project constraints well enough, you can customize subagents via
A minimal example: register a read-only code review subagent.
There are three key points in this example:
A good
If
Write
You can decide in this order:
Example: configure different strategies for different subagents.
For the complete set of allowed values for each field, see Agents Reference - model, Agents Reference - maxTurns, and Agents Reference - effort.
Custom subagents use the same tool names as the main session. Built-in tool names include
Common tool combinations:
Generally, do not set both
A subagent's
The tool set determines "which tools a subagent can call," while permission configuration determines "how those tool calls are approved or blocked." You can configure
For the complete set of allowed values and semantics of
Usage recommendations:
A subagent's
You can also configure a dedicated MCP server for a particular subagent:
Usage recommendations:
For the MCP server configuration structure, see MCP and Agents Reference - mcpServers.
There are three common ways to invoke a subagent.
The model automatically decides whether to invoke a subagent based on the task and each subagent's
If you want the model to use a certain subagent, you can call it out by name in the prompt.
A subagent runs in an isolated context. It receives its own system prompt and the delegation prompt, but does not directly inherit the parent session's full history.
The main channel for the parent session to pass information to a subagent is the task prompt passed in when calling the Agent tool. Therefore, if a subagent needs specific file paths, error messages, or business context, the main session should pass them explicitly when delegating.
After a subagent completes, the parent session receives its final return, not the full context of every one of its internal tool calls. This is also the main value of using subagents to isolate context.
Register multiple subagents with different roles, and let the main session decide whether and when to invoke them based on task needs.
If
- Built-in subagents: provided by qodercli, such as general-purpose search, code exploration, and planning.
- Custom subagents: defined by SDK consumers via
options.agents, suitable for specialized roles such as business review, test execution, and security analysis.
options.agent is a special usage that runs a subagent definition as the main session's role.
Built-in Subagents
When using a built-in subagent, you don't need to write a subagent definition yourself. You only need to know its name and reference it in the SDK.
Common built-in subagents currently in qodercli:
| Name | Purpose |
|---|---|
general-purpose | A general-purpose subagent, suitable for searching code, researching complex problems, and executing multi-step tasks |
Explore | A read-only code exploration subagent, suitable for quickly locating files, searching for keywords, and understanding code structure |
Plan | A read-only planning subagent, suitable for designing implementation plans, identifying key files, and analyzing architectural trade-offs |
/agents to view the subagents currently discovered; on the command line you can also run:
q.supportedAgents() to read the subagents actually available in the current session:
q.supportedAgents() includes subagents registered by the SDK via options.agents, as well as the built-in, user, project, and plugin subagents that the current CLI has discovered and that are applicable to SDK scenarios. general-purpose, Explore, and Plan can appear in SDK sessions by default; the interactive-CLI helper subagents qoder-guide and statusline-setup are not supported in SDK sessions and do not appear in q.supportedAgents(). See AgentInfo for the returned structure.
Using Built-in Subagents
Running as the Main Session Role
If you want the entire session to run as a certain built-in subagent's role, you can pass the built-in subagent name directly to options.agent without redefining it in options.agents.
options.agent can reference a subagent registered by the SDK, or a built-in / user / project / plugin subagent that the current CLI has discovered and that is applicable to SDK scenarios.
Delegating as a Subagent
Subagent delegation is done through the built-in Agent tool. The main session's available tool set must include Agent so that the model has an entry point to initiate delegation; a common practice in the SDK is to pre-authorize this tool-call path, then call it out by name in the prompt.
allowedTools: ['Agent'] means allowing / pre-authorizing this kind of tool call; if you also use options.tools to narrow the main session's available tool allowlist, you must include Agent in tools as well. Do not put Agent in disallowedTools.
The subagent name must match the current discovery result, including case. For example, the current built-in names include Explore, Plan, and general-purpose. When unsure, call q.supportedAgents() first.
Custom Subagents
When built-in subagents don't fit your business or project constraints well enough, you can customize subagents via options.agents. For example:
- A read-only code review subagent: can only read files and search, and cannot modify code.
- A test execution subagent: can run test commands and analyze failure causes.
- A security review subagent: focuses only on risks such as authentication, authorization, injection, and sensitive information leakage.
- A business support subagent: can only call specified MCP tools, such as order lookup, ticket retrieval, and internal knowledge base search.
- In
options.agents, define the subagent's name, purpose description, and system prompt. - Use
toolsordisallowedToolsto constrain which tools it can use. - Let the main session delegate to it through the
Agenttool, or useoptions.agentto have it drive the main session directly.
TheAgenttool must be included: a custom subagent needs the main session to initiate delegation through the built-inAgenttool, soallowedToolsmust include theAgenttool.
Customizing Subagents with options.agents
A minimal example: register a read-only code review subagent.
options.agents registers the custom subagents available for this session.
- Subagent delegation happens through the
Agenttool; here you must useallowedTools: ['Agent']to pre-authorize this call path. - The subagent's own
toolsallow only reading and searching, so it cannot modify files or execute commands.
options.agents Parameters
options.agents is a mapping from subagent names to subagent definitions. See AgentDefinition for the complete type.
| Field | Type | Required | How to Fill | Description |
|---|---|---|---|---|
description | string | Yes | A one-sentence explanation of when to use this subagent | Routing description for the model; affects whether it gets called |
prompt | string | Yes | The subagent's role, boundaries, and output requirements | The subagent's system prompt |
tools | string[] | No | e.g. ['Read', 'Grep', 'Glob'] | Tool allowlist; once configured, only the listed tools can be used |
disallowedTools | string[] | No | e.g. ['Bash', 'Write'] | Tool blocklist; suitable for excluding just a few tools |
model | string | No | e.g. 'inherit', 'auto', 'performance' | The subagent's model configuration |
maxTurns | number | No | e.g. 8 | Limits the maximum number of turns the subagent runs |
effort | EffortLevel | No | e.g. 'low', 'medium', 'high', 'max' | Controls the reasoning effort level |
permissionMode | PermissionMode | No | e.g. 'default', 'acceptEdits', 'plan' | Controls the permission mode for the subagent's internal tool calls |
skills | string[] | No | e.g. ['review'] | Skills preloaded into the subagent's context |
mcpServers | AgentMcpServerSpec[] | No | MCP server name or configuration | Restricts or adds MCP servers for the subagent |
initialPrompt | string | No | Automatic first-turn input | Only takes effect when this subagent becomes the main session role via options.agent |
Configuring the Subagent Role
description and prompt are the two most important fields for a custom subagent.
description
description describes "when this subagent should be used." The model decides whether to delegate based on it.
description should specifically state the task boundaries. Don't write generic descriptions like A helpful agent or Helper.
prompt
prompt defines the subagent's role, boundaries, and output style. TypeScript users will get a type-check error if they don't pass prompt; JavaScript users should always pass this field as well.
prompt is written only vaguely, like "you are a helpful assistant," the model may still call this subagent, but its behavior will be close to that of an ordinary assistant: it won't know what to check first, what not to do, or how to return results.
We recommend that prompt state at least three things:
| What to State | Example |
|---|---|
| What task it's responsible for | Review code for security and maintainability issues. |
| What it shouldn't do | Do not edit files. Do not run commands. |
| How to return results | Return findings sorted by severity with file paths. |
Configuring the Subagent's Model and Reasoning
Write description and prompt clearly first, then consider model, effort, and maxTurns. The former determine whether the subagent gets called correctly and whether it knows its boundaries once called; the latter are mainly used to tune effectiveness, speed, and cost after the role is already clear.
| Configuration | What It Controls | When to Adjust First |
|---|---|---|
model | Selects the model tier the subagent uses | This subagent takes on a fixed type of task long-term and needs stable control over capability and Credit cost |
effort | Controls how much reasoning budget to spend within the same model | The same subagent occasionally encounters more complex tasks that require more careful reasoning |
maxTurns | Limits the maximum number of turns | The task may explore too deeply, run too long, or you want to set a hard cap on cost |
- By default, configure nothing, or set
model: 'inherit'to have the subagent follow the main session's model. - If this subagent handles high-frequency, simple tasks that can tolerate rough answers, use
model: 'efficient'ormodel: 'lite'to reduce cost. - If this subagent takes on high-risk tasks such as architecture design, complex refactoring, or cross-module review, use
model: 'performance'ormodel: 'ultimate'to raise the capability ceiling. - If the model tier stays the same but you want it to think a bit more on the current task, raise
effort. - If you're worried about runaway exploration, use
maxTurnsto set a cap on the number of execution turns.
| Scenario | Recommended Configuration | Description |
|---|---|---|
| Quick Q&A, format conversion, simple lookup | model: 'efficient', effort: 'low', maxTurns: 3 | Cheap and fast, suitable for low-risk tasks |
| Read-only code exploration, mapping module relationships | model: 'auto' or 'inherit', effort: 'medium' | Let routing or the main session model decide the capability tier |
| Code review, security review, migration plans | model: 'performance', effort: 'high' | Better suited for tasks that require careful trade-offs and problem discovery |
| Complex system design, high-difficulty problem analysis | model: 'ultimate', effort: 'high' or 'max' | Higher cost; recommended only for critical, complex tasks |
| Batch assistant subtasks | model: 'efficient', effort: 'low', smaller maxTurns | Suitable for controlling total cost when multiple subagents collaborate |
Controlling Subagent Tools
Custom subagents use the same tool names as the main session. Built-in tool names include Read, Grep, Glob, and Bash; custom MCP tool names use the full format mcp__{serverName}__{toolName}. This part configures which tools the subagent can see and call.
The Agent Tool on the Main Session Side
options.agents only registers subagents; it does not automatically call them on the model's behalf. For the model to delegate a task, Agent must exist in the main session's tool set. The default tool set usually registers it; if you use options.tools to restrict the main session's available tools, remember to include Agent; if you set disallowedTools: ['Agent'], delegation will be disabled.
Tool Allowlist: tools
tools is the subagent's tool allowlist. Once configured, this subagent can only use the listed tools.
| Scenario | Recommended Tools | Description |
|---|---|---|
| Read-only analysis | Read, Grep, Glob | Can view code but cannot modify it or execute commands |
| Running tests | Bash, Read, Grep | Can execute test commands and analyze output |
| Writing code | Read, Edit, Write, Grep, Glob | Can read and write files, but cannot run commands directly |
| Calling business tools | mcp__server__tool | Only allows calling the specified custom tools |
Tool Blocklist: disallowedTools
disallowedTools is suitable for the "allow most tools, exclude only a few" scenario.
tools and disallowedTools, unless you know the final tool set exactly.
Relationship with the Main Session's Tool Configuration
A subagent's tools / disallowedTools apply only to itself, and do not inherit the main session's tool allowlist or blocklist restrictions. Even if the main session only pre-authorizes the Agent delegation path, the subagent can still use its own configured tools such as Read and Grep.
Controlling Subagent Permissions
The tool set determines "which tools a subagent can call," while permission configuration determines "how those tool calls are approved or blocked." You can configure permissionMode individually on a subagent to control the permission behavior of its internal tool execution.
Permission Mode: permissionMode
permissionMode, see Agents Reference - permissionMode. If the host needs to approve tool calls one by one, you can use the session-level canUseTool callback;
Loading Skills for a Subagent
skills is used to preload specialized skills into a particular subagent. It's suitable for binding a specific workflow, team convention, or tool usage to a single subagent, rather than stuffing it into every call's prompt.
| Scenario | How to Configure |
|---|---|
| The subagent always works according to a specific specialized process | Write the corresponding skill into that subagent's skills |
| Only the main session needs a certain skill | Use the session-level options.skills; don't put it in the subagent |
| A skill provided by a plugin | Use the plugin-qualified name, e.g. sdk-test-plugin:sdk-echo |
skills only affects that subagent's context, and is not equivalent to the main session's options.skills. For session-level skill behavior, see Skills.
Configuring the Subagent's mcpServers
mcpServers is used to restrict or add MCP servers for a subagent. It's suitable for exposing business tools only to the subagent that needs them, such as order lookup, ticket retrieval, and internal knowledge base search.
You can reference an MCP server already configured in the session:
| Scenario | How to Configure |
|---|---|
| Multiple subagents share the same MCP server | Configure the server at the session level in options.mcpServers, then reference the name in the subagent's mcpServers |
| Only a certain subagent needs business tools | Put the server in that subagent's mcpServers, and use tools to restrict which tools can be called |
| You only want to call a specific MCP tool | Also configure tools: ['mcp__server__tool'] to avoid exposing all of the server's tools |
Invoking Subagents
There are three common ways to invoke a subagent.
Automatic Invocation
The model automatically decides whether to invoke a subagent based on the task and each subagent's description. Writing a clear description improves matching accuracy.
Explicit Invocation by Name
If you want the model to use a certain subagent, you can call it out by name in the prompt.
Running as the Main Session Role
options.agent lets the main session run directly as a certain subagent.
options.agent can reference a custom subagent in options.agents, or a built-in / user / project / plugin subagent that the current CLI has discovered.
Subagent Context and Results
A subagent runs in an isolated context. It receives its own system prompt and the delegation prompt, but does not directly inherit the parent session's full history.
| What the Subagent Can See | What the Subagent Cannot See |
|---|---|
Its own prompt | The parent session's full conversation history |
The task prompt passed in by the main session via the Agent tool | The parent session's intermediate tool results |
| Its own available tool definitions | The parent session's private reasoning process that wasn't passed to it |
| Skills preloaded per configuration | Other agents' intermediate contexts |
Combined Examples
Multi-role Collaboration
Register multiple subagents with different roles, and let the main session decide whether and when to invoke them based on task needs.
Automatically Executing the First-turn Task After Startup
initialPrompt takes effect only when the subagent becomes the main session role via options.agent:
auditor is invoked by the main session as a subagent through the Agent tool, initialPrompt is ignored.
Common Pitfalls
- When using a built-in subagent directly, don't redefine a subagent with the same name in
options.agents, unless you explicitly want to override it. - Invoking a subagent depends on the main session's
Agenttool.allowedTools: ['Agent']is pre-authorization; if you useoptions.toolsto restrict the main session's available tools, includeAgentas well. - The subagent name must match the case of the current discovery result, e.g.
ExploreandPlanstart with an uppercase letter.descriptionis responsible for telling the model when to invoke;promptis responsible for telling the subagent what to do once invoked. - A subagent cannot spawn its own subagents. Don't put
Agentin a subagent'stools.initialPromptonly takes effect for the main session role specified byoptions.agent, and is ignored when delegated to as a subagent. - A subagent's dedicated MCP server can be configured via
mcpServers; for MCP connection methods, see MCP.
Further Reading
- Agents Reference: complete reference for
AgentDefinition,AgentInfo,options.agent, andoptions.agents. - Tools: built-in tools, custom tools, and tool permissions.
- Permission Control:
permissionMode,allowedTools,canUseTool. - Skills: session-level and subagent-level skill configuration.