What happened #
Warp published an early-access request page for Warp Factories, a system for running fleets of coding agents across the software development lifecycle, defined in a versioned configuration file and driven through a CLI, REST API, TypeScript SDK and an MCP server, with human approval checkpoints chosen by the customer.
Warp has published a page inviting requests for early access to Warp Factories, which the company describes as a way to "run fleets of coding agents across your SDLC: defined as code, on any model or harness, with humans at the checkpoints you choose." Factories appear as a third product alongside Warp's existing terminal and its agent CLI. Access is gated: the form on the page asks only for an email address, and the page states that qualified customers get up to $10,000 in factory usage. The page does not give a general availability date, a price for Factories, or any description of the selection criteria for early access.
The central artifact is a configuration file. The page shows a sample factory.yaml carrying schemaVersion v1alpha1, a factory name, a list of source repositories, agent defaults that include a model, and typed agents pointed at markdown definition files — one with an agentType of FOREMAN, one of REVIEW — plus an automation bound to a GitHub pull_request_ready event. The example uses two different model identifiers, one as the default and a different one for the review agent, which is how the page illustrates its claim that a factory can run on any model or harness. The v1alpha1 label is Warp's own signal that this format is early and subject to change.
Warp positions Factories as infrastructure rather than an assistant, saying it is "built as a platform, not a vertical product or AI teammate." The page shows four entry points: a setup step run through a skills installer, a CLI command that launches a cloud agent run against an environment with a prompt, a REST call that posts a prompt to an agent-runs endpoint with a bearer token and returns a run identifier and a QUEUED state, a TypeScript SDK wrapping the same call, and an MCP server exposing a send_task tool that takes a factory identifier, a title and a note. The page also says work flows in from chat, tickets and source control with status flowing back to where it started, that runs can be watched, steered and handed off from web, mobile, terminal or IDE, and that every run is scored — with "observer agents" opening pull requests against a customer's own factory configuration to improve it.
Four figures appear on the page: "trusted by 800k+ devs," "30%+ automation coverage — PRs merged, zero edits," "200k/day agent runs across all factories," and "-20% cost per PR, measured over time." None is accompanied by a definition, a baseline, a time window, a number of participating teams, or a description of the workloads involved. What is established here is narrow: Warp has published this page, is accepting early-access requests, and describes this specific architecture and these specific interfaces. What is not established is whether the system delivers the quoted automation or cost results for anyone outside a selected set of customers, since no independent evaluation, customer-published measurement or third-party test of Factories accompanies the announcement.
Read the primary source: warp.dev ↗
Why it matters #
It reframes AI coding from a single assistant in one developer's editor into a repo-level pipeline governed by checked-in configuration, which changes who is accountable for merged code and widens the security and permissions surface — while the performance figures used to justify it remain unverified.
Most AI coding tools to date have been shaped around one developer in one session. Factories describes a different unit of work: a checked-in file that names repositories, models, agent roles, permissions and the points at which a human must sign off. If that pattern holds, the decisions that matter move out of individual chat sessions and into version-controlled policy — reviewable, diffable, and enforced across a team rather than negotiated prompt by prompt. That is a meaningful change in where control sits, independent of how well any particular model performs.
The model-agnostic framing is also a commercial position. By treating models and harnesses as swappable fields in a config file, Warp is trying to occupy the orchestration layer above model vendors, where switching costs accrue to the pipeline rather than to any one provider. Several vendors are competing for that same layer from editors, terminals and hosted platforms. For buyers, the practical question is whether configuration written for one orchestrator can move to another, and the alpha schema version on the page suggests that portability question is unsettled even within Warp.
The headline metric deserves scrutiny rather than acceptance. "PRs merged, zero edits" measures how often humans did not intervene, which is not the same as measuring whether the change was correct. A high figure can reflect capable agents, but it can equally reflect thin review, low-risk change selection, or tasks scoped narrowly enough to be nearly mechanical. Without a stated definition of automation coverage, the sample of repositories, and the defect or rollback rate over the same period, the number cannot be compared against a team's current baseline or against a competitor.
The security and accountability surface widens with this design. A factory holds write access to source repositories, long-lived API credentials, ticket and chat integrations, and an MCP endpoint through which external tools can inject tasks — each of which is an instruction path into a system that can open pull requests. The self-improvement loop compounds this: agents that propose changes to the configuration governing agents make the audit question recursive, because the policy under review can itself be modified by the system it governs. Whether those proposals require human approval, and what the permission and logging model looks like, is not described on the page.
What to watch next #
Watch for general availability and pricing, a stable schema beyond the v1alpha1 label, published methodology behind the automation and cost-per-PR claims, and concrete detail on permissions, secrets handling and whether the self-improving "observer agent" pull requests require human approval.
First, the basics of availability. Whether Factories moves from gated early access to general availability, what it costs beyond the $10,000 usage credit offered to qualified customers, and whether the configuration schema advances past the v1alpha1 marker into something Warp commits to supporting. Published documentation for the API, the CLI flags, the agent types and the automation triggers would let engineering teams evaluate the design without joining a waitlist, and would show how much of the page's example configuration is already real versus illustrative.
Second, independent measurement. The useful signal will be customers publishing their own numbers — what share of pull requests merged without edits, what happened to defect and revert rates over the same window, and how cost per pull request was calculated including compute for retries and failed runs. If Warp releases the methodology behind the automation-coverage and cost figures, those claims become checkable. If the definitions shift or stay unstated while the figures grow, that is itself informative.
Third, governance detail for regulated buyers. Warp's site names financial services, insurance and telecommunications as target industries, which raises specific questions the launch page does not answer: how secrets are scoped per repository and per run, whether agent write access can be limited to branches rather than main, what audit trail exists for a run initiated through the MCP send_task tool, whether observer-agent pull requests against the factory config are blocked pending human approval, and how data handled during runs is retained.
Fourth, whether this becomes a pattern or stays a product. Configuration-as-code for agent fleets is the kind of idea that either converges on a shared format across vendors or fragments into per-vendor lock-in. Watch for competing orchestrators adopting similar declarative files, for pressure to keep model selection genuinely open rather than defaulting to preferred providers, and for the first public reports of failure modes — a mis-scoped permission, a prompt-injected ticket that reached an agent with repository write access, or a self-improvement loop that degraded a configuration rather than improving it.