From 0fc1a067db330a5c3f1f0ccab24317b6da11d69a Mon Sep 17 00:00:00 2001 From: Hong Yi Chen Date: Sat, 15 Aug 2026 16:45:56 -0700 Subject: [PATCH 1/2] docs(factories): add overview and workflow docs Co-Authored-By: Warp Co-Authored-By: Warp Agent --- .../docs/factories/how-factories-work.mdx | 72 ++++++++++++++++--- src/content/docs/factories/index.mdx | 54 +++++++++++--- src/content/docs/platform/overview.mdx | 4 +- 3 files changed, 106 insertions(+), 24 deletions(-) diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx index 5eeb05be..943c14b3 100644 --- a/src/content/docs/factories/how-factories-work.mdx +++ b/src/content/docs/factories/how-factories-work.mdx @@ -1,21 +1,71 @@ --- 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. + Warp Factories coordinate specialized agents from intake through review, + human handoff, measurement, and workflow improvement. sidebar: label: "How Factories work" --- -[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. +Warp Factories uses two connected loops. The **inner loop** moves a work item from intake toward a human handoff under the default seeded policy. The **outer loop** uses evidence from completed work to improve the factory. -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`. +A **work item** is one unit of engineering work, such as an issue, support request, pull request, or Factory MCP task. It retains its identity while specialized agents contribute through separate runs. -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 +## The inner execution loop -Cross-link to Configure your Factory and Connect your Factory for the procedural follow-through.] +The default path is intake, triage, specification when needed, implementation, review and verification, human handoff, and completion. Not every work item needs every stage. The foreman selects the shortest path that preserves the team's quality policy. It can enter at the stage supported by available context and return 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
(default policy)"] + Approval --> Implement + Implement --> Review[Review and verify] + Review --> Revision{Revision needed?} + Revision -->|Yes| Implement + Revision -->|No| Handoff["Human handoff
(default policy)"] + Handoff --> Complete[Complete] +``` + +| Stage | Purpose | Skip or return | Output | Human decision | +| --- | --- | --- | --- | --- | +| Intake | Preserve context from an integration, automation, direct run, or [Factory MCP](./factory-mcp). | Starts each work item. | Work item with source context. | None. | +| Foreman | Route work and coordinate specialized agents. | Can start at a later stage or return work to an existing conversation. | Context for the next agent. | Surfaces unresolved questions. | +| Triage | Research, reproduce when needed, and define scope. | Skip when intake is already bounded; return when requirements are unclear. | Evidence, scope, and complexity. | Clarify ambiguity. | +| Specification | Define product behavior, technical constraints, and validation criteria. | Skip for localized work; return when decisions are missing. | Product and technical spec. | Review before implementation under the default policy. | +| Implementation | Change code and produce test and visual evidence. | Return from review for revisions. | Branch, pull request, and validation evidence. | Clarify blockers with a human when needed. | +| Review and verification | Check requirements, code, tests, security expectations, and evidence. | Return findings to implementation. | Advisory verdict and findings. | Resolve ambiguous findings. | +| Human handoff | Present the result, evidence, and findings. | Can return to implementation for revisions. | Pull request or completed result. | Decide whether and when to merge under the default policy. | +| Complete | Record that the factory finished its work. | Terminal stage. | Completed work item. | None. | +| Cancelled | Record that cancellable work was stopped. | Terminal stage; **Complete** cannot overwrite it. | Cancelled work item. | None. | + +The foreman anchors the workstream, dispatches child runs, supplies relevant context, and continues existing agent conversations when possible. Sibling agents keep narrow responsibilities, and their runs remain distinct in run history. Verification belongs to implementation and review rather than a separate default role. See [factory agents](./factory-agents) for the role definitions. + +## Work items and agent runs + +| Concept | Scope | Behavior | +| --- | --- | --- | +| **Work item** | The unit a team follows through the factory. | Its stage is a progress signal based on the active or most recently launched role. Revision can move the stage backward, and the foreman can skip stages. | +| **Agent run** | One agent execution within the work item. | A top-level factory-agent run creates a work item. Child runs record stage actions and outputs inside that work item; they do not create additional work items. | + +The work-item stage is not an authoritative state machine. Run history is the detailed execution record across launches, revisions, and follow-up messages. + +In the [control room](./control-room), use **Activity** to locate, filter, and stop work items. + +## Human decisions are workflow policy + +The default seeded workflow asks for human review after a specification and expects a human merge decision. It also returns unclear requirements and ambiguous review findings to a person. + +These gates come from agent instructions and repository policy, not a factory-specific platform approval role. Warp Factories does not enforce human-only merges. Teams that require them should use branch protection and repository permissions. + +## The outer improvement loop + +The inner loop produces software and execution evidence. Run and pull request activity, costs, evaluations, and benchmarks help teams find repeated failures and compare model or harness configurations. + +A team or agent can propose changes to instructions, skills, models, environments, or other factory definitions. GitHub-backed definitions can use pull request review and factory configuration checks before changes reach the production branch. A Warp-managed definition can synchronize changes directly. Teams should set review policy according to the definition source and risk. + +Benchmarks organize evidence but do not replace product judgment or guarantee that an automated 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..fae48dc7 100644 --- a/src/content/docs/factories/index.mdx +++ b/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 help engineering teams define, deploy, measure, and improve + cloud software factories with specialized agents. 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 helps engineering teams define and operate cloud software factories. It coordinates specialized agents across repeatable development workflows, supports human responsibility through seeded instructions and repository policy, and records evidence for improving the system. -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 moves a **work item**, such as an issue, ticket, or triggered task, through specialized agents for triage, specification when needed, implementation, review, and verification. + +A **factory** is one deployed instance of that pattern on Warp Factories. It connects repositories and engineering tools to agent roles, execution infrastructure, and a measurable workflow. The factory keeps those roles connected around one work item. Each factory applies one operating policy across its connected work sources. Teams can deploy separate factories for different repository groups or operating 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** - Respond to defects reported through support channels. +* **Code maintenance** - Review incoming pull requests or maintain services across repositories. + +## What Warp Factories provides + +* **Assembly-line agents** - A foreman coordinates specialized agents and skips stages that do not apply. +* **Factory definitions as code** - Version-controlled definitions describe repositories, agents, automations, runners, skills, and MCP servers. +* **Integrations and Factory MCP** - Integrations route work from Slack, Linear, Jira, and GitHub. The [Factory MCP](./factory-mcp) connects compatible coding agents and MCP clients. +* **Model and harness choice** - Each 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** - Teams can use Warp-hosted execution, and eligible Enterprise teams can choose self-hosted execution. Teams can also connect supported inference providers and scope secrets. Eligible teams can configure customer-owned S3 or GCS buckets for supported transcripts, artifacts, and run attachments; Warp remains in the orchestration and write path. See [infrastructure and security](./infrastructure-and-security) for the available controls. + +## How Warp Factories relates to other Warp products + +| Product | Role | +| --- | --- | +| **Warp Factories** | Operates a persistent, multi-agent software development workflow. | +| **Warp Agent** | Warp's built-in agent harness for coding and command execution. A factory can use it for individual roles. | +| **Warp** | Provides the interactive terminal, agents, and code review for local development. A factory runs independently in the cloud. | +| **{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 cloud runs, environments, runners, integrations, secrets, orchestration, and APIs. Warp Factories assembles these primitives into a software-factory 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..de27dd78 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/) assembles the platform primitives described on this page into persistent, multi-agent software development workflows. A factory coordinates specialized cloud agents around work items as they move through stages such as triage, specification, implementation, review, and verification. --- From 8c69343df8f0eaec4feccdce6f23d5c3298b23c6 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:38:30 +0000 Subject: [PATCH 2/2] docs(factories): editorial pass for clarity and plain language Rewrite the overview and How Factories work pages as a copyediting pass: - Define terms (foreman, work item) before using them - Replace the 9x5 stage table with a scannable stage list - Remove internal implementation phrasing (seeded policy, authoritative state machine, orchestration/write path, Complete-vs-Cancelled overwrite) - Consolidate repeated default-policy and eligibility hedges - Fix singular subject-verb agreement for Warp Factories in frontmatter - Tighten the Factories paragraph in the platform overview No factual claims added; all verified behavior and caveats preserved. Co-Authored-By: Warp --- .../docs/factories/how-factories-work.mdx | 64 ++++++++++--------- src/content/docs/factories/index.mdx | 31 +++++---- src/content/docs/platform/overview.mdx | 2 +- 3 files changed, 49 insertions(+), 48 deletions(-) diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx index 943c14b3..d1713d6b 100644 --- a/src/content/docs/factories/how-factories-work.mdx +++ b/src/content/docs/factories/how-factories-work.mdx @@ -1,19 +1,24 @@ --- title: How Warp Factories work description: >- - Warp Factories coordinate specialized agents from intake through review, - human handoff, measurement, and workflow improvement. + 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" --- -Warp Factories uses two connected loops. The **inner loop** moves a work item from intake toward a human handoff under the default seeded policy. The **outer loop** uses evidence from completed work to improve the factory. +A factory runs two connected loops: -A **work item** is one unit of engineering work, such as an issue, support request, pull request, or Factory MCP task. It retains its identity while specialized agents contribute through separate runs. +* 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. -## The inner execution loop +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. -The default path is intake, triage, specification when needed, implementation, review and verification, human handoff, and completion. Not every work item needs every stage. The foreman selects the shortest path that preserves the team's quality policy. It can enter at the stage supported by available context and return to an earlier agent when revisions are needed. +## 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 @@ -31,41 +36,38 @@ flowchart LR Handoff --> Complete[Complete] ``` -| Stage | Purpose | Skip or return | Output | Human decision | -| --- | --- | --- | --- | --- | -| Intake | Preserve context from an integration, automation, direct run, or [Factory MCP](./factory-mcp). | Starts each work item. | Work item with source context. | None. | -| Foreman | Route work and coordinate specialized agents. | Can start at a later stage or return work to an existing conversation. | Context for the next agent. | Surfaces unresolved questions. | -| Triage | Research, reproduce when needed, and define scope. | Skip when intake is already bounded; return when requirements are unclear. | Evidence, scope, and complexity. | Clarify ambiguity. | -| Specification | Define product behavior, technical constraints, and validation criteria. | Skip for localized work; return when decisions are missing. | Product and technical spec. | Review before implementation under the default policy. | -| Implementation | Change code and produce test and visual evidence. | Return from review for revisions. | Branch, pull request, and validation evidence. | Clarify blockers with a human when needed. | -| Review and verification | Check requirements, code, tests, security expectations, and evidence. | Return findings to implementation. | Advisory verdict and findings. | Resolve ambiguous findings. | -| Human handoff | Present the result, evidence, and findings. | Can return to implementation for revisions. | Pull request or completed result. | Decide whether and when to merge under the default policy. | -| Complete | Record that the factory finished its work. | Terminal stage. | Completed work item. | None. | -| Cancelled | Record that cancellable work was stopped. | Terminal stage; **Complete** cannot overwrite it. | Cancelled work item. | None. | +### Stages -The foreman anchors the workstream, dispatches child runs, supplies relevant context, and continues existing agent conversations when possible. Sibling agents keep narrow responsibilities, and their runs remain distinct in run history. Verification belongs to implementation and review rather than a separate default role. See [factory agents](./factory-agents) for the role definitions. +* **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 -| Concept | Scope | Behavior | -| --- | --- | --- | -| **Work item** | The unit a team follows through the factory. | Its stage is a progress signal based on the active or most recently launched role. Revision can move the stage backward, and the foreman can skip stages. | -| **Agent run** | One agent execution within the work item. | A top-level factory-agent run creates a work item. Child runs record stage actions and outputs inside that work item; they do not create additional work items. | +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. -The work-item stage is not an authoritative state machine. Run history is the detailed execution record across launches, revisions, and follow-up messages. +In the [control room](./control-room), use the **Activity** view to find, filter, and stop work items. -In the [control room](./control-room), use **Activity** to locate, filter, and stop work items. +## Where humans decide -## Human decisions are workflow policy +By default, a factory asks for a human decision at three points: -The default seeded workflow asks for human review after a specification and expects a human merge decision. It also returns unclear requirements and ambiguous review findings to a person. +* **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 gates come from agent instructions and repository policy, not a factory-specific platform approval role. Warp Factories does not enforce human-only merges. Teams that require them should use branch protection and repository permissions. +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 improvement loop +## The outer loop: improving the factory -The inner loop produces software and execution evidence. Run and pull request activity, costs, evaluations, and benchmarks help teams find repeated failures and compare model or harness configurations. +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. -A team or agent can propose changes to instructions, skills, models, environments, or other factory definitions. GitHub-backed definitions can use pull request review and factory configuration checks before changes reach the production branch. A Warp-managed definition can synchronize changes directly. Teams should set review policy according to the definition source and risk. +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 evidence but do not replace product judgment or guarantee that an automated change is correct. See [measure and improve](./measure-and-improve) for the evaluation workflow. +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 fae48dc7..33404acf 100644 --- a/src/content/docs/factories/index.mdx +++ b/src/content/docs/factories/index.mdx @@ -1,14 +1,14 @@ --- title: Warp Factories overview description: >- - Warp Factories help engineering teams define, deploy, measure, and improve - cloud software factories with specialized agents. + 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'; -Warp Factories helps engineering teams define and operate cloud software factories. It coordinates specialized agents across repeatable development workflows, supports human responsibility through seeded instructions and repository policy, and records evidence for improving the system. +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. :::note **Early Access** - Warp Factories is available to a limited set of teams while Warp validates the product. @@ -16,36 +16,35 @@ Warp Factories helps engineering teams define and operate cloud software factori ## What is a software factory? -A **software factory** is an automation loop around software development. It moves a **work item**, such as an issue, ticket, or triggered task, through specialized agents for triage, specification when needed, implementation, review, and verification. +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 pattern on Warp Factories. It connects repositories and engineering tools to agent roles, execution infrastructure, and a measurable workflow. The factory keeps those roles connected around one work item. Each factory applies one operating policy across its connected work sources. Teams can deploy separate factories for different repository groups or operating policies. +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** - Respond to defects reported through support channels. +* **Operational requests** - Fix defects reported through support channels. * **Code maintenance** - Review incoming pull requests or maintain services across repositories. ## What Warp Factories provides -* **Assembly-line agents** - A foreman coordinates specialized agents and skips stages that do not apply. -* **Factory definitions as code** - Version-controlled definitions describe repositories, agents, automations, runners, skills, and MCP servers. -* **Integrations and Factory MCP** - Integrations route work from Slack, Linear, Jira, and GitHub. The [Factory MCP](./factory-mcp) connects compatible coding agents and MCP clients. -* **Model and harness choice** - Each role can use a different model and supported harness, including the Warp Agent, Claude Code, and Codex. +* **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** - Teams can use Warp-hosted execution, and eligible Enterprise teams can choose self-hosted execution. Teams can also connect supported inference providers and scope secrets. Eligible teams can configure customer-owned S3 or GCS buckets for supported transcripts, artifacts, and run attachments; Warp remains in the orchestration and write path. See [infrastructure and security](./infrastructure-and-security) for the available controls. +* **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 | Role | +| Product | How it relates | | --- | --- | -| **Warp Factories** | Operates a persistent, multi-agent software development workflow. | -| **Warp Agent** | Warp's built-in agent harness for coding and command execution. A factory can use it for individual roles. | -| **Warp** | Provides the interactive terminal, agents, and code review for local development. A factory runs independently in the cloud. | +| **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 cloud runs, environments, runners, integrations, secrets, orchestration, and APIs. Warp Factories assembles these primitives into a software-factory workflow. | +| **{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 diff --git a/src/content/docs/platform/overview.mdx b/src/content/docs/platform/overview.mdx index de27dd78..f658134a 100644 --- a/src/content/docs/platform/overview.mdx +++ b/src/content/docs/platform/overview.mdx @@ -47,7 +47,7 @@ In practice: **triggers create tasks; tasks execute on a host (optionally in an ### Warp Factories -[Warp Factories](/factories/) assembles the platform primitives described on this page into persistent, multi-agent software development workflows. A factory coordinates specialized cloud agents around work items as they move through stages such as triage, specification, implementation, review, and verification. +[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. ---