Skip to content

Factories

Warp Factories quickstart

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

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.

  • 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.
  1. 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. 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.

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

  4. 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/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. 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.

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

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.