Agent roles reference
The lead, its specialists, and the conversation assistants — what each does and how delegation is bounded.
Sub-agents & the swarm explains why a lead agent delegates. These are the roles in the app today. Not all are sub-agents: the Coordinator and the Overseer are conversation assistants without a work sandbox, and Question answers a focused question beside a transcript.
The roles
| Role | What it does |
|---|---|
| Agent (lead) | Owns the work thread, plans and delegates tasks, integrates results, and reports back to you. |
| Explore | Read-only code or web research; maps flows and returns findings, never files or edits. |
| Coder | Implements a scoped slice with named file ownership, choosing local implementation and tests within the lead's brief. |
| Review | Reads the diff through a Code lens for correctness and scope, Security for exploitability, or Linus to score whether the patch resolves its findings. |
| UI driver | Drives the sandbox's real browser to verify a flow or capture visual proof. |
| Question | Answers one focused question about a selected span of a thread, in a side panel without editing the project. |
| Overseer | Helps across your accessible workspace and hands project work to threads, without a code sandbox. |
| Coordinator | Helps within one project and hands implementation to work threads, without a code sandbox. |
| Knowledge maintainer | Settles the Organizer's proposals against the code in background runs listed in Knowledgebase History. |
For how the Coordinator and Overseer help you start and follow work, see The Coordinator & the Overseer.
Reading roles and writing roles
Explore and Review are read-only, so they can investigate or review without writing into the shared tree. Question is read-only too, but its answer goes into a side panel rather than the lead's code review. Coders can edit; their briefs name the slice they own. The UI driver uses the one desktop, so it runs alone. The Coordinator and the Overseer do not edit repository files or run a sandbox; they can hand work to a separate thread.
Scoped implementation
A coder owns a scoped implementation, including the explicit files it may change and the contracts it must leave intact. The lead decides the behavior and architecture; the coder chooses local implementation and tests. The lead checks the returned diff against its full context. Coders make changes in the lead's live sandbox; sub-agents do not commit or merge their own tree. Delegation & review covers the boundaries.
What a child starts with
A sub-agent gets its task directive, a short brief about the current working tree, and the project's knowledge manifest — not the lead's whole transcript. It can open the relevant Knowledgebase area or entry on demand. The context inspector shows what a run was given.
Delegation is bounded
There is no step cap. At the 15-minute wall-clock checkpoint, a child writes a progress report; the lead decides whether to resume it with its full transcript or finish its work itself. Sub-agents are one level deep and cannot delegate to children. A work thread's default limits are 500 child spawns in its lifetime and 10 children running together. Further spawns queue until slots free. Before launching more than two Explore runs in one round, or any Explore above the cost tier, the lead asks you to approve that research spend; model-routing tiers are cost, balance, and intelligence.