Run agents in parallel

This guide shows you how to run several agents at the same time without them overwriting each other.

The unit of isolation is the space, not the agent

When work starts in a space, Control Center provisions one copy-on-write checkout per registered repo under that space’s own root, on a branch derived from the workspace’s branch template. Each agent in the space then gets its own overlay working directory — but the overlays share that space’s repos/ directory.

So:

Two agents in different spaces work in different checkouts, on different branches. That is real isolation.
Two agents in the same space work in the same checkout, on the same branch. Their overlay paths differ, so the dispatch path lock (which serialises runs only when they request the identical working directory) does not serialise them either. They can write the same files at the same time.

The rule that follows: one space per parallel task.

Run tasks in parallel — separate spaces

Open a space with agent A and send it a task.
Open a second space with agent B and send it a different task.
Both dispatch immediately, each in its own space checkout on its own branch.

This is the recipe to use whenever the agents will be editing files.

Work together in one space — several mentions

In a single space, @-mention more than one agent:

@alice refactor the auth module. @bob review what alice lands.

Both agents dispatch in parallel and stream into the same space, tagged by sender. Because they share the space’s checkout, use this for collaboration — one writing, one reading, or two agents reasoning about the same tree — not for two independent edits.

Fan out from a pipeline

The built-in pr_review template is the shipped example of a fan-out: several reviewer nodes run concurrently off one trigger and a Consolidate (join) node folds their findings into one report. Run it from the pipelines screen and every reviewer dispatches in parallel.

Watch them run

Observability → Live (sidebar footer → Observability, then the Live tab) shows this workspace’s agent roster, re-ticking every second: status (running / idle / parked / aborted), what each one is doing, tokens and cost for its latest run and a kill control for a running process. Selecting a row docks a live transcript drawer.

Settings → Workspace → Agents shows the same roster with a different, attention-first status vocabulary derived from each agent’s run history — running, blocked, failed, idle, never run — sorted so anything needing attention floats to the top. Each agent’s Logs tab holds its own run history.

Both surfaces are scoped to the active workspace.

Handle conflicts

Across spaces, each space is on its own branch, so a collision surfaces as an ordinary Git merge conflict when you merge the second pull request. Resolve it the way you would any merge conflict.

Inside one space there is no branch boundary and no lock: the agents are writing the same files live and the loser is simply overwritten. If you find yourself wanting two agents to edit in one space, split the work into two spaces instead.

To reduce collisions either way:

Give each agent a distinct scope — different files, different modules.
Use the code graph to check what a change touches before dispatching. See Search code with the code graph.
Review and merge each agent’s pull request promptly.

Resource considerations

Each running agent costs:

A space checkout — negligible on disk while copy-on-write is available, a full git worktree otherwise
A process on the server host
Model tokens, which accumulate per agent

Costs land in Observability → Insights. Note that a normal interactive turn has no spend cap; see Manage costs for the two commands that do have one.