Fast follow: orchestration launch docs updates

AGENTS.md

@@ -177,6 +177,35 @@ Use formatting consistently to distinguish different types of content:
 - File naming: lowercase, hyphens, descriptive (`agent-mode-code-diff.png`, not `Screenshot 2026-03-15.png`)
 - Store PNGs in `src/assets/<section>/` (Astro optimizes them) and GIFs in `public/assets/<section>/` (to bypass optimization). See the "Assets" section below for the full convention.
 
+#### Screenshot placement guidelines
+Use screenshots to clarify product surfaces, configuration points, or visual states that are hard to understand from prose alone. Don't add screenshots for every step in a straightforward procedure.
+
+**Good screenshot placements:**
+- **After the concept or behavior is introduced** — Place the screenshot immediately after the paragraph that explains the UI or state it shows.
+- **Near configuration instructions** — Show settings panels, side panes, or menus where users make choices.
+- **Near status or result explanations** — Show outputs, references, badges, progress indicators, or completion states that help users recognize success.
+- **At the start of visual feature pages** — Use a broad orientation screenshot early when the page explains a new surface or layout.
+
+**Avoid:**
+- Repeating the same surface in multiple screenshots unless each image shows a meaningfully different state.
+- Screenshots that duplicate obvious text instructions without adding visual context.
+- Screenshots that include sensitive workspace data, private repo names, tokens, customer data, or personal information.
+- Images with stale UI labels, hidden feature flags, or unfinished internal-only surfaces.
+
+#### Screenshot sizing standards
+Use consistent screenshot widths so docs pages feel visually balanced. Crop unnecessary empty space before resizing, then choose the closest standard size.
+
+**Standard widths:**
+- **Large screenshots: default content width** — Use normal `<figure>` or Markdown image rendering for full-window, full-pane, or broad product-surface screenshots where the surrounding layout matters. In legacy GitBook screenshots, this was usually `563px`.
+- **Medium screenshots: ~375px** — Use for narrow UI surfaces such as popovers, command menus, side panes, dropdowns, and focused interaction flows. This is the preferred constrained size for most small Warp UI screenshots.
+- **Small screenshots: ~300-350px** — Use for tightly cropped controls, chips, buttons, tooltips, and small menus. Use a smaller width only when the UI remains legible and the crop is intentionally compact.
+
+**Rules:**
+- **Avoid arbitrary widths** — Choose the nearest standard size instead of one-off values. If a screenshot needs a different size, the reason should be clear from the UI being shown.
+- **Keep sequences consistent** — Screenshots in the same section or step sequence should use the same width unless they show meaningfully different UI surfaces.
+- **Preserve legibility** — Text in the screenshot must remain readable at the chosen size on the docs page.
+- **Prefer the default figure size for large screenshots** — Only constrain width when the screenshot is a narrow UI element that looks oversized at full content width.
+
 #### Image caption guidelines
 Captions orient the reader — they identify what the image shows so the reader knows where to look. They are not a place for instructions, marketing language, or exhaustive descriptions.
 

src/content/docs/agent-platform/agent-memory/index.mdx

@@ -1,79 +1,79 @@
 ---
 title: Agent Memory (Research Preview)
 description: >-
