Split big work into subtickets
One agent does best on one coherent change. When the work is bigger than that, split it: into subtickets you create yourself, into a fresh agent that executes a plan, or into a Loop an agent builds and runs. This page covers each, and where the children’s work lands.
Before you begin
Section titled “Before you begin”- For orchestration: Agent orchestration on in Settings > Agents > Orchestration. The Developer and Maintainer profiles turn it on; Explorer leaves it off.
Group tickets under an epic
Section titled “Group tickets under an epic”An epic runs no agent: it groups tickets.
- Click Create and set Type to Epic (no agent, groups subtasks).
- Write what the epic is for and click Create.
- Add its children (next section).
Result: the epic’s Subtasks list shows each child with its status, and its card counts them. The children do the work; move the epic to Done yourself when they are.
Add a subticket by hand
Section titled “Add a subticket by hand”In the parent ticket:
- Under Subtasks, type a title in New subtask title, or search an existing ticket to attach….
- Pick the type (task or command), the mode and the landing column (backlog or to do). + Description adds a description; More details… opens the full Create ticket form with the parent filled in.
- Click Add.
Or, from the Create ticket form, fill in Parent ticket (optional).
Result: the child lands on the parent’s board with the parent’s working directory, model, thinking level and priority, unless you change them. The parent’s timeline records it.
To attach an existing ticket, type at least two characters of its title or id in the same field, pick it (it reads attach existing) and click Attach. A ticket cannot move under one of its own children or onto another board’s ticket.
To reorder the list, drag a row by its handle. The filter pills above the list narrow it by column.
Read the Subtask map
Section titled “Read the Subtask map”Subtask map in a ticket with a parent or children draws the tree: each node with its status, title, a one-line summary and its branch. Click a node to open that ticket.
- Full tree redraws from the top ancestor, Archived adds archived children, and Expand opens the map full screen.
- With Subtask map explanations (LLM) on (Settings > Automation > Board features), an Explain button writes a one-line purpose for each node and a short relationship label for each arrow. Clear removes them. Nothing is generated until you click Explain.
Result: you see the whole split and where each part stands.
Execute a plan by subagent or by Loop
Section titled “Execute a plan by subagent or by Loop”When a plan is waiting for your sign-off, you can hand its execution to fresh agents instead of the one that wrote it:
- On the plan card, click Execute by subagent or Execute by loop (the second shows when orchestration is on).
- Pick a Model and Thinking level for the new agent, or keep Same as this ticket.
- Click Delegate.
| Choice | What happens |
|---|---|
| Execute by subagent | A subticket, Execute plan: and the title, implements the plan from an empty context. |
| Execute by loop | A subticket, Orchestrate plan: and the title, splits the plan into independent strands and runs them as a Loop you can watch. If the plan is really one strand, it says so and implements it itself. |
Result: the parent is marked approved and parks in Pending Action. When the child finishes (and its checks pass), its work merges into the parent’s branch and the parent moves to In Review with a note, so you approve one merge, on the parent.
Let an agent orchestrate
Section titled “Let an agent orchestrate”With orchestration on, an agent can decide to split its own ticket. It stays solo by default, hands one strand to a single child, and builds a Loop for two or more independent strands; it never fans out loose parallel tickets.
In Settings > Agents > Orchestration:
| Setting | Default | What it does |
|---|---|---|
| Agent orchestration | on (Developer, Maintainer) | Gives agents the playbook for splitting work. Off keeps every ticket solo. |
| Orchestrator worker model | sonnet | The model a child gets unless the orchestrator picks one: a frontier orchestrator over cheaper workers. Blank inherits the parent’s model. |
| Max orchestration children | 6 | How many children one orchestration may start (1 to 20). A plan that proposes more is refused. |
| Orchestrator self-approval | off | Lets the orchestrator approve or correct its own children’s plans and answer their questions, instead of you. |
| Orchestrator permission delegation | off | Lets the orchestrator pass on a tool grant it already holds to its children, or deny one. Shell commands, plugin sources and repo re-binds always come to you. |
When the orchestrator files its plan, an Agents to dispatch panel lists the children it will create. Before you accept, you can pick each one’s model or drop one.
With self-approval on, a child’s question, plan or permission request goes to its orchestrator first. The orchestrator answers it, or asks you once and passes your answer to every child that needs it; you are notified only if it cannot decide.
Result: the orchestrator parks while its children run and wakes when they have all finished, then reviews, merges and tests their work before it finishes.
Where a child’s work lands
Section titled “Where a child’s work lands”A child an orchestrator creates branches off the parent’s branch, not the base branch, and never opens a pull request or merges into the base by itself. The orchestrator merges each child into its own branch (the same merge as your Merge button, conflict resolution included), tests the combined result and hands over one branch.
So you review and merge once, on the parent, and the parent’s timeline says which child was merged into its branch. A child you add by hand is an ordinary ticket: it branches off the base and you merge it yourself.
Show or hide orchestrated children
Section titled “Show or hide orchestrated children”A child that reaches In Review while its orchestrator still has to review it is hidden from the board, so In Review only holds what is waiting for you.
- Open the More actions menu in the header.
- Click Show orchestrated (or Hide orchestrated).
Result: those children show again, each with an awaiting # chip naming the orchestrator. Once the orchestrator is Done or Discarded they come back by themselves. On the board, children in the same column as their parent nest in a frame under it (N subtickets), and Group cards by Parent groups a column by parent.
If something goes wrong
Section titled “If something goes wrong”exceeds the orchestrator_max_children cap
Section titled “exceeds the orchestrator_max_children cap”The orchestrator proposed more children than Max orchestration children allows. Ask for fewer, broader strands, or raise the cap.
epics are containers and cannot be claimed or run by an agent
Section titled “epics are containers and cannot be claimed or run by an agent”An epic runs no agent. Create a task under it for the work.
cannot attach a ticket to a parent on a different board
Section titled “cannot attach a ticket to a parent on a different board”Move the ticket to the parent’s board first (Organize the board).
Related
Section titled “Related”- Run a Loop, for the pipeline an orchestrator builds.
- Which tool when, for when splitting pays.
- Review and merge an agent’s work, for the one merge at the end.