How Warp Factories work

A factory is a team of cloud agents that ships software the way your team does: a request comes in, moves through the stages it needs, and comes back as a pull request for a person to review. You talk to one agent — the foreman — from whichever tool a request starts in, and it dispatches the factory’s other agents, each owning one part of the software development lifecycle.

A work item is one unit of that engineering work, such as an issue, support request, pull request, or Factory MCP task. It keeps its identity from intake to handoff, however many agents contribute to it along the way.

How a work item moves through the factory

The foreman coordinates every work item. It routes work between the factory’s agents, passes each one the context it needs, and continues existing agent conversations instead of starting new ones. See factory agents for what each agent does.

Not every work item needs every stage. The foreman picks the shortest path that still meets your quality policy: it skips stages when the work is already well defined, starts partway through when enough context exists, and sends work back to an earlier agent when revisions are needed.

Stages

The diagram below shows the default path through a factory’s stages.

flowchart LR
  Intake[Intake] --> Foreman[Foreman]
  Foreman --> Triage[Triage]
  Triage --> Decision{Specification needed?}
  Decision -->|Yes| Spec[Specify]
  Decision -->|No| Implement[Implement]
  Spec --> Approval["Human review<br/>(default policy)"]
  Approval --> Implement
  Implement --> Review[Review and verify]
  Review --> Revision{Revision needed?}
  Revision -->|Yes| Implement
  Revision -->|No| Handoff["Human handoff<br/>(default policy)"]
  Handoff --> Complete[Complete]

• Intake - A work item enters from a connected integration, an automation, a direct run, or the Factory MCP. It keeps its source context as it moves through later stages.
• Triage - The triage agent researches the request, reproduces the problem when needed, and defines the scope and complexity of the change. The foreman skips this stage when the request is already well bounded.
• Specification - The specification agent defines product behavior, technical constraints, and validation criteria. The foreman skips this stage for localized changes.
• Implementation - The implementation agent makes the code change on a branch and opens a pull request with test and visual evidence.
• Review and verification - The review agent checks the change against the requirements, tests, and security expectations, then sends findings back to implementation. Its verdict is advisory.
• Human handoff - The factory presents the result, its evidence, and any findings. A person decides what happens next.
• Complete or Cancelled - The work item ends when the factory finishes its work, or stops early if someone cancels it.

In the factory dashboard, the Activity view is where you find, filter, and stop work items. It groups these stages under its own names — Triage, Planning (specification), Building (implementation), and Reviewing — and each agent’s run within a work item is an ordinary cloud agent run you can watch and steer.

Where your team stays in charge

A factory is built to pause where the call belongs to a person. By default, that’s three places:

• Approving the spec - When work goes through the spec stage, implementation waits until a person signs off on the plan.
• Answering questions - When requirements are unclear or a review finding is ambiguous, the foreman asks instead of guessing.
• Merging - The factory opens the pull request and hands it off. Whether and when it merges is your team’s call.

The first two are workflow policy, written into the foreman’s instructions; edit them to change when the factory checks in. Merging is enforced by your repository, so if you require human-only merges, use branch protection and repository permissions.

How the factory improves itself

Your factory is self-improving, and you define what “better” means. Scorers grade completed runs against criteria you write, and Self-improvement groups the failures they flag into follow-up runs that propose fixes — to the application code or to the factory’s own definition. Every proposal arrives as a change for your review; nothing is adopted on its own.

The factory’s definition is open to the same loop. Anyone on the team, or an agent, can propose changes to its instructions, skills, models, or other definition files, and definitions stored in GitHub go through pull request review and configuration checks before a change reaches the production branch.

See measure and improve for the evaluation workflow, or build a self-improving agent to apply the same pattern to a standalone agent.