-  Agent Memory is a persistent, cross-harness memory layer for agents in
-  Oz, including the Warp Agent, Claude Code, and Codex.
+  Agent Memory gives agents in Oz persistent memory across supported harnesses,
+  including the Warp Agent, Claude Code, and Codex.
 sidebar:
   label: "Agent Memory (Research Preview)"
 ---
 :::caution
 Agent Memory is in **research preview** and is enabled per team for design partners. [Join the waitlist](https://warp.dev/oz/agent-memory#waitlist) to request access for your team.
 :::
 
-Agent Memory is a persistent memory layer that lives on Oz and is shared across every supported agent harness — the built-in Warp Agent, Claude Code, Codex, and others as they're added. Agents read from and write to it as they run, so durable facts, decisions, and outcomes from one conversation are available to the next — regardless of which harness, machine, or teammate triggers it.
+Agent Memory is a persistent memory system that lives on Oz and is shared across every supported agent harness, including the built-in Warp Agent, Claude Code, Codex, and others as they're added. Agents read from and write to this memory system as they run, so durable facts, decisions, and outcomes from one conversation are available to the next — regardless of which harness, machine, or teammate triggers the work.
 
 Memory creation and retrieval are asynchronous and run in the background, so they don't consume tokens or add latency to the active task.
 
-[Join the Agent Memory waitlist](https://warp.dev/oz/agent-memory#waitlist)
+[Join the Agent Memory waitlist](https://warp.dev/oz/agent-memory#waitlist).
 
 ## Key features
 
-* **Cross-harness memory** — One memory layer shared across the Warp Agent, Claude Code, Codex, and other harnesses as they're added. Third-party harnesses are covered when they run as cloud agents.
-* **Both local and cloud agents** — Supports interactive local agents in Warp and background cloud agents.
-* **Asynchronous by design** — Memory creation runs after a conversation ends. Retrieval runs in the background during a run. Neither consumes tokens or adds latency to the active task.
-* **Automatic memory from conversations** — When a conversation ends, Oz extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict.
-* **Agent-scoped, shareable stores** — By default, each agent has its own memory store. Stores can also be shared across multiple agents, or across an entire team, when the same knowledge should travel with the work.
-* **Per-agent access and instructions** — Attach stores to specific agents with read-only or read-write access. Per-store instructions tell each agent how and when to use the store.
-* **Fully accessible via API** — Memories and stores can be read, created, updated, and deleted through the [Oz API](/reference/api-and-sdk/).
-* **Traceability** — For any agent run, you can see which memories influenced it.
-* **Auditability** — Every change to a memory is recorded, so the full history of any memory can be inspected.
-* **Self-hostable** — Enterprises can run Agent Memory on a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance to meet security, privacy, and compliance requirements.
+* **Cross-harness memory** - One memory system is shared across the Warp Agent, Claude Code, Codex, and other harnesses as they're added. Third-party harnesses are covered when they run as cloud agents.
+* **Both local and cloud agents** - Supports interactive local agents in Warp and background cloud agents.
+* **Asynchronous by design** - Memory creation runs after a conversation ends. Retrieval runs in the background during a run. Neither consumes tokens or adds latency to the active task.
+* **Automatic memory from conversations** - When a conversation ends, Oz extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict.
+* **Agent-scoped, shareable stores** - By default, each agent has its own memory store. Stores can also be shared across multiple agents, or across an entire team, when the same knowledge should travel with the work.
+* **Per-agent access and instructions** - Attach stores to specific agents with read-only or read-write access. Per-store instructions tell each agent how and when to use the store.
+* **Fully accessible via API** - Memories and stores can be read, created, updated, and deleted through the [Oz API](/reference/api-and-sdk/).
+* **Traceability** - Memory retrievals are recorded so teams can inspect which memories contributed to a run's context.
+* **Auditability** - Every change to a memory is recorded so teams can inspect how a memory has changed over time.
+* **Self-hosting support** - Enterprises can run Agent Memory on a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance to meet security, privacy, and compliance requirements.
 
 ## Where Agent Memory runs
 
-Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on the same Oz instance that hosts your agents — either Warp-hosted Oz (the default) or a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance that your team operates inside its own perimeter. The same memory is accessible from any agent you run on Oz:
+Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on the same Oz instance that hosts your agents. That instance can be Warp-hosted Oz (the default) or a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance that your team operates inside its own perimeter. The same memory is accessible from any agent you run on Oz:
 
 * The local Warp Agent.
 * Cloud agents triggered from the CLI, web app, schedules, or integrations.
-* Third-party harnesses running as cloud agents — Claude Code, Codex, and others as they're added. (Running third-party harnesses locally isn't supported during the research preview.)
+* Third-party harnesses running as cloud agents: Claude Code, Codex, and others as they're added. (Running third-party harnesses locally isn't supported during the research preview.)
 
 Memory stays bound to its owner (a user or a team), independent of which harness reads or writes.
 
 ## Memory stores
 
-A memory store is a named collection of memories. By default, each agent has its own store and writes to it as it runs. Stores can also be shared across multiple agents when they need the same knowledge, and across teammates when knowledge should travel with the team.
+A memory store is a named collection of memories. By default, each agent has its own store that it writes to as it runs. Stores can also be shared across multiple agents when they need the same knowledge, and across teammates when knowledge should travel with the team.
 
-* **Personal stores** — Owned by a user. Hold preferences, working notes, and individual patterns.
-* **Team stores** — Owned by a team. Hold shared knowledge like deployment runbooks, code review conventions, or on-call procedures. Every team member, and any agent the team authorizes, can read from the same store.
+* **Personal stores** - Owned by a user. Store memories about preferences, working notes, and individual patterns.
+* **Team stores** - Owned by a team. Store shared knowledge like deployment runbooks, code review conventions, or on-call procedures. Every team member, and any agent the team authorizes, can read from the same store.
 
 Use multiple stores to keep contexts separate, and share stores across agents when needed. For example, a code review agent can have its own store of review patterns, while a repo-specific store of architectural decisions is shared between the code review agent and a Sentry triage agent so both reason about the same codebase.
 
 ## Automatic memory from conversations
 
 When a conversation finishes, Oz extracts durable facts, learnings, and outcomes from the transcript and writes them as memories. Memory creation runs in the background after the conversation ends, so it doesn't consume tokens or add latency during that run.
 
-* **Memories evolve over time** — Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories.
+* **Memories evolve over time** - Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories.
 
-You can also explicitly ask an agent to remember something during a conversation, and it lands in the appropriate store.
+You can also explicitly ask an agent to remember something during a conversation. Oz saves that memory to the appropriate store.
 
 ## How agents use memory
 
 When an agent starts a task, Oz searches the stores the agent can access for relevant memories and injects them as context. The search runs in the background, so the agent only sees the memories returned. Agents can also retrieve additional memories on demand mid-conversation when they determine it's relevant, similar to how they consult [Rules](/agent-platform/capabilities/rules/) or [Codebase Context](/agent-platform/capabilities/codebase-context/). You don't need to write retrieval queries or pre-load memory.
 
 ## Attaching memory to your agents
 
-Attach stores to agents with read-only or read-write access. Each attachment can include per-store instructions that tell the agent how and when to use the store — for example, "Reference this store for team naming conventions" or "Write a new memory after each successful deployment." Without instructions, the agent can access the store but won't know when to read from or write to it.
+Attach stores to agents with read-only or read-write access. Each attachment can include per-store instructions that tell the agent how and when to use the store. For example, use instructions like "Reference this store for team naming conventions" or "Write a new memory after each successful deployment." Without instructions, the agent can access the store but won't know when to read from or write to it.
 
 ## Join the waitlist
 
 Agent Memory is rolling out to design partner teams during research preview. [Join the waitlist](https://warp.dev/oz/agent-memory#waitlist) to request access.
 
 ## Related pages
 
-* [Codebase Context](/agent-platform/capabilities/codebase-context/) — Let agents understand your codebase through semantic indexing.
-* [Rules](/agent-platform/capabilities/rules/) — Define global and project-level guidelines that shape agent behavior.
-* [Skills](/agent-platform/capabilities/skills/) — Reusable, scoped instructions that teach agents how to perform specific tasks.
-* [Agent profiles and permissions](/agent-platform/capabilities/agent-profiles-permissions/) — Control what permissions and autonomy agents have.
-* [Cloud agents overview](/agent-platform/cloud-agents/overview/) — Run background agents with team-wide observability.
-* [Self-hosting overview](/agent-platform/cloud-agents/self-hosting/) — Run Oz, and Agent Memory along with it, on your own infrastructure.
-* [Oz API and SDK](/reference/api-and-sdk/) — Read, create, update, and delete memories and stores programmatically.
+* [Codebase Context](/agent-platform/capabilities/codebase-context/) - Let agents understand your codebase through semantic indexing.
+* [Rules](/agent-platform/capabilities/rules/) - Define global and project-level guidelines that shape agent behavior.
+* [Skills](/agent-platform/capabilities/skills/) - Reusable, scoped instructions that teach agents how to perform specific tasks.
+* [Agent profiles and permissions](/agent-platform/capabilities/agent-profiles-permissions/) - Control what permissions and autonomy agents have.
+* [Cloud agents overview](/agent-platform/cloud-agents/overview/) - Run background agents with team-wide observability.
+* [Self-hosting overview](/agent-platform/cloud-agents/self-hosting/) - Run Oz, and Agent Memory along with it, on your own infrastructure.
+* [Oz API and SDK](/reference/api-and-sdk/) - Read, create, update, and delete memories and stores programmatically.

src/content/docs/agent-platform/capabilities/skills.mdx

@@ -413,7 +413,7 @@ These same skills also appear as suggested agents in the [Oz web app](/agent-pla
 
 ## Suggested skills from Agent Memory
 
-Promoting recurring patterns from [Agent Memory](/agent-platform/agent-memory/) into reviewable skill drafts is in design as part of the research preview. See the Agent Memory page for current status.
+Promoting recurring patterns from [Agent Memory](/agent-platform/agent-memory/) into reviewable skill drafts is in design as part of the research preview. See the Agent Memory page for a current status.
 
 ## Invoking skills with a prompt
 

src/content/docs/agent-platform/cli-agents/claude-code.mdx

@@ -73,7 +73,7 @@ Claude Code supports the full set of Warp's agent integration features:
 
 * [How to set up Claude Code](/guides/external-tools/how-to-set-up-claude-code/) — step-by-step setup guide
 * [Claude Code in Warp](https://www.warp.dev/agents/claude-code) — product overview
-* [Third-Party CLI Agents Overview](/agent-platform/cli-agents/overview/)
+* [Third-Party CLI Agents Overview](/agent-platform/cli-agents/overview/) — supported CLI agent integrations
 * [Claude Code with Oz](/agent-platform/cloud-agents/harnesses/claude-code/) — Claude Code as a cloud harness
-* [OpenCode](/agent-platform/cli-agents/opencode/)
-* [Codex](/agent-platform/cli-agents/codex/)
+* [OpenCode](/agent-platform/cli-agents/opencode/) — OpenCode in Warp
+* [Codex](/agent-platform/cli-agents/codex/) — Codex in Warp

src/content/docs/agent-platform/cli-agents/codex.mdx

@@ -48,7 +48,7 @@ Codex supports the full set of Warp's agent integration features:
 
 * [How to set up Codex CLI](/guides/external-tools/how-to-set-up-codex-cli/) — step-by-step setup guide
 * [Codex in Warp](https://www.warp.dev/agents/codex) — product overview
-* [Third-Party CLI Agents Overview](/agent-platform/cli-agents/overview/)
+* [Third-Party CLI Agents Overview](/agent-platform/cli-agents/overview/) — supported CLI agent integrations
 * [Codex with Oz](/agent-platform/cloud-agents/harnesses/codex/) — Codex as a cloud harness
-* [Claude Code](/agent-platform/cli-agents/claude-code/)
-* [OpenCode](/agent-platform/cli-agents/opencode/)
+* [Claude Code](/agent-platform/cli-agents/claude-code/) — Claude Code in Warp
+* [OpenCode](/agent-platform/cli-agents/opencode/) — OpenCode in Warp