Multi-Agent principles

Multi-Agent does not let several models chat freely. It lets one root Agent place independent tasks in a controlled parent–child tree. Every Agent still uses the same Agent Loop, Tools, permissions, and approval mechanisms.

A tree, not a free-form network

Root Agent (the user communicates with it)
├── Subagent: frontend investigation
│   └── Subagent: focused review
└── Subagent: backend investigation

Each subagent has its own task name, model snapshot, and independent conversation, and belongs to exactly one parent. The current structure is not a general-purpose DAG, graphical workflow, or automatic planner.

What does the root Agent do?

The root Agent interprets the user's objective, selects templates, creates subagents, delegates work, follows up with or interrupts descendants, and organizes the results into a final answer. The user always interacts and handles approvals in the root conversation.

What does a subagent do?

A subagent receives a focused task and can read the project, use Tools, or create further descendants during its own Run. Its permissions cannot be broader than its ancestors' permissions; restrictions along the parent chain continue to narrow it.

Subagents in the right sidebar provides read-only observation of subagent conversations. This read-only behavior is intentional: it prevents the user from bypassing the parent–child collaboration relationship and directly changing a node that the root Agent is coordinating.

Messages and execution opportunities are different

Messages between a parent and child are persisted first. Sending a message alone does not necessarily make an idle Agent run immediately. When more work is required, the parent Agent assigns follow-up work and creates another execution opportunity. Completing one Turn does not delete the Agent; it can be awakened later.

More parallelism is not always better

All interactive root Agents, subagents, and Scheduled Automations share limited process concurrency. Splitting the work can make it slower when subtasks read many of the same files, depend on the same prerequisite conclusion, or frequently wait for one another.

Work suited to parallel execution normally has clear input boundaries, independent deliverables, and results that the root Agent can cross-check. Examples include assigning frontend, backend, and testing workstreams, or asking different Agents to review the same plan independently.

Recovery and unknown outcomes

The task tree, messages, and critical state are written to local storage first. After an application restart, work that crossed the persistence boundary can recover. If an external side effect may already have been sent but its result cannot be confirmed, the system does not replay it blindly and reports an unknown outcome instead.

Boundaries users should remember

• Subagent templates are managed per project; changes affect only nodes created in the future.
• Users cannot directly edit or start a subagent conversation.
• Scheduled Automation cannot target a subagent conversation directly.
• Multi-Agent does not automatically guarantee consistent conclusions; the root Agent must still compare evidence.
• More Agents increase context use, model calls, and cost.

For a guided example, see Use multiple Agents in parallel.