Warp launched Factories on Tuesday, August eighteenth, 2026, a cloud system for running agents across the whole development lifecycle rather than inside one editor. A factory is defined in version controlled YAML, and it routes work through triage, specification, implementation, review and verification stages, with humans kept at the decision points. The details worth your attention are not the agents. They are that the pipeline is code you can review and roll back, that you can bring your own inference and compute, and that the thing ships with a metrics dashboard measuring cost per pull request. Here is what that design gets right and where it asks for trust.
The short answer
Warp launched Factories on Tuesday, August eighteenth, 2026. A factory is a version controlled YAML pipeline that moves work through triage, specification, implementation, review and verification agents, orchestrated by a foreman that picks the model and harness per subtask. Work enters from Slack, Teams, Linear, Jira, GitHub and GitLab, or via API, SDK and CLI. You can bring your own inference and compute, self host, keep the data exhaust and enforce zero data retention. It is in closed beta.
Most agent tooling still assumes the interesting work happens in an editor with one person watching. Warp Factories, launched Tuesday, August eighteenth, 2026, assumes the opposite, and the assumption is worth examining even if you never enrol in the beta.
The shape of a factory
A factory is a pipeline over the ordinary phases of software work: triage, specification, implementation, review and verification. What changes is that any of those phases can be handled by an agent, with humans placed at the decision points rather than at every step.
The default line ships four agents. Triage evaluates what comes in and decides what it is. Spec works with a human when the requirement is not clear enough to implement, which is the phase most agent tooling skips and then pays for later. Implementation writes the code, with computer use available so it can drive a graphical interface. Review evaluates the resulting change. You can define your own agents on top of these.
Above them sits an orchestrator called the foreman, which routes each work item along the line and selects the model and harness for each subtask. That last part is the useful bit of the abstraction. Different stages genuinely want different models, since triage is cheap classification and implementation is not, and hard coding one model for the whole pipeline is how these systems get expensive.
Work enters from Slack, Teams, Linear, Jira, GitHub and GitLab, or directly through an API, SDK or CLI. There is also a Factory MCP integration, letting a local coding agent such as Claude Code or Cursor push work into a factory and pull tasks back down for local iteration, which is a sensible acknowledgement that people will keep working locally regardless of what the pipeline does.
The design decision that matters
Strip away the agents and one choice carries most of the value: a factory is defined in version controlled YAML, in the same spirit as infrastructure as code.
This sounds like plumbing and is not. Right now, most teams running agents keep their real configuration in prompts pasted into settings panels, in a document somewhere, or in nobody's head. When output quality drifts, there is no diff to read and nothing to revert to. You cannot bisect a prompt you did not version, and you cannot review a change that was never written down.
Putting the pipeline in a file fixes that. A change to how your review agent behaves becomes a pull request, with an author, a reason and a rollback. You can compare two configurations by checking out both. You can bisect a regression in the pipeline the same way you bisect one in the application. It is the identical argument that moved server configuration out of hands and into repositories, and the argument holds for the same reasons.
The second decision worth crediting is that Warp does not force the data path. You can bring your own inference infrastructure or use Warp's, self host or use Warp hosting, and keep the data exhaust the system generates, which means agent conversations, evaluations and memories. Zero data retention policies are supported so your data is not used for training, and the platform works across multiple models and harnesses including open weight ones, with Claude Code, Codex and Warp's own agent supported.
In regulated environments this is usually the whole conversation. The blocker on agent adoption there is rarely capability, it is where the code goes, who can retain it and whether that path can be described to an auditor. Being able to answer with your own infrastructure is worth more than another point on a coding benchmark.
Measure it, or it will quietly cost you
The part of the launch we would use first is not an agent at all. It is the metrics dashboard, which tracks cost per pull request alongside code quality and efficiency, with evaluation scorers and the ability to benchmark model and harness configurations against each other.
Agent pipelines do not usually fail loudly. They fail by producing a steady flow of plausible changes that look reasonable, pass a shallow review, and consume the scarcest resource on the team, which is senior attention. A pipeline generating forty pull requests a week of which six merge is not a productivity gain, it is a review tax with extra steps. Cost per pull request measured against merge rate is the number that tells you which situation you are in, and having it in the product rather than in a spreadsheet you never build is the difference between knowing and assuming.
Warp also ships self improvement loops, where observer agents identify optimisation opportunities and open pull requests against the factory definition itself. This is the most interesting and the most demanding feature in the launch. It is coherent, since the definition is code and agents can propose changes to code. It also means the system can propose changes to the rules governing its own behaviour, so the review gate on those pull requests needs to be a real human one, held to a higher standard than an ordinary change, not a rubber stamp because the diff is small.
Honest limits
This is a closed beta with limited onboarding and no general availability date, and qualified organisations get ten thousand dollars of free usage on enrolment. Free credits are a reasonable trial offer and also a strong incentive to run more agent work than you otherwise would, so measure during the trial rather than after it.
The claim that a basic factory can be configured in about five minutes is plausible for the default line and says nothing about the work of tuning it to a real codebase, which is where the effort actually goes. Warp reports roughly thirty percent of its own internal tasks running through factories, which is a genuine data point about a tooling company running its own product on a codebase it knows perfectly. Your ratio on a legacy service with thin test coverage will be different, and the verification stage is exactly where that difference shows up.
The broader pattern is the thing to take away regardless. Agent tooling is moving out of the editor and into pipelines that look like CI, defined as code, measured on cost per accepted change. Whether or not you enrol, the shape of that is worth understanding, and the first step costs nothing: write down what your agents are currently configured to do, and put the file under version control.
Sources and further reading
- Introducing Warp Factories, open, flexible infrastructure for building your software factory, Warp, August 2026
- Warp's new system is an out-of-the-box software factory for AI development, TechCrunch, August 18, 2026
- Warp launches AI software factories to automate coding workflows, Mezha, August 2026
Frequently asked questions
What is a Warp Factory?
It is a pipeline for agent driven development, defined as version controlled YAML in the same spirit as infrastructure as code. The default factory contains a triage agent that evaluates incoming work, a spec agent that works with a human on the requirements when they are unclear, an implementation agent that writes the code, and a review agent that evaluates the change. An orchestrator called the foreman routes each item along the line and picks the model and harness for each subtask. You can add your own agents. Work enters from Slack, Teams, Linear, Jira, GitHub and GitLab, or directly through an API, SDK or CLI.
Why does defining the pipeline as YAML matter?
Because it converts prompt tinkering into a reviewable change. If your agent behaviour lives in a settings panel, nobody can see why last week produced better results than this week, and there is nothing to revert to. If it lives in a file under version control, a change to how your review agent behaves goes through the same diff, review and rollback path as any other change, and you can bisect a regression in the pipeline itself. That is the same reason infrastructure as code beat configuring servers by hand, and it applies here for exactly the same reasons.
Can I use my own models and keep my data?
Yes, and Warp puts real emphasis on it. You can bring your own inference infrastructure or use Warp's, self host or use Warp hosting, and keep the data exhaust the system produces, meaning agent conversations, evaluations and memories. Zero data retention policies are supported, prohibiting use of your data for training. Factories work with multiple models and harnesses including open weight options, and support Claude Code, Codex and Warp's own agent. That combination matters most in regulated environments, where the blocker on agent adoption is usually the data path rather than the capability.
How does it measure whether the automation is working?
Through a metrics dashboard tracking cost per pull request, code quality and efficiency, plus built in evaluation scorers and the ability to benchmark different model and harness configurations against each other. There are also self improvement loops where observer agents spot optimisation opportunities and open pull requests against the factory definition. Cost per pull request is the number to watch. Agent pipelines fail quietly by producing plausible changes that consume review time, and a merged rate alongside a cost per accepted change is the honest measure of whether the pipeline pays for itself.
Who is it for and can I try it today?
It is in closed beta with limited onboarding, and qualified organisations get ten thousand dollars of free factory usage on enrolment. General availability has not been dated. The stated target is teams that want agents in development, testing and review without building the orchestration themselves, which in practice means smaller engineering organisations, since large ones tend to have already built something internal. Warp says roughly thirty percent of its own internal tasks now run through factories, which is a useful data point and also a vendor figure about its own product.