- Built-in subagents: Provided by qodercli, such as general-purpose search, code exploration, and planning.
- Custom subagents: Defined by SDK users through
QoderAgentOptions.agents, suitable for business review, test execution, security analysis, and other specialized roles.
QoderAgentOptions.agent is a special usage that runs an Agent definition as the main session role.
Built-in Subagents
When using a built-in subagent, you do not need to write the subagent definition yourself. You only need to know its name and reference it from the SDK. Common built-in subagents currently provided by qodercli:| Name | Purpose |
|---|---|
general-purpose | General-purpose subagent, suitable for searching code, researching complex problems, and executing multi-step tasks |
Explore | Read-only code exploration subagent, suitable for quickly finding files, searching keywords, and understanding code structure |
Plan | Read-only planning subagent, suitable for designing implementation plans, identifying key files, and analyzing architectural tradeoffs |
/agents to view the currently discovered subagents. From the command line, you can also run:
QoderSDKClient.supported_agents() to read the subagents actually available to the current session:
supported_agents() returns the subagents registered through agents plus the built-in, user, project, and plugin subagents discovered by the current CLI. See AgentInfo for the return structure.
Using Built-in Subagents
Run as the Main Session Role
If you want the entire session to run under a built-in subagent role, pass the built-in subagent name directly toQoderAgentOptions.agent. You do not need to redefine it in agents.
agent can reference a subagent registered by the SDK, or a built-in / user / project / plugin subagent discovered by the current CLI.
Delegate as a Subagent
Subagent delegation happens through the built-inAgent tool. The main session’s available tool set must include Agent; otherwise the model has no entry point for delegation. In SDK usage, a common pattern is to pre-authorize that tool call path and name the desired subagent in the prompt.
allowed_tools=["Agent"] allows or pre-authorizes this class of tool calls. If you also use tools to restrict the main session tool allowlist, include Agent in tools as well. Do not put Agent in disallowed_tools.
The subagent name must match the discovered result exactly, including case. For example, current built-in names include Explore, Plan, and general-purpose. If unsure, call client.supported_agents() first.
Custom Subagents
When built-in subagents do not fit your business or project constraints, define custom subagents throughQoderAgentOptions.agents. For example:
- Read-only code review subagent: can only read files and search; cannot modify code.
- Test execution subagent: can run test commands and analyze failure reasons.
- Security review subagent: focuses only on authentication, authorization, injection, sensitive information leakage, and related risks.
- Business support subagent: can only call specific MCP tools, such as order lookup, ticket search, or internal knowledge base search.
- Define the subagent name, usage description, and system prompt in
agents. - Narrow the tools it can use with
toolsordisallowedTools. - Let the main session delegate to it through the
Agenttool, or useagentto let it drive the main session directly.
TheAgenttool is required: Custom subagents need the main session to delegate through the built-inAgenttool, soallowed_toolsmust include theAgenttool.
Defining Custom Subagents with agents
Minimal example: register a read-only code review subagent.QoderAgentOptions.agentsregisters the custom subagents available to this session.- Subagent delegation happens through the
Agenttool; you must useallowed_tools=["Agent"]here to pre-authorize that call path. - The subagent’s own
toolsonly allow reading and searching, so it cannot edit files or execute commands.
agents Input
agents maps subagent names to AgentDefinition objects. See AgentDefinition for the complete type.
| Field | Type | Required | How to set it | Description |
|---|---|---|---|---|
description | str | Yes | One sentence describing when to use this subagent | Routing description for the model; affects whether it is invoked |
prompt | str | Yes | The subagent’s role, boundaries, and output requirements | System prompt for this subagent |
tools | list[str] | No | For example ["Read", "Grep", "Glob"] | Tool allowlist; when set, only listed tools can be used |
disallowedTools | list[str] | No | For example ["Bash", "Write"] | Tool blocklist, useful when excluding only a few tools |
model | str | No | For example "inherit", "auto", or a full model ID | Model configuration for the subagent |
maxTurns | int | No | For example 8 | Limits how many turns the subagent may execute |
effort | "low" | "medium" | "high" | "max" | No | For example "high" | Controls reasoning effort |
permissionMode | PermissionMode | No | For example "default", "acceptEdits", "plan" | Controls the permission mode for tool calls inside the subagent |
skills | list[str] | No | For example ["review"] | Skills preloaded into the subagent context |
mcpServers | list[str | dict[str, Any]] | No | For example ["orders"] or [{"kb": {...}}] | Limits or adds MCP servers for the subagent |
initialPrompt | str | No | First-turn automatic input | Only takes effect when this subagent becomes the main session role through agent |
AgentDefinition field names use protocol-style camelCase, such as disallowedTools, maxTurns, initialPrompt, and permissionMode, not disallowed_tools or max_turns.
Configuring the Subagent Role
description and prompt are the two most important fields for a custom subagent.
description
description explains when this subagent should be used. The model uses it to decide whether to delegate.
description should state the task boundary clearly. Avoid generic descriptions such as A helpful agent or Helper.
prompt
prompt defines the subagent’s role, boundaries, and output format. The Python AgentDefinition constructor requires this field.
prompt should explain three things:
| What to explain | Example |
|---|---|
| What task it owns | Review code for security and maintainability issues. |
| What it should not do | Do not edit files. Do not run commands. |
| How to return results | Return findings sorted by severity with file paths. |
Configuring Subagent Model and Reasoning
First makedescription and prompt clear, then consider model, effort, and maxTurns. The former decide whether the subagent is invoked correctly and whether it understands its boundaries once invoked. The latter mainly tune quality, speed, and cost after the role is clear.
| Option | Controls | When to adjust first |
|---|---|---|
model | Selects which model or model alias the subagent uses | This subagent repeatedly handles a fixed type of task and you need stable capability and cost |
effort | How much reasoning budget to spend under the same model | The same subagent occasionally receives a more complex task that needs more careful reasoning |
maxTurns | The maximum number of turns | The task may explore too deeply or run too long, or you want a hard cost limit |
model is str | None. Common values include "inherit", "auto", model aliases, or any full model ID supported by the current CLI / backend. Actual usable values depend on qodercli and backend configuration.
Example: give different subagents different strategies.
Controlling Subagent Tools
Custom subagents and the main session use the same tool names. Built-in tool names includeRead, Grep, Glob, and Bash; custom MCP tools use the full format mcp__{serverName}__{toolName}.
The Main Session’s Agent Tool
agents only registers subagents; it does not automatically make the model call them. To delegate a task, the main session’s tool set must contain Agent. If you set QoderAgentOptions.tools to limit the main session’s available tools, remember to include Agent. If you set disallowed_tools=["Agent"], delegation is disabled.
Tool Allowlist: tools
tools is the subagent’s tool allowlist. Once set, the subagent can only use listed tools.
| Scenario | Recommended tools | Description |
|---|---|---|
| Read-only analysis | Read, Grep, Glob | Can inspect code; cannot modify files or run commands |
| Run tests | Bash, Read, Grep | Can execute test commands and analyze output |
| Write code | Read, Edit, Write, Grep, Glob | Can read and write files but cannot run commands directly |
| Call business tools | mcp__server__tool | Only allows specific custom tools |
Tool Blocklist: disallowedTools
disallowedTools is useful when you want to allow most tools while excluding a few.
tools and disallowedTools unless you are certain of the final tool set.
Relationship to Main Session Tool Configuration
A subagent’stools / disallowedTools only apply to that subagent. They do not inherit the main session’s tool allowlist or blocklist trimming. Even if the main session only pre-authorizes the Agent delegation path, the subagent can still use its own configured Read, Grep, and related tools.
Controlling Subagent Permissions
The tool set decides which tools a subagent can call. Permission settings decide how those tool calls are approved or blocked. You can configurepermissionMode separately on a subagent to control permission behavior for its internal tool execution.
permissionMode, see Agents Reference - permissionMode. If the host needs to approve tool calls one by one, use the session-level can_use_tool callback; the context.agent_id received by the callback can be used to identify whether the call comes from a subagent.
Loading Skills for Subagents
skills preloads specialized skills for a subagent. It is useful when you want to bind a specific workflow, team convention, or tool usage pattern to one subagent instead of putting it in every prompt.
skills only affect that subagent’s context. They are not the same as the main session’s QoderAgentOptions.skills. For session-level skill behavior, see Skills.
Configuring Subagent mcpServers
mcpServers limits or adds MCP servers for a subagent. It is suitable for exposing business tools only to the subagents that need them, such as order lookup, ticket search, or internal knowledge base search.
You can reference an MCP server already configured at the session level:
| Scenario | How to configure |
|---|---|
| Multiple subagents share one MCP server | Configure the server in session-level QoderAgentOptions.mcp_servers, then reference its name in the subagent’s mcpServers |
| Only one subagent needs a business tool | Put the server in that subagent’s mcpServers and use tools to limit callable tools |
| You only want to call a specific MCP tool | Also set tools=["mcp__server__tool"] to avoid exposing every tool from the server |
Invoking Subagents
Subagents have three common invocation modes.Automatic Invocation
The model decides whether to call a subagent based on the task and each subagent’sdescription. Clear descriptions improve routing accuracy.
Explicit Invocation
If you want the model to use a specific subagent, name it in the prompt.Run as the Main Session Role
QoderAgentOptions.agent makes the main session run directly as a subagent identity.
agent can reference a custom subagent in agents, or a built-in / user / project / plugin subagent discovered by the current CLI.
Subagent Context and Results
A subagent runs in an independent context. It receives its own system prompt and delegation prompt, but it does not directly inherit the parent session’s full history.| Subagent can see | Subagent cannot see |
|---|---|
Its own prompt | Full parent-session conversation history |
The task prompt passed by the main session through the Agent tool | Intermediate tool results from the parent session |
| Its own available tool definitions | Parent session private reasoning that was not passed to it |
| Skills preloaded by configuration | Intermediate context from other Agents |
Combined Examples
Multi-role Collaboration
Register multiple subagents with different roles. The main session decides whether and when to call them based on the task.Automatically Run the First Task After Startup
initialPrompt only takes effect when that subagent becomes the main session role through agent:
auditor is called as a subagent through the main session’s Agent tool, initialPrompt is ignored.
Common Pitfalls
- When directly using a built-in subagent, do not redefine a subagent with the same name in
agentsunless you intentionally want to override it. - Calling subagents depends on the main session’s
Agenttool.allowed_tools=["Agent"]pre-authorizes it; if you usetoolsto restrict main-session tools, includeAgentthere too. - Subagent names are case-sensitive and must match the discovered result, such as
ExploreandPlanwith capitalized first letters. descriptiontells the model when to call the subagent;prompttells the subagent what to do after it is called.- Subagents cannot spawn their own subagents. Do not put
Agentin a subagent’stools. initialPromptonly takes effect for the main session role specified byagent; it is ignored when the agent is delegated to as a subagent.AgentDefinitionfield names are camelCase, not snake_case.- Fields like
background,memory, andcriticalSystemReminder_EXPERIMENTALexist as types, but the SDK registration pipeline does not currently use them to change runtime behavior. Check Agents Reference before relying on them.
Continue Reading
- Agents Reference: Complete reference for
AgentDefinition,AgentInfo,agent, andagents. - Tools: Built-in tools, custom tools, and tool permissions.
- Permissions:
permissionMode,allowed_tools, andcan_use_tool. - Skills: Session-level and subagent-level skill configuration.