docs(orchestration): polish wording in orchestration pages

* Make the 'Where parent and child agents can run' header explicit about
  the parent/child relationship.
* Tighten 'plan for itself plus a fleet of children' to 'plan for itself
  and the child agents it intends to spawn'.
* Replace 'jump straight to' with 'navigate directly to' in the agent
  notifications observability bullet.
* Reword the opening of multi-agent-runs.mdx so 'orchestrated run' is
  the subject and the surfaces are listed cleanly.
* Clarify how a local parent spawns cloud children: 'by specifying an
  environment for each child' and 'You can select any environment'.
* Rephrase the cancellation guidance: 'in many orchestrations, you want
  children to finish' and split out 'then cancel the parent'.

Co-Authored-By: Oz <oz-agent@warp.dev>

Author: oz-agent

src/content/docs/agent-platform/cloud-agents/orchestration/index.mdx

@@ -18,7 +18,7 @@ An orchestrated workflow always has one **parent agent** and one or more **child
 
 The parent and child each have an independent **run** with its own lifecycle, transcript, conversation, and credit usage. The management view, web app, and API all surface a parent alongside its children.
 
-### Where each side can run
+### Where parent and child agents can run
 
 The parent and child don't have to run in the same place. Orchestration supports three combinations:
 
@@ -84,7 +84,7 @@ A flat group of peer agents discover each other through messaging and coordinate
 
 When an agent runs in `orchestrate` mode (set by the `/orchestrate` slash command or the API's `mode: orchestrate` field), the agent **proposes** an orchestration plan and waits for approval before spawning any children. Use this to review the breakdown — number of children, prompts, environments, parallelism — before any children start. Once you approve, the parent starts spawning children.
 
-`orchestrate` mode is distinct from `plan` mode. A `plan`-mode agent produces a written plan for *itself* to execute. An `orchestrate`-mode agent produces a plan for itself plus a fleet of children.
+`orchestrate` mode is distinct from `plan` mode. A `plan`-mode agent produces a written plan for *itself* to execute. An `orchestrate`-mode agent produces a plan for itself and the child agents it intends to spawn.
 
 ## Observability
 
@@ -93,7 +93,7 @@ Because every parent and child is tracked as its own conversation or run, the ex
 * **[Managing cloud agents](/agent-platform/cloud-agents/managing-cloud-agents/)** - in the Warp app, local children appear in a child agent status card above the parent's input, while cloud children appear as their own rows in the management view.
 * **[Oz web app](/agent-platform/cloud-agents/oz-web-app/)** - the Runs page groups cloud children under the parent's row, and the parent's detail pane adds a **Sub-agents** tab.
 * **[Oz API](/reference/api-and-sdk/)** - list every descendant of a parent in one call and fetch any run with its conversation, transcript, and artifacts. See [Running orchestrated agents](/agent-platform/cloud-agents/orchestration/multi-agent-runs/#retrieving-conversations-and-artifacts).
-* **[Agent notifications](/agent-platform/capabilities/agent-notifications/)** - each child's state transitions generate notifications on the child's own conversation so you can jump straight to whichever one needs attention.
+* **[Agent notifications](/agent-platform/capabilities/agent-notifications/)** - each child's state transitions generate notifications on the child's own conversation, so you can navigate directly to whichever one needs attention.
 
 ## Related pages
 

src/content/docs/agent-platform/cloud-agents/orchestration/multi-agent-runs.mdx

@@ -5,7 +5,7 @@ sidebar:
   label: "Running orchestrated agents"
 ---
 
-Running orchestrated agents starts a parent Oz agent that can spawn child agents from the Warp app, Oz CLI, Oz web app, or Oz API. Use orchestrated runs to review a plan before fan-out, execute children locally or in the cloud, and inspect parent and child conversations as they work.
+An orchestrated run starts with a parent Oz agent that spawns one or more child agents. You can start a parent from the Warp app, the Oz CLI, the Oz web app, or the Oz API. Use orchestrated runs to review a plan before fan-out, execute children locally or in the cloud, and inspect parent and child conversations as they work.
 
 ## Before you start
 
@@ -34,7 +34,7 @@ Approve the plan to start spawning children. The parent's transcript renders eac
 
 ### Spawning cloud children from a local parent
 
-A local parent — a Warp Agent conversation in the desktop app — can spawn cloud children by passing an environment when it spawns them. The parent agent will ask you for the environment if it isn't already clear from context. Point it at any environment from your account or team.
+A local parent — a Warp Agent conversation in the desktop app — can spawn cloud children by specifying an environment for each child. The parent agent asks you for the environment if it isn't already clear from context. You can select any environment from your account or team.
 
 Cloud children inherit the parent's authentication; the same credit and credentials rules from the [Cloud agents overview](/agent-platform/cloud-agents/overview/) apply.
 
@@ -157,7 +157,7 @@ POST /api/v1/agent/runs/YOUR_RUN_ID/cancel
 Authorization: Bearer YOUR_API_KEY
 ```
 
-Cancelling the parent does **not** automatically cancel its children. This is intentional: many orchestrations want the children to finish even after the parent ends. To cancel everything, list the descendants first and cancel each one, then the parent:
+Cancelling the parent does **not** automatically cancel its children. This is intentional: in many orchestrations, you want children to finish even after the parent ends. To cancel everything, list the descendants and cancel each one, then cancel the parent:
 
 ```bash
 # List every descendant of the parent, then cancel each.