Warp launches Factories for code-defined cloud agent workflows

• Warp Factories is a cloud control plane whose factories are configured as code, with model choice, harness choice, evaluations, memory and self-improvement in the product scope, according to Warp's launch announcement.
• Work can enter from Slack or Teams, Linear or Jira, GitHub or GitLab, and local agents through Factory MCP, as Warp's integrations post lists.
• The system supports Warp's multi-model agent, including open-weight models, or direct Claude Code and Codex harnesses, per Warp's harness post.
• Factory agents have computer use on Linux and Mac, and Warp says recordings can be attached to pull requests as evidence of a change, in Warp's computer-use post.
• The launch starts as a limited-company beta: Warp's measurement post describes cost and velocity telemetry, while Warp's access post offers selected organizations $10,000 in usage.

Warp's launch post says its default factory divides a repository's work among triage, specification, implementation and review agents, with separate skills, MCP servers and permissions. Its benchmarking guide treats the harness as an experimental variable too, including tool sets, context compaction, sandboxing and the non-interactive entrypoint. The Warp docs place Factories in an automation platform that also exposes a CLI, API and SDK.

A factory definition is version-controlled configuration rather than a dashboard-only workflow. Warp says teams can roll definitions forward or back, canary and test them, and encode repositories, agents, skills, MCPs and permissions in that definition.

• Repositories: one or more codebases, generally for a product.
• Agents: distinct roles in the pipeline.
• Capabilities: skills, MCP servers and permissions scoped to the factory.

Warp connects the factory to the systems where engineering work already appears. Its launch post says a run can be started explicitly, such as a Slack message to the foreman, or implicitly, such as a tag on a Jira issue.

• Chat: Slack and Teams.
• Task trackers: Linear and Jira.
• Source forges: GitHub and GitLab.
• Local tooling: terminals, IDEs and other coding agents through Factory MCP.

The foreman receives the triggering context, spins out subagents and selects their model, harness and context, Warp says in its launch post. The default roles split the path as follows:

1. Triage decides whether to implement, spec or wait.
2. Spec works with a human on ambiguous or complex changes.
3. Implement writes the code.
4. Review reviews the resulting code.

The product separates the model from the harness. Warp offers its own agent for multi-model access, including open-weight models, and names direct Claude Code and Codex execution in Warp's harness post.

The Factory MCP is the bridge back to local tools: Warp's steering guide says an MCP client can submit work, retrieve status and guide a session, while local agents can pull an in-progress task down for iteration.

Warp gives the factory roles computer use on Linux and Mac. Its launch post describes an implementation agent clicking through a dropdown it built, then saving the recording in the pull-request description for human review.

The control room and API expose queryable throughput, cost, quality and ROI data, according to Warp's measurement post. Warp also describes three linked mechanisms:

• Scorers evaluate work-item flow, token use, code quality and defects; teams can define custom scorers.
• Benchmarks run fixed tasks across factory configurations, including model and harness combinations.
• Observer agents score a portion of runs, then can open pull requests changing the factory's model, harness, context or skills to improve the score.

Warp is onboarding a limited number of companies, with access requested through its closed-beta application. The announcement publishes neither a general-availability date nor standard pricing; selected organizations may receive $10,000 of factory usage.