Warp introduced Warp Factories on August 18, 2026, to help engineering organizations run AI coding agents through a shared, configurable pipeline. According to CEO Zach Lloyd, Warp's own engineering teams already use the infrastructure to automate 20 to 30 percent of their weekly pull requests.

Running agents at that volume takes more than a model API and a connection to a repository. Someone has to manage agent execution, connect planning and communication tools, evaluate results, and account for spending. Stripe's “minions” system and Ramp's background agents represent substantial internal investment in this kind of tooling. Many organizations don't have the engineering capacity to build an equivalent system.

Factories aims to provide that infrastructure, including controls for cost, quality, and changes to the agent pipeline itself. The last part deserves particular attention: observer agents can examine factory runs and propose configuration changes through pull requests.

How the pipeline works

A Factory organizes software tasks into stages such as triage, specification, implementation, review, and verification. Specialized agents handle those stages. A “foreman” orchestrator routes work through the appropriate stages and selects models and harnesses, the software that lets an agent use tools and carry out a task.

Those routing choices happen for individual work items. A task might warrant Claude Code's deeper reasoning, a faster open-weight model, or a cheaper harness. Poor routing can waste money on a straightforward task or send difficult work to an agent that can't handle it reliably. At higher volumes, the system has to manage both cost and quality.

The factory definition is version-controlled code. Teams can inspect changes, roll back to an earlier configuration, or test a new version on a subset of work before applying it broadly. This is a canary deployment, a familiar way to limit the consequences of a bad infrastructure change.

Version control also gives teams a record to investigate when results deteriorate. If a code quality score falls from 93 percent to 81 percent, for example, the configuration history can show what changed between the two versions. Those figures illustrate the kind of comparison a team could make; they aren't evidence of a measured regression. Treating agent configuration as production infrastructure is a useful operating model.

What the automation rate establishes

Lloyd told TechCrunch that running these systems properly is a large infrastructure undertaking. He identified cross-agent memory, cloud agent management, local integration, and evaluation as major challenges.

Warp's reported 20 to 30 percent automation rate is a useful indication of how much work the company is assigning to its pipeline. It also describes a different review burden from inline completion or simple code generation. An agent that opens a pull request presents code that has already been committed, tested, and marked as ready for review. Reviewers need to evaluate the resulting change and the assumptions behind it, rather than consider a suggestion while writing the code themselves.

The work outside that automated share can include tasks with ambiguous requirements, sustained context, organizational judgment about architecture, or design choices that models still handle unpredictably. The reported percentage doesn't establish exactly how Warp's remaining work breaks down.

Lloyd expects the automated share to grow. Reaching 50 percent over the next twelve to eighteen months is a plausible forecast as models and context windows improve, but it isn't an established trajectory. A headcount plan would need longer-term evidence about accepted changes, review effort, and quality, rather than a single company's current PR percentage.

Agents can propose changes to the factory

According to the launch announcement, observer agents analyze factory runs and propose improvements by opening pull requests against the factory definition. That makes a proposed adjustment visible in the same review process used for application code.

For example, repeated failures might reveal that a particular task type is being triaged incorrectly, or that the specification stage produces instructions that lead to implementations reviewers won't accept. The observer can turn that pattern into a concrete configuration proposal, reducing the amount of manual log analysis needed to identify a possible fix.

A proposal still needs validation. Calling this a self-improvement loop doesn't mean every suggested change improves the system. Someone has to review the reasoning and assess the results. Factory configuration PRs need the same care as changes to other production systems, because they affect how subsequent work gets done.

Canary deployments help here. Running a proposed configuration against a limited set of work items gives the team a chance to compare results before changing the entire pipeline. Version control makes the change reviewable and reversible; the evaluation process determines whether it should stay.

Shared controls for cost and quality

Wiring agents into models and CI systems is only part of the work. Giving a dozen teams access can leave an organization with many custom pipelines, inconsistent quality standards, and token spending that's difficult to explain when the bill arrives.

Factories provides a shared control plane for those operations. It tracks cost per PR and token consumption per stage, and it scores code quality. Warp's example dashboard shows a 93 percent quality score and 96 percent efficiency. These are example dashboard values, not independently established performance results.

Teams can define custom scorers to reflect their own quality criteria. An enterprise shipping software into regulated industries might weight license-header compliance or test coverage differently from a consumer software startup. That flexibility matters because a single headline score can't express every organization's acceptance criteria.

Integrations with Linear, Jira, Slack, and Microsoft Teams connect the pipeline to existing workflows. Work can enter through planning tools, and results can appear in the communication channels teams already use. The measurement infrastructure is as much a part of the offering as the agent orchestration.

Where the pipeline can become expensive

Agents that open PRs can generate a large amount of plausible work that passes automated checks but still takes substantial human effort to evaluate. A pipeline can consume review capacity before its quality problems become obvious enough to trigger a halt. Increasing output is useful only while the team can assess it properly.

Several signals deserve close attention:

  • Cost per PR rises while quality scores remain flat. More spending isn't producing a measurable improvement.
  • Review latency grows because agents open PRs faster than engineers can evaluate them.
  • Observer agents repeatedly propose configuration changes without clear evidence that results are improving.

The third signal is especially ambiguous. Frequent changes could reflect productive learning, or they could indicate a poorly tuned factory generating churn. A dashboard alone can't resolve that distinction. Someone with operational context needs to examine the failures, the proposed fixes, and their effects.

As of August 25, 2026, Warp is offering $10,000 in free factory credits to qualified organizations during the closed beta. That gives teams room to establish quality baselines and identify failure modes before committing to production volume. A useful trial would examine both the changes agents produce and the human review work those changes create.

Fast setup still needs careful configuration

Warp says an organization can have a factory running against its codebase in under five minutes. That is a setup claim, not a reason to make deployment decisions at the same speed. Quality criteria, review responsibilities, and rollback triggers deserve at least a day of careful thought before broad use.

The practical change is that organizations without the headcount to build an internal agent platform now have a packaged option for coordinating work and tracking its costs. They still need to decide which work belongs in the pipeline and what evidence is sufficient to accept its output.

Teams adopting Factories should treat its configuration like other production infrastructure: test changes in staging, maintain rollback capability, monitor results, and assign someone responsibility for operational health. Observer agents can propose fixes, but approval and accountability remain engineering work.