Parallel agents

There are two ways to run more than one agent at once. Give each stream of work its own workspace so they never share a checkout or branch, or let one agent hand a scoped piece to a delegated session inside the workspace it is already in. Reach for separate workspaces when the outputs are independent, and for a delegated session when the work is part of the same task.

Parallel workspaces

Each workspace has its own checkout and branch, so two agents can work at the same time without fighting over the same working directory — even though they share one runtime (the local AnyHarness runtime, or your cloud sandbox). The unit of integration stays the branch or pull request: review the diff before it merges.

Good parallel work:

• Fix independent bugs in separate workspaces.
• Add tests in one workspace while another implements the feature.
• Compare two implementation approaches side by side.
• Review one diff while another workspace continues follow-up work.

Risky parallel work:

• Multiple agents editing the same files, which just moves the merge conflict later.
• Broad refactors without a plan someone has read.
• Database migrations without explicit sequencing.
• Release or infrastructure work without a human approval step.

Delegated sessions

A delegated session is a full Proliferate session that a parent agent spawns to handle a focused piece of the task it is already working on. It runs in the same workspace — same checkout, same files, same git state — so there is no second environment to provision, and it works the same way across every supported harness.

Not the same as native subagents

Some harnesses spawn their own helper agents inside a single session — a Claude Code Task agent, a Codex collaboration child, a Cursor task agent. Those are native subagents: they stay inside the parent session and show up in its activity roster. A delegated session is different — it is a separate Proliferate session with its own tab, receipts, Wake, and lifecycle. This page is about delegated sessions; for what a harness does natively, see its agent page.

Delegate when the sub-task is scoped and benefits from running on its own:

• Trace how a subsystem works before deciding how to change it.
• Run a focused review pass on a plan or a diff.
• Try two approaches in parallel, then compare the results before picking one.
• Split a larger task into worker pieces that do not need to share context.

Skip a delegated session when a single, direct conversation would be simpler. Spawning a helper adds coordination overhead you do not always need.

Limits

• A parent session can have up to 8 active delegated sessions at a time.
• A delegated session cannot spawn its own. Delegation is one level deep.
• A delegated session starts fresh and does not carry the parent's connected integrations. It begins with its own core agent tools.

How delegated sessions appear

Delegated sessions come from a product tool set the runtime injects into a parent session; they are not something you install or configure. When your agent creates one, it lands in the transcript as a receipt you can expand to see the child's name and the prompt it was given.

The child's tab groups next to its parent in the top tab strip under a small collapsible pill (for example, "3 agents"), so delegated work is easy to tell apart from tabs you opened yourself.

The composer's Agents popover lists every delegated session with its current status and a Wake button, so you can be notified the moment one finishes. When a delegated session that scheduled a wake completes a turn, the parent's transcript gets a short receipt you can click through to open that session and read what it found.

Delegated sessions work the same way across every supported harness. See Agents for what each one does natively.