Warp Factories Moves Coding Agents From Laptops to the Cloud

Warp just launched Warp Factories, an infrastructure layer for running fleets of coding agents across the entire software development lifecycle. Instead of treating agents as personal tools that developers run on their laptops, factories move the work to the cloud, define it as version-controlled code, and let teams measure, benchmark, and self-improve their agent workflows over time. Warp Factories provide flexible, open infrastructure to accelerate companies building internal cloud software factories, helping engineering leaders measure and improve coding agent ROI over time.

The problem with laptop agents

Warp CEO Zach Lloyd argues that the current pattern, where every engineer installs their own coding agent locally, has two structural flaws. The first is measurement: teams can tell that agents help, but can not tell whether the productivity gain justifies the token spend. The second is governance. Running agents in the cloud, steering them, bringing work into a local environment, setting up memory across agents, and setting up evals is a huge infrastructure undertaking to do right.

Factories reframe the problem. A cloud software factory is an automation loop around the software development lifecycle: triage, spec, implement, review, verify, ship, monitor, where a mix of agents and humans moves work forward at each step. Warp is betting this becomes as ubiquitous as CI/CD, and that most teams should not be rebuilding it from scratch.

Terraform, but for agents

The core primitive is a factory defined in YAML. Repositories, agent roles, models, permissions, triggers, and human checkpoints all live in one config that can be rolled back, canaried, and tested like any other infrastructure. A minimal definition looks like this:

schemaVersion: v1alpha1
name: pr-review
repositories:
  - owner: acme
    name: web
agentDefaults:
  model: claude-5-fable-high
# agents/foreman/agent.md
agentType: FOREMAN
# automations/on-pr/automation.md
agent: review
triggers:
  - provider: github
    event: pull_request_ready

Because the config is code, agents themselves can propose changes to it, which is the mechanism behind Warp's self-improvement loops.

How work flows through a factory

A work item enters through a trigger, either explicitly through a Slack message or implicitly through something like a Jira tag. That fires the foreman, an orchestrator agent that splits the task across specialized subagents. Warp's default assembly line includes:

• Triage: decides whether an item should be implemented, spec'd, or parked
• Spec: works with a human to define ambiguous changes
• Implement: writes the code
• Review: reviews the diff

All of these agents get computer use on Linux and Mac so they can actually reproduce bugs and verify that a fix works end-to-end. Verification recordings get attached to the PR so a human reviewer never has to pull the branch down to check behavior. The platform integrates with Linear, Jira, Slack, and Teams, enabling AI agents to work within the services engineering teams already use, so companies do not need to completely rebuild their software development processes to begin automating individual operations.

Bring your own model, bring your own harness

Warp is deliberately not locking teams into one model or one agent runtime. Users can choose their own coding model and harnesses as necessary; the system works as well with Codex as Claude Code. You can also run Warp's own agent for multi-model access, which includes open-weight options. The point is to let teams benchmark configurations against their own workflows rather than commit to a vendor's default.

That flexibility extends to inference and hosting. Teams can bring their own inference, their own hosting, and keep all agent conversations, memories, and eval data on their own infrastructure, with a zero-data-retention policy blocking any training use.

Metrics and self-improving agents

Every factory ships with a metrics dashboard tracking cost per PR, code quality scores, and throughput, all queryable through the API, SDK, and an MCP server. Warp reports that its own internal factory currently handles about 30% of tasks with automation coverage, roughly 200k agent runs per day across all customer factories, and a 20% reduction in cost per PR over time.

The more interesting piece is what sits on top of those metrics. Observer agents grade a sample of runs against scorers, then open pull requests against the factory config itself, tweaking which model handles which stage, what context is provided, or the contents of skill files. Benchmarks let you pin a fixed task set and compare configurations directly, for example running GLM 5.2 in Warp's harness against Claude Opus running through Claude Code on the same frontend tickets.

Factory MCP: escape hatch to local agents

The Factory MCP server is how the cloud layer talks to whatever local agent a developer prefers. From Claude Code, Codex, Cursor, or the Warp terminal, an engineer can push a task into the factory, pull status back, or grab an in-progress session down to their laptop to iterate. A CLI call to trigger a run looks like:

warp agent run-cloud --environment ENV_ID \
    --prompt "fix LIN-482, low risk only"

This matters because it means factories do not force a workflow change on individual developers. Their editor and CLI stay the same; only the target of long-running or asynchronous work shifts to the cloud.

Access and pricing

Warp Factories is in closed early access. Qualifying organizations get up to $10,000 in factory usage credits to get started, and you request access through the early access form. There is no public pricing tier yet, and billing runs on platform credits shared with Warp's existing cloud agent product.

Why this matters

The framing shift here is worth pausing on. Most agent products in this space, whether Devin-style teammates or GitHub's Copilot Workspace, present themselves as finished products or virtual employees. Warp is explicitly refusing that framing and positioning factories as programmable infrastructure that teams own and extend. Warp calls this AI sovereignty: you own your data, inference and compute, and Warp provides the infrastructure and control plane while you own and customize the rest.

For teams already stitching together GitHub Actions runners, Docker containers, and homegrown Slack bots to run agents at scale, this is a serious shortcut. For anyone still doing interactive prompting one laptop at a time, it is a preview of where the industry is heading. Software development is shifting from interactive coding agents to cloud software factories, systems that automate major parts of the SDLC while improving security, compliance, and measurable ROI. The bet is that the winning teams over the next couple of years will be the ones who standardized this loop earliest, not the ones who wrote the most prompts.