Give each Warp agent trigger an owner and a budget, then choose the agent and where it runs. Keep merge approval on your code host. Warp Factories, in early access since August 2026, packages these settings as a team of agents defined in code.
When you need this
- Engineers want an agent to pick up Slack requests, Linear issues, or failed CI runs.
- You run Claude Code or Codex locally and want the same agent in the background.
- You are evaluating Warp Factories and need to know what it decides and what people still approve.
Trigger and approval map
Triggers
Which events can start an agent, and whose budget pays?
Where Warp connectsSlack, Linear, Jira, and GitHub integrations need a Warp team. Individuals can run cloud agents only from the CLI or API. Scheduled agents run as their creator and draw on that person's usage unless configured to run as a cloud agent on shared team usage.
Agent
Which agent does the work?
Where Warp connectsWarp calls this choice the harness. The options are the Warp Agent on any plan, or Claude Code and Codex on a paid plan, all under the same triggers, environments, secrets, and transcripts. Claude Code and Codex use credentials you supply, so Anthropic or OpenAI bills inference while Warp bills compute and agent hours.
Where it runs
Can the run reach private code and services?
Where Warp connectsWarp-hosted runs use ephemeral Docker sandboxes with 2 to 8 vCPU by plan and up to 80 concurrent agents on Business. Private repositories behind your network need Enterprise self-hosting, either a managed worker that Warp orchestrates or oz agent run in your own CI or Kubernetes. Both use outbound connections only.
Factories
What does a factory decide on its own?
Where Warp connectsA foreman agent routes each work item through triage, planning, building, and review, and can skip stages or send work back. Spec approval lives in the foreman's editable instructions, so no repository permission enforces it. Definitions can live in a GitHub repository, so changes to the factory go through pull request review.
Ownership and review
Who approves what comes back?
Where Warp connectsFactories and cloud agents open pull requests and never merge them. Branch protection and repository permissions stay the approval gate, and every run leaves a transcript and a shareable session to read before approving.
Questions to settle with each team
- Which Slack conversations, labels, and CI events can start an agent, and who maintains the list?
- Which credentials and secrets does each environment carry, and which repositories can they reach?
- Who owns each schedule's spend, the creator or the team?
- Which factory stages need a human sign-off, and where is that written?
Red flags
- Schedules that bill their creator's usage by default, with no owner named to move them before that person leaves the team.
- Agent environments holding long-lived cloud keys when they should use a federated role.
- A factory whose spec approval step was removed from the foreman's instructions.
- Merge rights granted to an agent account.
Products in this piece
Sources
- Official documentation
- 16
- Warp docs: Cloud agents overview
- Warp docs: Automation Platform overview
- Warp docs: Triggers
- Warp docs: GitHub Actions integration
- Warp docs: Harnesses in the Automation Platform
- Warp docs: Access, billing, and identity permissions
- Warp docs: Platform usage
- Warp docs: Security and networking for self-hosted agents
- Warp docs: Self-hosting
- Warp docs: Warp Factories overview
- Warp docs: How Warp Factories work
- Warp docs: Deployment patterns for Warp Factories
- Warp docs: Factory definitions as code
- Warp docs: Transitioning from Oz to Warp Factories
- Warp blog: Introducing Warp Factories (Aug 18, 2026)
- Warp docs: Changelog 2026