diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx
index 5eeb05be..d1713d6b 100644
--- a/src/content/docs/factories/how-factories-work.mdx
+++ b/src/content/docs/factories/how-factories-work.mdx
@@ -1,21 +1,73 @@
 ---
 title: How Warp Factories work
 description: >-
-  Warp Factories move work through triage, spec, implementation, review, and
-  verification, with humans in the loop and every step defined as code.
+  A factory's foreman routes each work item through triage, specification,
+  implementation, and review, with humans making the key decisions.
 sidebar:
   label: "How Factories work"
 ---
 
-[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC.
+A factory runs two connected loops:
 
-This page absorbs and supersedes the existing conceptual content at `platform/software-factory.mdx` (inner loop / outer loop, agent roles: triage, spec, implementation, reviewer) — see that file for source material and the redirect from `/platform/software-factory` added in `vercel.json`.
+* The **inner loop** moves each work item from intake to a human handoff.
+* The **outer loop** uses evidence from completed work to improve the factory itself.
 
-Cover, per the launch blog draft:
-- Work item lifecycle: Triage → Spec → Implement → Review → Verify
-- The foreman/orchestrator agent and how it dispatches subagents
-- Human-in-the-loop decision points
-- Factory definitions as code (version-controlled repos, agent roles, skills, MCPs, permissions)
-- Natively multi-model and multi-harness
+A **work item** is one unit of engineering work, such as an issue, support request, pull request, or Factory MCP task. It keeps its identity while specialized agents contribute to it through separate runs.
 
-Cross-link to Configure your Factory and Connect your Factory for the procedural follow-through.]
+## The inner loop: intake to handoff
+
+The **foreman** coordinates every work item. It routes work between the specialized agents, passes each one the context it needs, and continues existing agent conversations instead of starting new ones. The specialized agents keep narrow responsibilities, and each of their runs stays distinct in run history. See [factory agents](./factory-agents) for the role definitions.
+
+Not every work item needs every stage. The foreman picks the shortest path that still meets your quality policy: it skips stages when the work is already well defined, starts partway through when enough context exists, and sends work back to an earlier agent when revisions are needed.
+
+```mermaid
+flowchart LR
+  Intake[Intake] --> Foreman[Foreman]
+  Foreman --> Triage[Triage]
+  Triage --> Decision{Specification needed?}
+  Decision -->|Yes| Spec[Specify]
+  Decision -->|No| Implement[Implement]
+  Spec --> Approval["Human review<br/>(default policy)"]
+  Approval --> Implement
+  Implement --> Review[Review and verify]
+  Review --> Revision{Revision needed?}
+  Revision -->|Yes| Implement
+  Revision -->|No| Handoff["Human handoff<br/>(default policy)"]
+  Handoff --> Complete[Complete]
+```
+
+### Stages
+
+* **Intake** - A work item enters from an integration, an automation, a direct run, or the [Factory MCP](./factory-mcp), and keeps its source context.
+* **Triage** - Researches the request, reproduces it when needed, and defines its scope and complexity. Skipped when the request is already well bounded.
+* **Specification** - Defines product behavior, technical constraints, and validation criteria. Skipped for localized changes.
+* **Implementation** - Makes the code change on a branch and opens a pull request with test and visual evidence.
+* **Review and verification** - Checks the change against the requirements, tests, and security expectations, and sends findings back to implementation. Its verdict is advisory.
+* **Human handoff** - The factory presents the result, its evidence, and any findings, and a person decides what happens next.
+* **Complete or Cancelled** - The work item ends when the factory finishes its work, or is marked **Cancelled** when someone stops it.
+
+## Work items and agent runs
+
+A work item is the unit your team follows through the factory; an agent run is one agent execution inside it. The first factory-agent run creates the work item, and child runs record each stage's actions and outputs inside that same work item.
+
+The work item's **stage** shows progress at a glance. It reflects the most recently active role, so it can move backward during a revision or skip ahead. Run history is the complete execution record.
+
+In the [control room](./control-room), use the **Activity** view to find, filter, and stop work items.
+
+## Where humans decide
+
+By default, a factory asks for a human decision at three points:
+
+* **Specification review** - A person approves the specification before implementation starts.
+* **Clarification** - The factory asks a person about unclear requirements, blockers, and ambiguous review findings.
+* **Merge** - A person decides whether and when to merge the final pull request.
+
+These checkpoints come from the factory's agent instructions and your repository policy, not from a platform-level approval feature. Warp Factories doesn't enforce human-only merges: if your team requires them, use branch protection and repository permissions.
+
+## The outer loop: improving the factory
+
+Each completed work item leaves evidence behind: run and pull request activity, costs, evaluations, and benchmarks. Use it to spot repeated failures and compare model or harness configurations.
+
+Anyone on the team, or an agent, can propose changes to the factory's instructions, skills, models, environments, or other definitions. Definitions stored in GitHub can go through pull request review and configuration checks before a change reaches the production branch; Warp-managed definitions sync changes directly. Match your review policy to the definition source and the risk of the change.
+
+Benchmarks organize the evidence; they don't replace your judgment about whether a change is correct. See [measure and improve](./measure-and-improve) for the evaluation workflow.
diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx
index 520a0fc8..33404acf 100644
--- a/src/content/docs/factories/index.mdx
+++ b/src/content/docs/factories/index.mdx
@@ -1,20 +1,53 @@
 ---
 title: Warp Factories overview
 description: >-
