diff --git a/src/content/docs/platform/orchestration/index.mdx b/src/content/docs/platform/orchestration/index.mdx
index 2169e4983..dd9347364 100644
--- a/src/content/docs/platform/orchestration/index.mdx
+++ b/src/content/docs/platform/orchestration/index.mdx
@@ -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.
 
@@ -83,19 +83,26 @@ 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)
 
@@ -103,7 +110,7 @@ A [scheduled](/platform/triggers/scheduled-agents/) or webhook-triggered parent
 
 ### 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