Skip to content
rev0Docs

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.

  • For orchestration: Agent orchestration on in Settings > Agents > Orchestration. The Developer and Maintainer profiles turn it on; Explorer leaves it off.

An epic runs no agent: it groups tickets.

  1. Click Create and set Type to Epic (no agent, groups subtasks).
  2. Write what the epic is for and click Create.
  3. 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.

In the parent ticket:

  1. Under Subtasks, type a title in New subtask title, or search an existing ticket to attach….
  2. 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.
  3. 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.

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.

When a plan is waiting for your sign-off, you can hand its execution to fresh agents instead of the one that wrote it:

  1. On the plan card, click Execute by subagent or Execute by loop (the second shows when orchestration is on).
  2. Pick a Model and Thinking level for the new agent, or keep Same as this ticket.
  3. Click Delegate.
ChoiceWhat happens
Execute by subagentA subticket, Execute plan: and the title, implements the plan from an empty context.
Execute by loopA 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.

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:

SettingDefaultWhat it does
Agent orchestrationon (Developer, Maintainer)Gives agents the playbook for splitting work. Off keeps every ticket solo.
Orchestrator worker modelsonnetThe model a child gets unless the orchestrator picks one: a frontier orchestrator over cheaper workers. Blank inherits the parent’s model.
Max orchestration children6How many children one orchestration may start (1 to 20). A plan that proposes more is refused.
Orchestrator self-approvaloffLets the orchestrator approve or correct its own children’s plans and answer their questions, instead of you.
Orchestrator permission delegationoffLets 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.

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.

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.

  1. Open the More actions menu in the header.
  2. 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.

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).