Subagents
The main conversation can hand a self-contained piece of work to a subagent. Three read-only helpers investigate, plan and review; a worker makes changes in its own worktree.
When a task splits into independent parts, the main conversation hands them to subagents in parallel and keeps the summary and merging for itself. Subagents run in the background and deliver their results to the conversation; you can keep chatting.
Four roles
| Role | Does | Changes files | Step limit |
|---|---|---|---|
| scout | Investigates project files, and outside sources when the task asks; reports exact paths or links, key findings and open questions | Read only | 24 |
| planner | Reads the relevant code and constraints and proposes a verifiable plan | Read only | 24 |
| reviewer | Reviews code, research, data or design against the requirements and real artifacts, reporting problems with evidence | Read only | 24 |
| worker | Completes one bounded implementation slice within the project’s permissions: a chapter, one problem in one module, a set of tests | Yes | 32 |
When a subagent runs out of steps it writes a summary before ending instead of just stopping.
What a subagent knows
A subagent has the project instructions, skills, project memory search, and web search and reading when the main conversation has them. It does not see the conversation, so the task has to state the goal, the facts so far, your requirements and what to return. With “include conversation”, your own recent words are attached as its requirements.
Subagents cannot delegate further, install capabilities, request broader permissions or message anyone outside. Project skills or documents cannot widen their task or authority.
How a worker’s changes reach the project
Each worker changes files in its own worktree. The delegation lists the paths it will change; overlaps with running workers are noted and writes outside them are reported.
After a worker finishes, the host merges its changes itself in only two cases: while the main conversation's turn is still running, it writes the part without conflicts and leaves the conflicting files to the main conversation; when the main conversation is idle but the result opens a new turn, it writes everything or nothing. In every other case (the worker did not finish, failed or ran out of steps, or it finished while the main conversation was idle with nobody to take it) the changes stay pending, untouched in the worker's worktree.
The main conversation handles pending changes with agent_merge: look at them, merge, take one side, resolve by hand or drop them. You can also merge from the subagent card in the conversation. If unmerged workers remain at the end of a turn, the conversation is reminded to settle them first. See Isolation and rollback.
Results reach the model
When a background subagent finishes after the main conversation's turn has already ended, its result is no longer only a notice for you: the next request carries it to the model, so "I delegated it and will report back" can come true. If you rewind the message that carried a result, it is offered again.
Limits
| Scope | Limit |
|---|---|
| Per turn | 12 delegations |
| Running per conversation | 4 |
| Running overall | 6 |
In the UI
The background tasks panel shows each subagent’s progress, usage and current step. The timeline shows “Subagent finished / did not finish / cancelled” with its conclusion; a running subagent can be given more instructions or cancelled, and its result still arrives as a notice.
Workspace and panels
To the right of the conversation is a workspace you arrange yourself: background tasks, files, evolution, workspace changes, terminal, browser and preview all open as panels.
CLI reference
The rna command connects to the same daemon as the workbench. Common commands grouped by purpose.