Run steps in parallel

Run independent review steps at once and collect their results

Run independent steps at the same time with a fan-out, then collect their results with a fan-in. In practice, independent work means reviews.

reviews [shape="component", max_parallel="2"]
collect [shape="tripleoctagon", prompt="Summarise these reviews: {{ context.parallel.results['0'].context.assessment }} and {{ context.parallel.results['1'].context.assessment }}"]
reviews -> clarity
reviews -> risks
clarity -> collect
risks -> collect

Orbital keeps each branch’s context apart, but not its files. Two branches that write to the same checkout will fight over it.

How the fan-out works

reviews is a component, a fan-out. Each of its bare outgoing edges starts a branch, up to max_parallel at a time. Every branch must reach the same tripleoctagon fan-in without a cycle, a nested fan-out or an edge that leaves the branch.

Each branch keeps its own context, so clarity cannot read what risks produced. After the fan-in, results arrive in edge order under parallel.results, with node, outcome, failure reason and context. The fan-in prompt reads {{ context.parallel.results['0'].context.assessment }}. The index is quoted, and the complete example validates that spelling.

The editor shows a fan-out step with a maximum of three, three parallel steps below it, and a prompted fan-in step that combines their findings. — Every branch leaves the fan-out and meets again at the fan-in.

Set max_parallel to the number of steps your harness can run at once. If branches must write, give them separate files and review the combined result after the fan-in.

Before you start

You need a harness you have signed in to that can run two steps at once, and a project in Orbital. Any project works. It does not need to be a Git repository, unless you run the example with Codex, which needs one. See Projects and folders.

The branches share a folder, so every step has the Read only tool access and cannot change it.

1. Download the example

Download the example and unpack it into ~/.orbital/workflows/. Keep every relative path.

reviews forks into clarity and risks; both meet at collect, which summarises them and reaches done.

digraph reviews {
  graph [version="1", entry="reviews"]
  reviews [shape="component", max_parallel="2"]
  clarity [tool_access="Read only", prompt="Review the goal for clarity.", outputs="assessment:text"]
  risks [tool_access="Read only", prompt="Review the goal for risks.", outputs="assessment:text"]
  collect [shape="tripleoctagon", tool_access="Read only", prompt="Summarise these reviews: {{ context.parallel.results['0'].context.assessment }} and {{ context.parallel.results['1'].context.assessment }}"]
  done [shape="Msquare"]
  reviews -> clarity
  reviews -> risks
  clarity -> collect
  risks -> collect
  collect -> done
}

Download parallel-reviews.dot

2. Validate it

orbital validate ~/.orbital/workflows/parallel-reviews.dot

Validate again whenever you change where a branch starts or ends.

3. Run it

Choose New task, pick any project, and choose the parallel-reviews workflow and your harness. One project serves every example. Write the goal both reviews should assess, and start the run.

Both reviews run. Their assessment outputs stay inside parallel.results. The collect step summarises both before done.

Fan-out and fan-in: what the two steps take and do.
Parallel branches: the exact rules for branches, their context and their results.
Pass context between steps: why a branch cannot read its sibling’s outputs.
Give steps a role: give each branch its own role.