SAN FRANCISCO, 20 AUG 2026 — Warp has opened a closed beta of Warp Factories, infrastructure for running coding agents as a pipeline rather than one prompt at a time. A factory triages a ticket, writes a spec, implements it, reviews it, verifies it and monitors the result, and each stage can use a different model.

The interesting claim is not the automation, but the model choice: each stage of the pipeline can use a different one, avoiding a platform-level commitment.

What it is

Triage → spec → implement → review → verifyThe pipeline a factory runs, with monitoring after
Claude Code, Codex, Cursor, open weightsHarnesses and models the platform runs
Per stageEach step picks its own model and harness
Self-host on EnterpriseOwn inference providers, own S3 or GCS for transcripts

Announced on 18 August in closed beta, the platform runs on Warp-hosted infrastructure or self-hosted execution on an eligible enterprise plan. Teams connect supported inference providers, scope secrets, and store transcripts, artefacts and run attachments in their own object storage.

The company describes evaluation against a team's own data, with benchmarks and memory intended to improve the pipeline over time, and claims a factory can be configured against a codebase in under five minutes.

Pipeline is a different product from assistant

An assistant answers a developer. A pipeline consumes a ticket and produces a change, with the developer supervising rather than prompting.

The distinction matters because it moves the unit of work. An assistant's throughput is limited by what a developer can hold in their head and how fast they can type. A pipeline's throughput is limited by concurrent ticket processing and downstream review capacity. The human constraint shifts from authoring to judging.

That is a real change in what an engineering organisation is optimising, and it is not obviously good. Review is the scarcer skill and it does not parallelise well. A system that generates more changes than a team can meaningfully review has only moved the bottleneck, not removed it. Whether these pipelines help depends almost entirely on whether the verify stage is trusted enough to reduce human review rather than add to it.

The five-minute setup claim deserves the scepticism any such claim earns. Configuring a pipeline against a repository is not the hard part. The hard part is deciding what a good specification looks like for your codebase, what the review stage should reject, and what verification means when your test suite is incomplete. None of that is simple configuration. Vendors in this category consistently measure time-to-first-run and customers consistently experience time-to-useful-output, and the gap between those is where adoption succeeds or stalls.

Model neutrality as the product

The option to pick a model for each stage is the key design decision, and its timing is specific.

We reported this week that SpaceX closed a US$60 billion acquisition of Cursor, and argued the open question was whether the editor keeps routing to competing frontier models. A platform launching days later whose central promise is that you choose the model per stage is selling exactly the property that acquisition put in doubt.

There is a technical argument for it independent of the politics. The stages have different requirements. Triage is cheap classification. Specification needs careful reasoning. Implementation depends on code fluency and long context. Review demands scepticism. Verification is closer to test execution than generation. Using one frontier model for all five is convenient and wasteful, and on a large enough volume the cost difference between the right model per stage and the best model everywhere is substantial.

The counter-argument is operational. Five models means five failure modes, five sets of rate limits, five pricing changes to track and five behaviour shifts when any vendor updates. Neutrality is a benefit, but it carries an integration cost. Small teams frequently discover that cost exceeds the benefit.

The self-hosting option is the regional detail

The ability to run execution on your own infrastructure, connect your own inference providers, and keep transcripts in your own object storage is what makes this procurable in regions with data residency rules.

An agent pipeline sees more of a codebase than any individual engineer does, and the transcripts are a running record of what the system knows about it. For a bank in Singapore, a government contractor in Malaysia or anyone operating under a data residency obligation, that record is the compliance question, and a hosted-only product frequently cannot be bought at all.

The limit, of course, is that self-hosting execution is not self-hosting inference. If the models still run on somebody else's endpoint in another jurisdiction, the code still leaves. What the architecture allows is running open-weight models on infrastructure you control, and that is the configuration a regulated buyer here would actually need — considerably more work than the five-minute setup, and the only version that satisfies the constraint.

What this says about where the tooling is going

Two years ago the product category was autocomplete. Last year it was chat in the editor. This year it is a fleet, and the artefacts of the category are starting to look like continuous integration rather than like an IDE feature.

There is a logic to this progression. Once a model can reliably complete a bounded task, the constraint shifts from capability to orchestration: queuing, retries, isolation, cost control, evaluation, and audit. Those are infrastructure problems with well-understood shapes, and the companies that solve them are usually not the companies that built the model.

This raises the question every team should ask before adoption: if the pipeline writes the spec, the implementation, and the review, what exactly is the human approving?

What we could not establish

Whether it works. This is a closed beta with no published evaluation of pipeline output quality against human-authored changes, and the entire value proposition rests on that comparison.

Pricing is also unestablished, as is how cost scales with tickets processed. Other open questions: what the verify stage does (run tests, static analysis, or another model's judgement?); how failures are surfaced; which inference providers are supported for self-hosting; whether open-weight models can run entirely on customer infrastructure; and how the memory and self-improvement features handle a changing codebase.

What to watch

Watch for a published evaluation on somebody else's codebase. Every vendor in this category claims measurable improvement and very few publish a methodology anyone can reproduce.

Then watch whether per-stage model selection is actually used. If most customers configure one model for everything, neutrality was a positioning choice rather than a feature, and the cost argument that justifies it will quietly disappear from the marketing.

Finally, watch review capacity. The interesting failure of this category will not be bad code generated; it will be good code generated faster than anyone can responsibly approve it, and the organisations that notice that early will be the ones that measured their review throughput before they raised their generation throughput.