Factories
Warp Factories quickstart
# Warp Factories quickstart import { Steps } from '@astrojs/starlight/components'; Set up a factory, connect its repositories, and submit a first work item in about 10 minutes. ## Prerequisites * **Warp team membership** - Join the [Warp team](../knowledge-and-collaboration/teams) that will own the factory. Ask a team admin to complete team-level connections when your role does not include the required permissions. * **Factory agent capacity** - Setup provisions five agents for the default roster. If setup reports an agent limit, contact your workspace admin or Warp to confirm that the team has the required entitlement. * **GitHub repository access** - Choose at least one repository for the factory. You need permission to authorize or install the GitHub connection for those repositories, or help from a GitHub organization owner. Review the [GitHub integration requirements](../platform/integrations/github) if your organization restricts app installations. ## Set up a factory and submit work <Steps> 1. #### Open factory setup Sign in to Warp and open the factory setup flow. If setup asks you to choose a team, select the team that owns the repositories and integrations for this factory. A factory belongs to one Warp team. Team admins manage connections that require administrative permission. **Expected outcome:** Setup shows the selected Warp team and advances to GitHub configuration. 2. #### Connect GitHub and select repositories Complete the GitHub authorization or installation flow. If GitHub requires organization approval, ask an organization owner to approve the installation and grant access to the intended repositories. Return to setup and select one or more repositories. Use a focused repository set so the factory receives only the code context needed for its work. The default roster uses the same selected repositories. Warp provisions a default execution environment for the repository set. You do not need to create a separate environment for this quickstart. See [cloud agent environments](../platform/environments) for details about toolchains, setup commands, and runtime configuration. **Expected outcome:** The selected repositories appear in setup. 3. #### Name and create the factory Enter a short name that identifies the product, service, or repository group the factory maintains. For example, use `Payments services` rather than a generic name such as `Engineering`. Continue through setup, review the team, name, and repositories in the summary, then complete setup. Warp automatically provisions the default foreman, triage, specification, implementation, and review agents. You do not need to configure each role before the first work item. See [factory agents](./factory-agents) for role details. The summary confirms configuration only. Agents do not start work until you submit a request or a connected integration triggers one. :::caution If setup reports an agent limit while creating the factory, contact your workspace admin or Warp to confirm that the team has capacity for the five default agents. ::: **Expected outcome:** The factory control room opens with **Runs** and **Activity** available. 4. #### Submit the first work item Open the factory's **Runs** page and submit a small request with one repository, a narrow scope, a verifiable outcome, and an explicit validation command. ```text title="First work item" In `OWNER/REPO`, update `PATH` so it states `EXPECTED_CHANGE`. Keep the change limited to that file, run `VALIDATION_COMMAND`, and open a pull request. If the repository contradicts the request, stop and report what you found. ``` Replace `OWNER/REPO` with a selected repository, `PATH` with the file to change, `EXPECTED_CHANGE` with the required result, and `VALIDATION_COMMAND` with a command already defined by the repository. The factory creates a top-level foreman run. By default, the foreman routes the work through the applicable triage, specification, implementation, and review stages rather than requiring every stage. **Expected outcome:** A new foreman run appears on **Runs** with the submitted request as context. 5. #### Verify the work item Confirm the request at two levels: * **Runs** - Inspect the top-level foreman run and its status. Child runs appear as the foreman dispatches specialized agents. * **Activity** - Find the work item in its current stage, such as triage, planning, building, or reviewing. Open it to inspect its event history and any pull request artifacts. The control room records progress and outputs, but it does not provide in-page controls to steer or approve running agents. By default, the workflow returns specifications and pull requests to people for review when those steps apply. Use your team's existing process to review the work and decide whether to merge. **Expected outcome:** The factory has accepted the work item, started the foreman run, and exposed its current stage. This does not mean that a pull request is ready or that code has been merged. </Steps> ## Next steps * [**Connect your factory**](./connect-your-factory) - Add optional Slack or issue-tracker intake after the critical path works. * [**Factory MCP**](./factory-mcp) - Exchange work with the factory from a compatible coding agent or MCP client. * [**How Warp Factories work**](./how-factories-work) - Follow the full work-item lifecycle and default human decision points. ## Troubleshooting ### A GitHub repository does not appear Confirm that the GitHub installation includes the repository and that your Warp team uses the intended GitHub organization. Ask a GitHub organization owner or Warp team admin to update the connection when you do not have permission.Tell me about this feature: https://docs.warp.dev/factories/quickstart/Set up a factory, connect GitHub, and submit your first work item in about 10 minutes.
Set up a factory, connect its repositories, and submit a first work item in about 10 minutes.
Prerequisites
Section titled “Prerequisites”- Warp team membership - Join the Warp team that will own the factory. Ask a team admin to complete team-level connections when your role does not include the required permissions.
- Factory agent capacity - Setup provisions five agents for the default roster. If setup reports an agent limit, contact your workspace admin or Warp to confirm that the team has the required entitlement.
- GitHub repository access - Choose at least one repository for the factory. You need permission to authorize or install the GitHub connection for those repositories, or help from a GitHub organization owner. Review the GitHub integration requirements if your organization restricts app installations.
Set up a factory and submit work
Section titled “Set up a factory and submit work”-
Open factory setup
Section titled “Open factory setup”Sign in to Warp and open the factory setup flow. If setup asks you to choose a team, select the team that owns the repositories and integrations for this factory.
A factory belongs to one Warp team. Team admins manage connections that require administrative permission.
Expected outcome: Setup shows the selected Warp team and advances to GitHub configuration.
-
Connect GitHub and select repositories
Section titled “Connect GitHub and select repositories”Complete the GitHub authorization or installation flow. If GitHub requires organization approval, ask an organization owner to approve the installation and grant access to the intended repositories.
Return to setup and select one or more repositories. Use a focused repository set so the factory receives only the code context needed for its work. The default roster uses the same selected repositories.
Warp provisions a default execution environment for the repository set. You do not need to create a separate environment for this quickstart. See cloud agent environments for details about toolchains, setup commands, and runtime configuration.
Expected outcome: The selected repositories appear in setup.
-
Name and create the factory
Section titled “Name and create the factory”Enter a short name that identifies the product, service, or repository group the factory maintains. For example, use
Payments servicesrather than a generic name such asEngineering.Continue through setup, review the team, name, and repositories in the summary, then complete setup. Warp automatically provisions the default foreman, triage, specification, implementation, and review agents. You do not need to configure each role before the first work item. See factory agents for role details.
The summary confirms configuration only. Agents do not start work until you submit a request or a connected integration triggers one.
Expected outcome: The factory control room opens with Runs and Activity available.
-
Submit the first work item
Section titled “Submit the first work item”Open the factory’s Runs page and submit a small request with one repository, a narrow scope, a verifiable outcome, and an explicit validation command.
First work item In `OWNER/REPO`, update `PATH` so it states `EXPECTED_CHANGE`. Keep the change limited to that file, run `VALIDATION_COMMAND`, and open a pull request. If the repository contradicts the request, stop and report what you found.Replace
OWNER/REPOwith a selected repository,PATHwith the file to change,EXPECTED_CHANGEwith the required result, andVALIDATION_COMMANDwith a command already defined by the repository.The factory creates a top-level foreman run. By default, the foreman routes the work through the applicable triage, specification, implementation, and review stages rather than requiring every stage.
Expected outcome: A new foreman run appears on Runs with the submitted request as context.
-
Verify the work item
Section titled “Verify the work item”Confirm the request at two levels:
- Runs - Inspect the top-level foreman run and its status. Child runs appear as the foreman dispatches specialized agents.
- Activity - Find the work item in its current stage, such as triage, planning, building, or reviewing. Open it to inspect its event history and any pull request artifacts.
The control room records progress and outputs, but it does not provide in-page controls to steer or approve running agents. By default, the workflow returns specifications and pull requests to people for review when those steps apply. Use your team’s existing process to review the work and decide whether to merge.
Expected outcome: The factory has accepted the work item, started the foreman run, and exposed its current stage. This does not mean that a pull request is ready or that code has been merged.
Next steps
Section titled “Next steps”- Connect your factory - Add optional Slack or issue-tracker intake after the critical path works.
- Factory MCP - Exchange work with the factory from a compatible coding agent or MCP client.
- How Warp Factories work - Follow the full work-item lifecycle and default human decision points.
Troubleshooting
Section titled “Troubleshooting”A GitHub repository does not appear
Section titled “A GitHub repository does not appear”Confirm that the GitHub installation includes the repository and that your Warp team uses the intended GitHub organization. Ask a GitHub organization owner or Warp team admin to update the connection when you do not have permission.