docs(factories): add concise overview and workflow

src/content/docs/factories/how-factories-work.mdx

@@ -1,21 +1,77 @@
 ---
 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.
+
+### Stages
+
+The diagram below shows the default path through a factory's stages.
+
+```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]
+```
+
+* **Intake** - A work item enters from a [connected integration](./connect-your-factory), an automation, a direct run, or the [Factory MCP](./factory-mcp). It keeps its source context as it moves through later stages.
+* **Triage** - The triage agent researches the request, reproduces it when needed, and defines its scope and complexity. The foreman skips this stage when the request is already well bounded.
+* **Specification** - The specification agent defines product behavior, technical constraints, and validation criteria. The foreman skips this stage for localized changes.
+* **Implementation** - The implementation agent makes the code change on a branch and opens a pull request with test and visual evidence.
+* **Review and verification** - The review agent checks the change against the requirements, tests, and security expectations, then sends findings back to implementation. Its verdict is advisory.
+* **Human handoff** - The factory presents the result, its evidence, and any findings. A person decides what happens next.
+* **Complete or Cancelled** - The work item ends when the factory finishes its work, or stops early if someone cancels it.
+
+## Work items and agent runs
+
+A work item and an agent run track different things. The work item is the single unit of engineering work your team follows from intake to completion. An agent run is one agent's execution within that work item. The first factory-agent run creates the work item, and each later run records one stage's actions and outputs within that 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.
+
+## What 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, including run and pull request activity, costs, [Scorer](./measure-and-improve) evaluations, and benchmarks. Teams use this evidence to spot repeated failures and compare model or harness configurations.
+
+The factory can also act on that evidence directly. Its [self-improvement](./measure-and-improve#configure-and-review-self-improvement) capability groups the failures Scorers flag and files follow-up runs that propose changes to the application code or the factory's own definition. Nothing is adopted without your review.
+
+Anyone on the team, or an agent, can also propose changes to the factory's instructions, skills, models, environments, or other [definitions](./factory-as-code). 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, or [build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) to apply the same outer-loop pattern to a standalone agent.

src/content/docs/factories/index.mdx

@@ -1,20 +1,54 @@
 ---
 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
+This feature is currently in **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 automates the software development lifecycle. 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 pattern. 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 benefits from Warp Factories
+
+Warp Factories is designed for engineering teams with repeatable work that extends beyond one coding session, such as:
+
+* **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 you get with Warp Factories
+
+* **Coordinated specialist agents** - A team of [factory agents](./factory-agents) runs each work item. A coordinating foreman routes it through the triage, spec, implement, and review roles, skipping stages that don't apply. You can add custom agents and automations to handle work the default roles don't cover.
+* **Factory definitions as code** - [Version-controlled definition files](./factory-as-code) describe your repositories, agents, automations, runners, skills, and MCP servers, so factory changes get the same review, history, and rollback as code changes.
+* **Integrations and the Factory MCP** - Work flows in from [Slack](./integrations/slack), [Linear](./integrations/linear), [Jira](./integrations/jira), and [GitHub](./integrations/github), plus direct runs and schedules. 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](../platform/harnesses), including the Warp Agent, Claude Code, and Codex.
+* **Measurement and self-improvement** - The [control room](./control-room) shows work-item status, runs, automations, costs, and benchmarks. [Scorers](./measure-and-improve) grade completed work, and [Self-improvement](./measure-and-improve#configure-and-review-self-improvement) turns repeated failures into follow-up work the factory proposes for review.
+* **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}** | Provides the cloud runs, environments, runners, integrations, secrets, orchestration, and APIs that a factory assembles 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.
+* [**Meet the factory agents**](./factory-agents) - See what each role does and how to configure its model, harness, and instructions.
+* **Adapt the system** - [Define the factory as code](./factory-as-code) and [connect its work sources](./connect-your-factory).

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.
 
 ---