> 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 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

-   **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

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.
    
    ```
    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.
    

## 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.