Multi-Agent

Multi-Agent lets one root agent organize multiple subagents. Each subagent has its own task, conversation, and model run, while remaining part of the same collaboration tree. The root agent divides the work, follows up, integrates the results, and delivers the final result to you.

When to use it

It suits parallel work with clear boundaries, for example:

One agent reads the frontend and another reads the backend, followed by a cross-check.
Research multiple candidate approaches or sources in parallel.
Review implementation, tests, and documentation separately.
Have one subagent reproduce an issue while another reviews historical changes.

Do not split every small sequential step when they depend strongly on one another. Communication and context copying between subagents also carry a cost. A single agent is usually faster for a simple task.

How to use it now

There is currently no user-facing “Create subagent” button. In the root conversation, explicitly ask the root agent to divide the work, for example:

Divide this project review into three independent subtasks: frontend interactions, the Rust core, and testing and release. Complete them in parallel, cross-check the results, and then summarize them yourself. All subtasks must be read-only first.

The root agent can use collaboration tools to create subagents, send messages, assign follow-up tasks, wait for results, inspect the tree, or interrupt descendants. Whether it actually delegates still depends on the current model calling these tools correctly. You can ask it to report the division of work and the status of every subtask.

Create subagent templates

A template can define the name, description, instructions, and model for a recurring role:

Add a project first.
Open “Settings → Subagents.”
Select the project, then select “New template.”
Enter the name, short description, and complete instructions.
Select an enabled model and save.

Templates are isolated by project and are not global. You can enable, disable, edit, or delete them. A change affects only subagents created in the future; existing nodes retain the snapshot from their creation time.

Observe work in Agent Center

After the current root conversation creates a subagent, a “Subagents” module appears in the right sidebar:

“In progress” shows queued, running, and awaiting-approval subagents.
“Finished” shows completed, failed, interrupted, unknown-outcome, archived, or disabled states.
Open a subagent to inspect its read-only conversation and tool activity.
Returning to the list preserves the current root task's browsing position.

A subagent conversation is an observation surface. You cannot type into it, edit its history, or start a run directly. When rework or more information is needed, tell the root agent which subtask should continue.

Subagent approvals

Subagents remain subject to file, command, skill, MCP, and browser permissions. An action that needs a user decision is routed to the root task's approval area with the source task path and tool name.

Before approval, verify:

Which subagent proposed the action.
Whether the target is within the original division of work.
Whether another subagent is modifying the same file or external resource at the same time.

A subagent cannot have broader permissions than the root task. Follow-up tasks are further constrained by ancestor permissions.

How collaboration is organized

The current structure is a tree: every subagent has one direct parent agent. Sending a message transfers information only; to schedule another execution, the parent agent must issue a follow-up task. A subagent does not disappear automatically after completing one run and may be awakened again later.

Each agent can run at most one turn at a time. Interactive root agents, subagents, and scheduled automations share concurrency capacity. By default, at most four agent turns run globally at the same time. A single tree can contain at most 64 nodes and reach a depth of at most eight. At a limit, work is queued or rejected rather than expanding without bound.

Practical guidance

Give every subtask explicit inputs, outputs, and prohibited scope.
Avoid having two subagents write the same file at the same time.
Require each subagent to provide evidence rather than only report “done.”
Have the root agent integrate the final result and resolve conflicts and inconsistencies.
When external side effects are involved, do not let multiple subagents submit the same action.

Current limitations

Supports tree-structured collaboration only, not arbitrary dependencies, conditional branches, or graphical workflows.
Users cannot directly edit, start, or reply to subagent conversations.
A scheduled automation cannot target a subagent directly. It can only start a root task, which may then delegate.
Agent Center shows only the collaboration tree of the active root conversation; it does not aggregate multiple root tasks.
External side effects whose outcome cannot be confirmed after a process crash are conservatively marked as unknown and are not replayed automatically.