Warp Factories overview
Warp Factories turns issues, tickets, and Slack messages into reviewed pull requests. Teams of cloud agents do the work, while people approve specs and merges.
A factory is a team of cloud agents attached to a set of repositories. It takes work from Slack, GitHub, Linear, or Jira through triage, spec, implementation, and review, and returns the result, usually a pull request, where the work started.
- Read the Warp Factories quickstart：Follow the setup instructions to connect repositories and send your first request.
What a factory does
A factory can work through a backlog of issues, fix defects reported in a support channel, or review incoming pull requests across several repositories.
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
The foreman is the agent that coordinates a factory's work and communicates with you. See factory agents for agent roles, models, harnesses, and configuration.
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
Work moves through Triage, Planning, Building, and Reviewing. The foreman can skip unnecessary stages or send work back for revisions. Spec approval is part of the foreman's editable instructions, not a repository permission. The factory never merges on your behalf. Repository permissions and branch protection control approval and merge access. 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, and Jira through factory integrations. Results return to the thread, issue, or pull request where work began. Use custom webhooks or factory endpoints for other systems, and automations for scheduled work.
The Factory MCP lets a local coding agent send work to a factory, take it over locally, and hand it back.
Execution
Every agent run in a factory is an ordinary cloud agent run on the Automation Platform. 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 for runners, inference, and credential boundaries.
Evaluate and improve factory work
Use the factory dashboard to inspect PR activity, autonomy, cycle time, and cost. To evaluate and improve the work:
- Scorers - Classify runs against your criteria.
- Benchmarks - Compare configurations on the same tasks.
- Self-improvement - Propose changes for review.
See measure and improve for definitions and limitations.
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.
- Transitioning from Oz - Assess an existing web app, CLI, SDK, or API workflow.
- <a href=https://www.warp.dev/get-started>Get started with the Warp team - Get help choosing and setting up a workflow.