> For the complete documentation index, see [llms.txt](/llms.txt). > Markdown versions of each page are available by appending .md to any URL. # Warp Factories overview Warp Factories help engineering teams define, deploy, measure, and improve cloud software factories with specialized agents. Warp Factories is Warp’s product for defining and operating cloud software factories. It coordinates specialized agents across a repeatable software development workflow, supports human responsibility through seeded instructions and repository policy, and records the work so teams can measure and improve the system. Note Warp Factories is currently in closed beta. Access is limited while Warp works with participating teams to validate the product. ## What is a software factory? A **software factory** is a system that applies a defined automation loop to software development. Instead of assigning one general-purpose agent an open-ended request, the system moves a **work item**, such as an issue, ticket, or triggered task, through specialized stages. Agents triage the request, write a specification when the work needs one, implement the change, and review and verify the result. Humans clarify requirements, approve plans, review pull requests, and decide what ships. A **factory** is one deployed instance of that pattern on Warp Factories. It connects a team’s repositories and engineering tools to a roster of agents, execution infrastructure, and a measurable workflow. Teams can deploy separate factories for different products, repositories, or operating constraints. ## Who Warp Factories is for This model fits engineering organizations with repeatable workflows that extend beyond one coding session. Examples include processing an issue backlog, responding to defects from a support channel, reviewing incoming pull requests, or maintaining a service across many repositories. A factory makes the process explicit and gives each stage a defined owner. ## What Warp Factories provides Warp Factories combines the workflow layer and the infrastructure required to operate it: - **Assembly-line agents** - A foreman receives each work item and coordinates agents for triage, specification, implementation, and review. The foreman skips stages that do not apply and returns decisions to a human when requirements or outcomes need judgment. - **Factory definitions as code** - Version-controlled definitions describe the factory, its repositories, agents, automations, runners, skills, and MCP servers. Definitions make the operating model reviewable alongside the code the factory works on. - **Integrations and Factory MCP** - Integrations route work from tools such as Slack, Linear, Jira, and GitHub into a factory. The [Factory MCP](./factory-mcp) lets compatible coding agents and MCP clients find work, inspect context, coordinate with the foreman, and return completed work. - **Model and harness choice** - Each role can use the model and agent harness suited to its task. A factory can combine the Warp Agent harness, Claude Code, and Codex instead of requiring every stage to run on one model or harness. - **Measurement and evaluation** - The control room shows work-item status, agent runs, automations, costs, evaluations, and benchmarks. Teams use that evidence to compare configurations and decide where to change the workflow. - **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 a factory handles work Work can enter through an integration, an automation, a direct prompt, or the Factory MCP. The foreman interprets the request, selects the next stage, and dispatches the appropriate sibling agent. Each agent receives its role instructions, repository context, skills, tools, model, harness, and execution environment. The work item’s stage gives the team a workflow-level view of progress. The underlying agent runs preserve the detailed execution record, including messages, actions, outputs, and parent-child relationships. A single work item can therefore involve several coordinated runs without losing its identity as one unit of engineering work. The default lifecycle is intake, triage, optional specification, implementation, review and verification, human handoff, and completion. It is not a mandatory sequence. A small, well-defined fix can move from triage directly to implementation, while an ambiguous product change pauses for questions and specification approval. [How Warp Factories work](./how-factories-work) explains the lifecycle and coordination model. ## How Warp Factories relates to other Warp products Warp Factories interoperates with Warp’s agent and developer surfaces, but it serves a different purpose: - **Warp Factories** - Defines and operates a multi-agent software development system. It owns the workflow around work items, specialized roles, integrations, measurement, and infrastructure policy. - **Warp Agent** - Warp’s built-in agent harness for coding and command execution. A factory can use the Warp Agent for one or more roles, but the agent is not the factory or its orchestration layer. - **Warp Terminal** - The interactive terminal and development environment where a developer runs commands, works with agents, reviews changes, and handles local tasks. It is not required to keep a cloud factory running. - **Warp Agent CLI** - Runs the Warp Agent in any terminal. Through the Factory MCP, a developer can pull factory work into a local conversation and return the result to the same work item. - **Oz** - Provides the underlying primitives for cloud runs, environments, runners, integrations, secrets, orchestration, and APIs. Warp Factories assembles those primitives into an opinionated software-factory workflow. See the [Oz overview](../platform/overview) for the general-purpose platform. These products remain independently useful. A developer can use the Warp Agent without a factory, and a team can build custom cloud automation directly on Oz. Warp Factories is for teams that want a persistent, multi-stage system for moving software work from intake to a human-reviewed outcome. ## Explore Warp Factories - [**Warp Factories quickstart**](./quickstart) - Set up a factory and send the first work item. - [**How Warp Factories work**](./how-factories-work) - Follow the work-item lifecycle, foreman coordination, and improvement loop. - [**Factory agents**](./factory-agents) - Understand the default agent roles and how they collaborate. - [**Configure your factory**](./configure-your-factory) - Configure agents, automations, integrations, and execution resources. - [**Factory definitions as code**](./factory-as-code) - Define repositories, agents, automations, runners, skills, and MCP servers. - [**Connect your factory**](./connect-your-factory) - Route work from engineering tools and coding agents. - [**Factory MCP**](./factory-mcp) - Exchange work and context with a factory from an MCP client. - [**Measure and improve**](./measure-and-improve) - Evaluate runs, compare configurations, and refine the factory. - [**Infrastructure and security**](./infrastructure-and-security) - Choose execution, inference, storage, secrets, and governance controls.