-  Warp Factories give engineering teams open, flexible infrastructure for
-  building and operating their own cloud software factories.
+  Warp Factories runs cloud software factories where specialized agents move
+  engineering work from intake to a reviewed pull request.
 sidebar:
   label: "Overview"
 ---
+import { VARS } from '@data/vars';
 
-[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. This page is the Factories tab landing page (`/factories/`).
+Warp Factories lets engineering teams define and operate **software factories**: cloud workflows where specialized agents move engineering work from intake to a reviewed pull request. Your team sets the policy and makes the final decisions; the factory does the repetitive work and records the evidence you need to improve it.
 
-Cover, per the launch positioning:
-- What a software factory is (automation loop around the SDLC: triage, spec, implement, review, verify) and why teams are building them
-- How Warp Factories relates to Warp Agent / Warp Terminal / the CLI (decoupled products that interoperate)
-- The "open, flexible infrastructure" positioning: AI sovereignty, bring-your-own inference/hosting, factory definitions as code
-- Closed beta status + apply/waitlist CTA (mention the $10k qualified-org usage offer if approved for this surface)
+:::note
+**Early Access** - Warp Factories is available to a limited set of teams while Warp validates the product.
+:::
 
-See `.agents/references/terminology.md` → "Warp Factories terminology" for the baseline glossary (factory, software factory, work item, Factory MCP, control room, etc.) to write against.
+## What is a software factory?
 
-Cross-link to: Quickstart, How Factories work, and the Automation Platform tab (primitives Factories are built on).]
+A software factory is an automation loop around software development. It takes a **work item**, such as an issue, ticket, or triggered task, and moves it through specialized agents that triage it, write a specification when one is needed, implement the change, and review the result.
+
+A **factory** is one deployed instance of that loop. It connects your repositories and engineering tools to agent roles, execution infrastructure, and a measurable workflow. Each factory applies a single policy across all of its work sources, so deploy separate factories for repository groups that need different policies.
+
+## Who Warp Factories is for
+
+Warp Factories fits engineering teams with repeatable work that extends beyond one coding session:
+
+* **Backlog work** - Process issues with a consistent triage and delivery policy.
+* **Operational requests** - Fix defects reported through support channels.
+* **Code maintenance** - Review incoming pull requests or maintain services across repositories.
+
+## What Warp Factories provides
+
+* **Coordinated specialist agents** - A coordinating agent, the foreman, routes each work item through triage, specification, implementation, and review agents, skipping stages that don't apply.
+* **Factory definitions as code** - Version-controlled definitions describe your repositories, agents, automations, runners, skills, and MCP servers.
+* **Integrations and the Factory MCP** - Work flows in from Slack, Linear, Jira, and GitHub. The [Factory MCP](./factory-mcp) connects coding agents and other MCP clients.
+* **Model and harness choice** - Each agent role can use a different model and supported harness, including the Warp Agent, Claude Code, and Codex.
+* **Measurement and evaluation** - The control room shows work-item status, runs, automations, costs, evaluations, and benchmarks.
+* **Infrastructure control** - Run on Warp-hosted infrastructure, or self-host execution on an eligible Enterprise plan. Teams can also connect supported inference providers, scope secrets, and (if eligible) store transcripts, artifacts, and run attachments in their own S3 or GCS buckets. See [infrastructure and security](./infrastructure-and-security) for the available controls.
+
+## How Warp Factories relates to other Warp products
+
+| Product | How it relates |
+| --- | --- |
+| **Warp** | The interactive terminal where you develop locally with agents and code review. A factory runs independently in the cloud. |
+| **Warp Agent** | Warp's built-in agent harness. Factory roles can run on it or on another supported harness. |
+| **{VARS.WARP_CLI}** | Runs the Warp Agent in any terminal and exchanges work with a factory through the Factory MCP. |
+| **{VARS.WARP_AUTOMATION_PLATFORM}** | The platform underneath: cloud runs, environments, runners, integrations, secrets, orchestration, and APIs. A factory assembles these primitives into one workflow. |
+
+## Next steps
+
+* [**Set up a factory**](./quickstart) - Create a factory and send its first work item.
+* [**Understand the execution model**](./how-factories-work) - See how the foreman coordinates stages, runs, and human decisions.
+* **Adapt the system** - [Define the factory as code](./factory-as-code) and [connect its work sources](./connect-your-factory).
diff --git a/src/content/docs/platform/overview.mdx b/src/content/docs/platform/overview.mdx
index d9bec567..f658134a 100644
--- a/src/content/docs/platform/overview.mdx
+++ b/src/content/docs/platform/overview.mdx
@@ -47,9 +47,7 @@ In practice: **triggers create tasks; tasks execute on a host (optionally in an
 
 ### Warp Factories
 
-[Warp Factories](/factories/) give engineering teams open, flexible infrastructure for building and operating their own cloud software factories. A factory composes the primitives described on this page — triggers, tasks, environments, hosts, and integrations — into an automation loop around your development lifecycle.
-
-Factories are in closed beta. See the [Factories](/factories/) tab for what a software factory is, how to configure and connect one, and how to apply.
+[Warp Factories](/factories/) builds on the primitives described on this page to run persistent, multi-agent development workflows. A factory coordinates specialized cloud agents that move each work item through triage, specification, implementation, and review.
 
 ---