> For the index of every page in Orbital's docs, read https://docs.beta.runorbital.dev/llms.txt.

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

```dot title="parallel-reviews.dot"
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](/reference/node-types/#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.](/screenshots/workflow-editor-roles.webp?v=3ff23d4252)

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

:::caution
If a branch fails and the fan-out has no conditioned failure edge, the run is Paused. It waits for you and names the failed branches. Add a failure edge on the fan-out when partial completion has a safe recovery. See [Runs](/runs/).
:::

## 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](/projects/).

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](/parallel-reviews.zip) 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.](/parallel-reviews.svg?v=13456a7d81)

```dot title="parallel-reviews.dot"
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](/examples/parallel-reviews/parallel-reviews.dot)

## 2. Validate it

```sh
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`.

## Related

- [Fan-out](/reference/node-types/#fan-out) and [fan-in](/reference/node-types/#fan-in): what the two steps take and do.
- [Parallel branches](/reference/history-and-threads/#parallel-branches): the exact rules for branches, their context and their results.
- [Pass context between steps](/workflows/pass-context/): why a branch cannot read its sibling's outputs.
- [Give steps a role](/roles/configure-steps/): give each branch its own role.