Software factory

A software factory is a development system where specialized agents take new issues through triage, spec, implementation, and review, producing pull requests for your team to merge. Instead of every developer executing every step — reading each issue, writing specs, implementing changes, reviewing output — agents execute and humans review. The team’s job shifts from doing the work to defining the process and raising the quality bar over time.

Warp uses this model to build Warp itself. The agent dashboard at build.warp.dev shows the work Warp’s agents are tackling across the open source repository in real time.

Read on to learn about the two loops that make up a software factory, the agent roles involved, and how to decide if this model is right for your team.

The two loops

A software factory has two loops that work together.

The inner loop is the execution loop: a triage agent, spec agent, implementation agent, and reviewer agent work in sequence, turning a new issue into a pull request for human review.

The outer loop is the improvement loop: a scheduled agent reviews past inner-loop runs, observes where maintainers made corrections, and opens a pull request to update the skill files that drive the inner-loop agents. Over time, the factory gets better without anyone manually rewriting prompts.

The inner loop ships software. The outer loop improves the factory that ships it.

Agent roles

A software factory delegates work to specialized agents, each with a narrow responsibility:

• Triage agent - Reviews new issues for clarity and completeness. Labels issues as ready to implement, needs more information, or a duplicate. Flags open questions for the reporter before implementation begins, so the backlog stays clean and actionable.
• Spec agent - Drafts a product spec (user stories and acceptance criteria) and a tech spec (implementation strategy, relevant code locations, and edge cases). The specs serve as the blueprint for the implementation agent and the review criteria for the reviewer agent.
• Implementation agent - Builds against approved specs. Uses spec context to make better architectural decisions and raises a blocked status when specs are missing or ambiguous rather than guessing.
• Reviewer agent - Checks the implementation against specs, code conventions, and security requirements. Posts inline review comments and validates that acceptance criteria are met before a human reviewer opens the PR.

The warpdotdev/oz-for-oss repository is the complete reference implementation with all four roles deployed in a working system.

How it works

Each agent role is backed by a skill, a markdown file checked into a Git repository that defines the agent’s behavior: what to check, how to classify results, what to output, and when to escalate. Skills are versioned, reviewed as code changes, and composable across repositories.

The inner loop runs when a new issue is filed:

1. A webhook or GitHub Action triggers the triage agent. The agent runs in a cloud environment, analyzes the issue, and applies labels and comments.
2. When the issue is labeled ready-to-spec, the spec agent creates PRODUCT.md and TECH.md in a specs/ directory in the repository.
3. A human reviews and approves the specs.
4. When the implementation label is applied, the implementation agent opens a PR that includes the spec files alongside the code.

Oz orchestrates each agent as a cloud run. Every run has its own environment (repository checkout, secrets, toolchain), its own permissions, and a session link your team can use to inspect what the agent did, steer it mid-run, or hand work back to a local session.

The outer loop runs on a schedule, not in response to events.

A scheduled cloud agent collects signals from past inner-loop runs and generates a diff to the relevant skill files. That diff goes through a normal pull request review before merging. Humans decide what improves; agents propose it.

When to use a software factory

A software factory is a strong fit when:

• Your team has a repeatable development workflow: a backlog of issues with consistent shape, and a process you can write down and teach to an agent.
• The cost of a missed edge case in agent output is recoverable. The agent opens a pull request, not a deploy, so humans stay in control of what ships.
• You want to scale throughput without scaling headcount linearly, or you want to move faster on a large backlog with a small team.

Start with one agent role. Most teams start with a triage agent, which is the simplest loop to close correctly. A well-groomed backlog immediately benefits every developer on the team. Add spec, implementation, and reviewer agents as you build confidence in each step.

Reference implementation

warpdotdev/oz-for-oss is Warp’s open-source software factory platform for GitHub-hosted repositories. It includes a Vercel webhook layer, GitHub App, and skill files for every agent role in the loop: triage, spec, implementation, review, verification, and self-improvement. Get started with the onboarding guide.

Related pages

• Build a triage agent for your issue backlog — Start the series with the simplest agent role.
• Write product and tech specs with agents — Write specs that guide implementation agents.
• Set up your software factory: from triage to PR — Connect the four roles into a working loop.
• Run a software factory in the cloud — Move the loop off your laptop with Oz.
• Build a self-improving agent — Add the outer improvement loop.
• Skills — How skill files work in Warp and Oz.
• Cloud agents overview — Setting up cloud agents on Oz.
• Deployment patterns — Common architectures for cloud agent deployment.