Parallel agents
Run independent agents together in isolated cloud lanes.
Agents in a workflow normally run one after another: the spine goes top to bottom, one agent finishes its steps before the next one starts. A parallel group is the exception: two or more agents that run at the same time instead, each in its own session, each working through its own steps independently. Parallel groups run in the cloud only.
A "Run together" block
In the editor, add an agent in parallel from an existing agent's menu, or from the footer button under the last agent in the spine. Either one wraps the agent into a Run together block and adds a second lane next to it. Add more lanes the same way; each lane is an ordinary agent underneath, same slot, harness, model, and step list as a standalone agent, just laid out side by side with its siblings instead of stacked below them.
A lane's inspector panel has a Remove from group action. Removing a lane peels it back out to a standalone agent. If that leaves the group with only one lane left, the group itself dissolves and the remaining agent goes back to being an ordinary spine entry, with no trace of ever having been parallel.
Groups don't nest. A lane is a plain agent; you can't put another Run together block inside one.
Parallel groups have four beta constraints: the whole run must target Cloud; existing sessions cannot be bound to any slot in the run; an Include step cannot appear inside a lane; and a goal that tries to pause for approval fails that lane instead. Use new sessions and keep approval-dependent work outside the group.
What a lane can see
The same visibility rule that governs the rest of a workflow applies here. A step can reference an earlier Write output step's fields from any agent that ran strictly before it in run order: an earlier standalone agent, or every lane of an earlier parallel group in full. A step can never reference a sibling lane running in the same group. Lanes run concurrently, so there's no "earlier" between them, and the editor's reference popover won't suggest a sibling lane's output even if you know its step name.
Once the whole group finishes, every lane's outputs become visible to whatever runs after the group, the same as any other earlier agent's outputs would be. The block is the unit: steps inside it are invisible to each other across lanes, but the block as a whole behaves like any other step in the spine once you're referencing it from further down.
When a lane fails
A lane's steps can fail on their own terms. An on-fail policy of stop inside one lane fails that lane, it doesn't reach across and stop its siblings. The rest of the group runs to completion regardless of what happened in the lane that failed:
- Every lane finishes (or fails) independently.
- Once all of them are done, the group joins. If every lane succeeded, the run continues to whatever comes after the group. If any lane failed, the join fails the run. The steps after the group never run, and the lane branches are not merged into the run's main worktree.
So a failing lane doesn't cut its siblings off mid-work, and it doesn't let the run quietly continue past the group either. The run view shows this honestly: a failed lane next to a sibling that finished cleanly, and nothing after the block if the join failed.
There's no per-group choice between "let the others finish" and "stop everything the moment one lane fails." Siblings always run to completion, full stop. If you need one lane's failure to actually stop another lane's work, that isn't what a parallel group is for.
Isolation, per lane
Execution and isolation covers the fresh-worktree-per-run default for cloud runs. A parallel group extends that per lane: every lane that uses the repository gets a separate worktree and branch based on the run-level worktree. Siblings do not see one another's uncommitted changes while they run.
After every lane succeeds, Proliferate merges the lane branches back into the run-level worktree in lane order. Steps after the group, including Open PR, see that combined result. If those merges conflict, the run fails at the join and no later step runs; conflicting changes are never silently discarded.