A hard request is often several smaller jobs. Workflow lets one turn plan itself, split into parallel work, and come back as a single result.

## One turn, orchestrated

Type `/workflow` and it arms your next message. The run happens in place, in the current thread, and your chat's own model becomes the conductor: it reads the request first and decides how much orchestration the work actually needs.

## Plan, fan out, come back

The conductor breaks the request into independent sub-tasks and runs them as parallel workers, each on its own engine, so a job that would have been one long sequential turn becomes several short ones happening at once. Up to four run at a time. As they return, the conductor checks each result and assembles the answer from what came back.

You can leave the routing to it or pin a sub-task to a specific engine, so "one Claude and one Codex on this" is a thing you can ask for rather than hope for.

## It decides how far to go

Not every request needs a swarm, so the conductor picks a mode for the run:

- **Answer directly**, in one turn with no workers, when the request does not warrant them.
- **Investigate and reply**, when it is a question: the workers dig, the conductor writes the answer, and nothing in your repository changes.
- **Propose and integrate**, when it is code: the workers draft the change and the conductor folds it into the project.

Writing to the repository is always an explicit decision, so by default a workflow answers rather than edits.

## Workers read, the conductor writes

Each worker runs in its own isolated scratch space and may read your repository but not change it. Only the conductor writes to the real project, it leaves the change unstaged so you review it before anything is committed, and it never runs git on your behalf.

If a worker fails, the conductor is the one that retries it, within a bounded number of passes, rather than letting a worker try to heal itself. A run also has a cost and step ceiling, and when it reaches one it stops and hands back what it has rather than running on.

## Grounded in the right context

Each worker boots from the path-scoped memories, rules and skills for the path its sub-task belongs to, plus a brief of the conversation so far. A parallel agent is not a context-blind one: it reads the same product knowledge a normal turn would, scoped to the work in front of it.

## The same engine behind the board

Workflow is the same conductor that runs a whole [Tasks board](/docs/studio/tasks) when you run it all at once. There, cards are clustered by what they touch, and groups that touch different files run in [parallel git worktrees](/docs/studio/board-settings#parallel-runs) with a branch each, while groups that would collide are merged into one sequential lane.

## Council's sibling

Workflow does the work. When you want several opinions on one question instead of one answer, that is [Council](/docs/studio/council). Both are armed the same way, on a single chat turn, from the composer.