Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 13 additions & 6 deletions src/content/docs/platform/orchestration/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ sidebar:
import VideoEmbed from '@components/VideoEmbed.astro';
import { VARS } from '@data/vars';

Multi-agent orchestration lets one agent spawn and coordinate other agents to parallelize work, delegate specialized tasks, or verify another agent's output. The parent/child model works from the Warp app, the [{VARS.WARP_AGENT_CLI}](/agents/cli/oz-cli/), and the [{VARS.WARP_PLATFORM_API}](/factories/api-and-sdk/), and supports local, cloud, and mixed execution.
Multi-agent orchestration in Warp lets a parent agent spawn and coordinate child agents to work in parallel, handle specialized tasks, or verify output. The parent/child model works from the Warp app, the [{VARS.WARP_AGENT_CLI}](/agents/cli/oz-cli/), and the [{VARS.WARP_PLATFORM_API}](/factories/api-and-sdk/), and supports local, cloud, and mixed execution.

Watch this walkthrough to see how a cloud agent can coordinate a team of agents in the cloud.

Expand Down Expand Up @@ -83,27 +83,34 @@ Use messages for coordination signals - handoffs, decisions, blocked-on-input re

## Common patterns

The following patterns show common ways to structure parent and child agents, depending on whether you need parallel execution, review, dependency ordering, or loose coordination.
| Pattern | When to use it | What Warp provides |
| --- | --- | --- |
| [Supervisor and worker](#supervisor--worker) | Divide a task into work items with one agent owning coordination. | A [parent agent](#the-parentchild-model) assigns work to children and collects results. |
| [Fan-out and fan-in](#fan-out--fan-in) | Run a refactor or migration across independent modules or targets. | Parallel child runs and [lifecycle events](#run-state-transitions) let the parent wait and combine results. |
| [Critic and verifier](#critic--verifier) | Check a proposed solution before accepting it, when correctness matters more than throughput. | The critic child reports its notes in its final output, and the parent sends follow-up instructions through [messaging](#messaging-between-agents). |
| [Review swarm](#review-swarm-cloud--cloud) | Review multiple open PRs from a scheduled or webhook-triggered run. | [Cloud children](#where-parent-and-child-agents-can-run) run reviews in parallel; the parent collects their findings. |
| [DAG](#dag) | Subtasks must wait for upstream results, such as build, test, then deploy. | The parent observes child [state transitions](#run-state-transitions) before starting dependent work. |
| [Swarm](#swarm) | Coordinate a flat group of agents without a strict hierarchy. | The parent acts as a coordinator; agents use [messaging](#messaging-between-agents) for coordination signals. |

### Supervisor / worker

A parent supervisor agent breaks the task into a queue of work items, spawns worker children to claim and complete each item, and writes a summary when the queue is empty. Use this when the task is naturally divisible and you want a single agent to own coordination.
A parent supervisor agent breaks the task into a queue of work items, spawns worker children to claim and complete each item, and writes a summary when the queue is empty.

### Fan-out / fan-in

The parent spawns N children in parallel, each with a sharded prompt (one module, one file set, one test target, one model), then waits for all of them to complete and merges their results. Use this for large refactors, repo-wide migrations, or running the same task across multiple targets.
The parent spawns N children in parallel, each with a sharded prompt (one module, one file set, one test target, one model), then waits for all of them to complete and merges their results.

### Critic / verifier

The parent (the "writer") proposes a solution, then spawns a critic child to review it. The critic returns notes; the writer revises; the cycle repeats until the critic approves or a budget is exhausted. Useful when correctness matters more than throughput.
The parent (the "writer") proposes a solution, then spawns a critic child to review it. The critic returns notes; the writer revises; the cycle repeats until the critic approves or a budget is exhausted.

### Review swarm (cloud → cloud)

A [scheduled](/platform/triggers/scheduled-agents/) or webhook-triggered parent spawns one cloud child per open pull request to run reviews in parallel. Each child posts its findings as a comment and exits. The parent fans in the results and posts a summary back to the triggering system.

### DAG

The parent encodes a directed acyclic graph of subtasks where some nodes depend on the outputs of others. It spawns ready nodes, waits on their state transitions, and spawns dependents as upstream nodes complete. Use this when the workflow has explicit ordering constraints (build → test → deploy, for example).
The parent encodes a directed acyclic graph of subtasks where some nodes depend on the outputs of others. It spawns ready nodes, waits on their state transitions, and spawns dependents as upstream nodes complete.

### Swarm

Expand Down
Loading