Workflow

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 scratch space. It reads your repository for context and writes only its own output files there; the conductor reviews that output and is the only one that 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.

How strictly a worker is kept out of your repository depends on its engine:

• Codex workers run in Codex's own sandbox, rooted in the scratch space. They can read your repository, but writing to it is not possible.
• Every other engine is told the same contract, and Pathrule watches every file a worker writes. A worker that writes anywhere outside its scratch space is stopped as failed, the run panel says it wrote outside its scratch space, and nothing it produced is integrated. The write itself has already happened, so review your working tree if you see that message.

If you want a run that can only read, ask the Council instead: its members run read-only turns that the engine itself enforces.

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 with relevant path-scoped memories and rules for its sub-task, the names of available skills, and a brief of the conversation so far. A skill's instructions are loaded when invoked. The worker starts with knowledge 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 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 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. Both are armed the same way, on a single chat turn, from the composer.