Factories
Warp Factories quickstart
# Warp Factories quickstart Set up a factory, connect the repositories it will work in, and submit a first work item in about 10 minutes. This quickstart is for Warp Factories closed-beta participants who already have access and the required team and GitHub permissions. *** ## Prerequisites * **Closed-beta access** - Use the access instructions from your Warp contact. Warp Factories is available only to participating teams during the closed beta. * **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. Confirm with your workspace admin or Warp that the team has the required closed-beta entitlement before creating the factory. * **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 underlying [GitHub integration requirements](../platform/integrations/github) before setup if your organization restricts app installations. :::note GitHub and at least one repository are required. Slack and an issue tracker are optional. You can submit the first work item from the factory's **Runs** page without connecting an optional integration. ::: *** ## Setting up a factory and submitting work _About 10 minutes_ ### 1. Open the factory setup flow Use the closed-beta access instructions from Warp to sign in 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 members with access can inspect its work, while team admins manage connections that require administrative permission. **Expected outcome:** The setup flow shows the selected Warp team and advances to the code-host 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 factory setup after GitHub completes the authorization. Select one or more repositories for the factory. Use a focused repository set for the first factory so the agents receive only the code context needed for the work you plan to submit. Every agent in the default roster works from this selected repository set. Warp provisions a default execution environment for the factory and its selected repositories. You do not need to create a separate environment for this quickstart. See [cloud agent environments](../platform/environments) to understand how repositories, toolchains, setup commands, and runtime configuration affect later runs. **Expected outcome:** The selected repositories appear in setup, and you can continue to the factory identity step. ### 3. Name 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`. When you continue, Warp creates the factory and provisions the default agent roster: * **Foreman** - Receives the work item, chooses the route through the workflow, coordinates the other agents, and communicates the outcome. * **Triage** - Investigates the request, gathers evidence, and establishes scope. * **Specification** - Defines requirements and validation criteria when the work needs a spec. * **Implementation** - Changes the code and validates the implementation. * **Review** - Independently reviews the change and its verification evidence. You do not need to configure each role before submitting the first work item. The foreman skips stages that do not apply, so a small, well-scoped request does not require a specification by default. See [factory agents](./factory-agents) for role boundaries and [how Warp Factories work](./how-factories-work) for the complete lifecycle. **Expected outcome:** The setup flow shows the factory name and continues to optional integrations. :::caution If setup reports an agent limit while creating the factory, contact your workspace admin or Warp to confirm that the team has closed-beta capacity for the five default agents. ::: ### 4. Optionally connect Slack and an issue tracker Connect Slack if you want teammates to submit requests and receive updates in a Slack thread. The factory uses its connected Slack app to keep each thread associated with the same work item. See the underlying [Slack integration](../platform/integrations/slack) for workspace requirements. Connect either Linear or Jira if your team wants issues to become the intake point for factory work. Choose the tracker your team already uses: * [**Linear integration**](../platform/integrations/linear) - Review workspace access, identity, and issue-trigger requirements. * [**Jira integration**](../platform/integrations/jira) - Review Jira Cloud and site-admin requirements. You can skip both optional connections and add them later. [Connect your factory](./connect-your-factory) covers the available intake paths and integration behavior. **Expected outcome:** Setup reflects the optional connections you completed, or lets you continue without them. ### 5. Complete setup Review the setup summary. Confirm the team, factory name, selected repositories, and optional integrations, then complete setup and open the factory. The summary confirms the factory configuration. It does not mean that agents have started working. Work begins only after you submit a request or a connected integration triggers one. Open the factory's **Runs** and **Activity** pages. **Runs** shows the agent runs behind each request. **Activity** shows work items at the workflow level. **Expected outcome:** The factory control room opens, and no work item appears until you submit one. ### 6. Submit the first work item Use the factory's **Runs** page for the shortest path. Open the new-run composer and enter a small request with one repository, a narrow scope, a verifiable outcome, and an explicit validation command. For example: > 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. Submit the request. The factory creates a top-level foreman run for the work item. The foreman then decides whether the request needs triage, specification, implementation, or review. If you connected an integration, you can instead submit the same scoped request through the factory's Slack app or the connected issue tracker. Keep the first request small regardless of its source. **Expected outcome:** A new foreman run appears on **Runs** with the submitted request as its context. ### 7. Confirm the work item is running Use the control room to verify the request at two levels: * **Runs** - Confirm that the top-level foreman run exists and inspect its status. Child runs appear under the work item as the foreman dispatches specialized agents. * **Activity** - Confirm that the work item appears in its current stage, such as triage, planning, building, or reviewing. Open the item to inspect its event history and any pull request artifacts that become available. The control room records progress and outputs. 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. Success at this point means the factory accepted the work item, started the foreman run, and exposed the current stage. It does not mean that a pull request is ready or that code has been merged. *** ## Next steps * [**How Warp Factories work**](./how-factories-work) - Follow the full work-item lifecycle and human decision points. * [**Factory agents**](./factory-agents) - Understand the default roster and each role's responsibilities. * [**Connect your factory**](./connect-your-factory) - Add communication tools, issue trackers, and other intake paths. * [**Factory MCP**](./factory-mcp) - Connect a compatible coding agent or MCP client after the critical-path setup is working. * [**Infrastructure and security**](./infrastructure-and-security) - Review execution, inference, storage, secrets, and governance controls. ## 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. ### An integration request does not create a run Confirm that the integration is connected to the same factory and team as the selected repositories. Submit the request from the factory's **Runs** page to separate factory setup from integration configuration, then review [connecting your factory](./connect-your-factory).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 the repositories it will work in, and submit a first work item in about 10 minutes. This quickstart is for Warp Factories closed-beta participants who already have access and the required team and GitHub permissions.
Prerequisites
Section titled “Prerequisites”- Closed-beta access - Use the access instructions from your Warp contact. Warp Factories is available only to participating teams during the closed beta.
- 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. Confirm with your workspace admin or Warp that the team has the required closed-beta entitlement before creating the factory.
- 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 underlying GitHub integration requirements before setup if your organization restricts app installations.
Setting up a factory and submitting work
Section titled “Setting up a factory and submitting work”About 10 minutes
1. Open the factory setup flow
Section titled “1. Open the factory setup flow”Use the closed-beta access instructions from Warp to sign in 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 members with access can inspect its work, while team admins manage connections that require administrative permission.
Expected outcome: The setup flow shows the selected Warp team and advances to the code-host configuration.
2. Connect GitHub and select repositories
Section titled “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 factory setup after GitHub completes the authorization.
Select one or more repositories for the factory. Use a focused repository set for the first factory so the agents receive only the code context needed for the work you plan to submit. Every agent in the default roster works from this selected repository set.
Warp provisions a default execution environment for the factory and its selected repositories. You do not need to create a separate environment for this quickstart. See cloud agent environments to understand how repositories, toolchains, setup commands, and runtime configuration affect later runs.
Expected outcome: The selected repositories appear in setup, and you can continue to the factory identity step.
3. Name the factory
Section titled “3. Name 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.
When you continue, Warp creates the factory and provisions the default agent roster:
- Foreman - Receives the work item, chooses the route through the workflow, coordinates the other agents, and communicates the outcome.
- Triage - Investigates the request, gathers evidence, and establishes scope.
- Specification - Defines requirements and validation criteria when the work needs a spec.
- Implementation - Changes the code and validates the implementation.
- Review - Independently reviews the change and its verification evidence.
You do not need to configure each role before submitting the first work item. The foreman skips stages that do not apply, so a small, well-scoped request does not require a specification by default. See factory agents for role boundaries and how Warp Factories work for the complete lifecycle.
Expected outcome: The setup flow shows the factory name and continues to optional integrations.
4. Optionally connect Slack and an issue tracker
Section titled “4. Optionally connect Slack and an issue tracker”Connect Slack if you want teammates to submit requests and receive updates in a Slack thread. The factory uses its connected Slack app to keep each thread associated with the same work item. See the underlying Slack integration for workspace requirements.
Connect either Linear or Jira if your team wants issues to become the intake point for factory work. Choose the tracker your team already uses:
- Linear integration - Review workspace access, identity, and issue-trigger requirements.
- Jira integration - Review Jira Cloud and site-admin requirements.
You can skip both optional connections and add them later. Connect your factory covers the available intake paths and integration behavior.
Expected outcome: Setup reflects the optional connections you completed, or lets you continue without them.
5. Complete setup
Section titled “5. Complete setup”Review the setup summary. Confirm the team, factory name, selected repositories, and optional integrations, then complete setup and open the factory.
The summary confirms the factory configuration. It does not mean that agents have started working. Work begins only after you submit a request or a connected integration triggers one.
Open the factory’s Runs and Activity pages. Runs shows the agent runs behind each request. Activity shows work items at the workflow level.
Expected outcome: The factory control room opens, and no work item appears until you submit one.
6. Submit the first work item
Section titled “6. Submit the first work item”Use the factory’s Runs page for the shortest path. Open the new-run composer and enter a small request with one repository, a narrow scope, a verifiable outcome, and an explicit validation command.
For example:
In
OWNER/REPO, updatePATHso it statesEXPECTED_CHANGE. Keep the change limited to that file, runVALIDATION_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.
Submit the request. The factory creates a top-level foreman run for the work item. The foreman then decides whether the request needs triage, specification, implementation, or review.
If you connected an integration, you can instead submit the same scoped request through the factory’s Slack app or the connected issue tracker. Keep the first request small regardless of its source.
Expected outcome: A new foreman run appears on Runs with the submitted request as its context.
7. Confirm the work item is running
Section titled “7. Confirm the work item is running”Use the control room to verify the request at two levels:
- Runs - Confirm that the top-level foreman run exists and inspect its status. Child runs appear under the work item as the foreman dispatches specialized agents.
- Activity - Confirm that the work item appears in its current stage, such as triage, planning, building, or reviewing. Open the item to inspect its event history and any pull request artifacts that become available.
The control room records progress and outputs. 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.
Success at this point means the factory accepted the work item, started the foreman run, and exposed the current stage. It does not mean that a pull request is ready or that code has been merged.
Next steps
Section titled “Next steps”- How Warp Factories work - Follow the full work-item lifecycle and human decision points.
- Factory agents - Understand the default roster and each role’s responsibilities.
- Connect your factory - Add communication tools, issue trackers, and other intake paths.
- Factory MCP - Connect a compatible coding agent or MCP client after the critical-path setup is working.
- Infrastructure and security - Review execution, inference, storage, secrets, and governance controls.
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.
An integration request does not create a run
Section titled “An integration request does not create a run”Confirm that the integration is connected to the same factory and team as the selected repositories. Submit the request from the factory’s Runs page to separate factory setup from integration configuration, then review connecting your factory.