Warp Factories overview

A factory is a team of cloud agents attached to a set of repositories. Work arrives as a Slack message, a GitHub issue, a Linear or Jira ticket, or a scheduled job. A coordinating agent called the foreman routes each request through triage, spec, implementation, and review, and the result comes back where the work started, usually as a pull request. For example, a factory can work through a backlog of issues, fix defects reported in a support channel, or review incoming pull requests across several repositories.

People stay in the loop at the points that matter: approving a spec, answering the foreman’s questions, and merging.

Get started with Warp FactoriesFor prospective users and teams new to Warp Factories.

Open Warp FactoriesFor existing users and teams already using Warp Factories.

The software factory loop. The default agents cover triage through review.

The parts of a factory

Work items

A work item is one request the factory acts on: an issue, a support thread, a pull request, or a scheduled job. It keeps its source context from intake to handoff, however many agents contribute along the way.

Foreman and factory agents

Every factory has one foreman, the agent you talk to. It decides which agent a work item goes to next, asks you when it needs a decision, and hands back the finished pull request. Behind it are the default triage, spec, implement, and review agents; add custom agents for work they don’t cover. Each agent can run on its own model and harness, including the Warp Agent, Claude Code, and Codex. See factory agents.

Setup gives the foreman the same handle as the factory, so payments is the factory and @payments reaches its foreman from Slack or Linear. See Foreman name.

Stages and checkpoints

The foreman moves a work item through the Triage, Planning, Building, and Reviewing stages, skipping the ones a well-defined request doesn’t need and sending work back when review finds problems. Spec approval and the foreman’s questions are written into its instructions, which your team can edit. Merging is enforced by your repository’s branch protection. See how Warp Factories work.

Factory definition

A factory’s repositories, agents, automations, runners, skills, and MCP servers are declared in definition files, either managed by Warp or stored in a GitHub repository your team owns. Changes to a GitHub-backed factory go through pull request review like any other code. See definitions as code.

Work sources

Connect Slack, Microsoft Teams, GitHub, GitLab, Azure DevOps, Linear, or Jira, and the factory posts results back in the same thread, issue, or pull request. Custom webhooks and factory endpoints cover other systems, schedules start recurring work, and the Factory MCP lets a local coding agent hand work to a factory and take it back. See connect your factory.

Execution

Every agent run in a factory is an ordinary cloud agent run on the Automation Platform, so the same runners, models, APIs, and security controls apply. Runs execute on Warp-hosted compute by default. Enterprise teams can keep checkout and execution on their own infrastructure with managed self-hosting. See infrastructure and security.

Measurement

The factory dashboard shows work items by stage, runs, and cost per pull request. Scorers classify completed runs against criteria you write, benchmarks compare models, harnesses, and runners on the same tasks, and Self-improvement turns repeated failures into pull requests for your review. See measure and improve.

Sizing a factory

Group the repositories that ship together into one factory, and keep separate products in separate factories. For example:

• One factory for your main application
• One factory for your marketing site
• One factory for your data pipelines

Don’t split the same repositories across factories by team or task, such as frontend and platform. Add agents and skills to specialize instead.

Related pages

• Warp Factories quickstart - Create a factory and send its first work item.
• How Warp Factories work - The work-item lifecycle, stage by stage.
• Factory agents - What each default agent does and how to configure its model and harness.
• Definitions as code - The definition file format, with working examples in warp-factory-examples.