Factories
Factory configuration overview
# Factory configuration overview Factory configuration defines the operating model for repeatable software work: repositories, role boundaries, approved tools, execution resources, intake paths, and evidence. A live-managed factory keeps configuration in the control room. After you link a definition source, the factory becomes file-managed and the Git repo becomes its reviewable desired state. :::note Warp Factories is currently in closed beta. Access is limited while Warp works with participating teams to validate the product. ::: ## Repositories and shared defaults Choose repositories that form one workflow boundary. Every agent works from the factory's repository set, so separate unrelated products or access requirements. Set shared defaults for the configuration most roles use: * **Model or harness** - Establish a baseline runtime and model. * **Runner and environment** - Establish the default compute and workspace. * **Secrets and MCP servers** - Put baseline role access in `agentDefaults`. Add top-level entries only when every agent requires them. * **Credential strategy** - Choose whether a run uses credentials from its execution principal or the principal that created the run. For a file-managed factory, use [factory definitions as code](./factory-as-code) for the exact directory structure, inheritance rules, validation behavior, and synchronization model. ## Agent roles and responsibilities Define one foreman as the factory's entry point. Add specialized agents for triage, specification, implementation, and review when those stages have distinct responsibilities. State what each role owns, what evidence it must produce, when it returns work, and which decisions require a human. Keep verification within implementation and review. The default roster is a starting point, not a required fixed pipeline. Add a custom agent when a workflow needs a durable specialty with separate instructions or tools. Add an automation when an event or schedule must start a defined prompt. See [factory agents](./factory-agents) for role guidance and [how Warp Factories work](./how-factories-work) for the complete handoff model. ## Models and harnesses Select models and harnesses per role. Specification, implementation, and review have different context, reasoning, and tool requirements. Use a factory-level default, then override roles that need a different runtime. The `model` shorthand selects the Warp Agent harness, serialized as `type: oz`. An explicit `harness` mapping selects the Warp Agent, Claude Code, or Codex and carries harness-specific configuration. Compare [supported harnesses](../platform/harnesses/) and review general guidance in [model choice](../agents/inference/model-choice). ## Skills, MCP servers, and secrets Give each agent the minimum instructions and tool access its role needs: * **Factory-wide skills** - Put shared repository conventions and common workflows under `skills/`. * **Per-agent skills** - Put role-specific workflows under `agents/<name>/skills/`. * **MCP servers** - Reference existing Warp MCP servers when an agent needs approved external tools or context. * **Secrets** - Reference Warp-managed secret names instead of putting values in the definition. Skills are directories, not YAML fields. Read [Skills for agents](../agents/capabilities/skills) for the file format. Use [MCP servers for cloud agents](../platform/mcp) to configure tools and [cloud agent secrets](../platform/secrets) to store credentials. ## Environments and runners Separate workspace configuration from compute: * **Environment** - Defines repositories, toolchains, images, and setup for a cloud run. * **Runner** - Defines the operating system, architecture, compute shape, and sandbox image. * **Host** - Determines whether the workload runs on Warp-hosted or self-hosted infrastructure. Reference an existing environment from the factory or a role. Define runners when roles need explicit compute, and override defaults only for workloads with different requirements. See [cloud agent environments](../platform/environments), [cloud agent runners](../platform/runners), and [infrastructure and security](./infrastructure-and-security) for execution, inference, storage, secret, and governance decisions. ## Automations and integrations Choose intake paths based on where the source context lives. Preserve that context and route the event to the foreman unless a specialized role owns intake. An automation defines its target agent, run prompt, and one or more triggers. Integrations connect the external system that emits those events and receives results. Keep the automation prompt focused on interpreting the event; put durable role behavior in the target agent or a skill. Use [connect your factory](./connect-your-factory) for intake patterns. Refer to [platform integrations](../platform/integrations/) and the [triggers reference](../platform/triggers/) for underlying event sources. ## Measurement Measurement configuration remains control-room state rather than part of the factory definition tree. Configure scorers, evaluations, and benchmarks there, then review activity, costs, and results for repeated failures tied to a role, tool, or handoff. When evidence identifies a problem, change one concrete part of the operating model and compare later outcomes. Benchmarks support that decision; they do not replace human judgment. See [measure and improve](./measure-and-improve) for metrics, scorers, evaluations, benchmarks, and the reviewed improvement loop. ## Configuration sources Use each surface for a different job: * **Control room** - Stores configuration for a live-managed factory. It also shows work items, run history, automations, evaluations, benchmarks, and current state. * **Definitions as code** - Becomes the desired state after a definition source is linked. Use version control to review repositories, agents, prompts, triggers, runners, skills, and defaults together. For a GitHub-backed definition, make configuration changes in the repo and merge them through pull requests. The factory configuration check validates changes before they reach the production branch. The control room does not write file-managed configuration back to a customer-owned GitHub source. For a Warp-managed factory repo, supported control room edits write through as commits, validate the resulting tree, and synchronize the commit. The repo remains the source of truth. The control room reports operational state. It does not replace source review or human approval for consequential engineering decisions. ## Continue configuring * [Factory definitions as code](./factory-as-code) - Author and validate the complete source tree. * [Factory agents](./factory-agents) - Configure responsibilities and role handoffs. * [Connect your factory](./connect-your-factory) - Add intake paths, integrations, automations, and Factory MCP. * [Measure and improve](./measure-and-improve) - Evaluate outcomes and compare configurations. * [Infrastructure and security](./infrastructure-and-security) - Choose hosting, inference, storage, credentials, and security controls.Tell me about this feature: https://docs.warp.dev/factories/configure-your-factory/Factory configuration combines repositories, agent roles, tools, execution infrastructure, automations, and measurement decisions.
Factory configuration defines the operating model for repeatable software work: repositories, role boundaries, approved tools, execution resources, intake paths, and evidence.
A live-managed factory keeps configuration in the control room. After you link a definition source, the factory becomes file-managed and the Git repo becomes its reviewable desired state.
Repositories and shared defaults
Section titled “Repositories and shared defaults”Choose repositories that form one workflow boundary. Every agent works from the factory’s repository set, so separate unrelated products or access requirements.
Set shared defaults for the configuration most roles use:
- Model or harness - Establish a baseline runtime and model.
- Runner and environment - Establish the default compute and workspace.
- Secrets and MCP servers - Put baseline role access in
agentDefaults. Add top-level entries only when every agent requires them. - Credential strategy - Choose whether a run uses credentials from its execution principal or the principal that created the run.
For a file-managed factory, use factory definitions as code for the exact directory structure, inheritance rules, validation behavior, and synchronization model.
Agent roles and responsibilities
Section titled “Agent roles and responsibilities”Define one foreman as the factory’s entry point. Add specialized agents for triage, specification, implementation, and review when those stages have distinct responsibilities.
State what each role owns, what evidence it must produce, when it returns work, and which decisions require a human. Keep verification within implementation and review.
The default roster is a starting point, not a required fixed pipeline. Add a custom agent when a workflow needs a durable specialty with separate instructions or tools. Add an automation when an event or schedule must start a defined prompt.
See factory agents for role guidance and how Warp Factories work for the complete handoff model.
Models and harnesses
Section titled “Models and harnesses”Select models and harnesses per role. Specification, implementation, and review have different context, reasoning, and tool requirements.
Use a factory-level default, then override roles that need a different runtime. The model shorthand selects the Warp Agent harness, serialized as type: oz. An explicit harness mapping selects the Warp Agent, Claude Code, or Codex and carries harness-specific configuration.
Compare supported harnesses and review general guidance in model choice.
Skills, MCP servers, and secrets
Section titled “Skills, MCP servers, and secrets”Give each agent the minimum instructions and tool access its role needs:
- Factory-wide skills - Put shared repository conventions and common workflows under
skills/. - Per-agent skills - Put role-specific workflows under
agents/<name>/skills/. - MCP servers - Reference existing Warp MCP servers when an agent needs approved external tools or context.
- Secrets - Reference Warp-managed secret names instead of putting values in the definition.
Skills are directories, not YAML fields. Read Skills for agents for the file format. Use MCP servers for cloud agents to configure tools and cloud agent secrets to store credentials.
Environments and runners
Section titled “Environments and runners”Separate workspace configuration from compute:
- Environment - Defines repositories, toolchains, images, and setup for a cloud run.
- Runner - Defines the operating system, architecture, compute shape, and sandbox image.
- Host - Determines whether the workload runs on Warp-hosted or self-hosted infrastructure.
Reference an existing environment from the factory or a role. Define runners when roles need explicit compute, and override defaults only for workloads with different requirements.
See cloud agent environments, cloud agent runners, and infrastructure and security for execution, inference, storage, secret, and governance decisions.
Automations and integrations
Section titled “Automations and integrations”Choose intake paths based on where the source context lives. Preserve that context and route the event to the foreman unless a specialized role owns intake.
An automation defines its target agent, run prompt, and one or more triggers. Integrations connect the external system that emits those events and receives results. Keep the automation prompt focused on interpreting the event; put durable role behavior in the target agent or a skill.
Use connect your factory for intake patterns. Refer to platform integrations and the triggers reference for underlying event sources.
Measurement
Section titled “Measurement”Measurement configuration remains control-room state rather than part of the factory definition tree. Configure scorers, evaluations, and benchmarks there, then review activity, costs, and results for repeated failures tied to a role, tool, or handoff.
When evidence identifies a problem, change one concrete part of the operating model and compare later outcomes. Benchmarks support that decision; they do not replace human judgment.
See measure and improve for metrics, scorers, evaluations, benchmarks, and the reviewed improvement loop.
Configuration sources
Section titled “Configuration sources”Use each surface for a different job:
- Control room - Stores configuration for a live-managed factory. It also shows work items, run history, automations, evaluations, benchmarks, and current state.
- Definitions as code - Becomes the desired state after a definition source is linked. Use version control to review repositories, agents, prompts, triggers, runners, skills, and defaults together.
For a GitHub-backed definition, make configuration changes in the repo and merge them through pull requests. The factory configuration check validates changes before they reach the production branch. The control room does not write file-managed configuration back to a customer-owned GitHub source.
For a Warp-managed factory repo, supported control room edits write through as commits, validate the resulting tree, and synchronize the commit. The repo remains the source of truth.
The control room reports operational state. It does not replace source review or human approval for consequential engineering decisions.
Continue configuring
Section titled “Continue configuring”- Factory definitions as code - Author and validate the complete source tree.
- Factory agents - Configure responsibilities and role handoffs.
- Connect your factory - Add intake paths, integrations, automations, and Factory MCP.
- Measure and improve - Evaluate outcomes and compare configurations.
- Infrastructure and security - Choose hosting, inference, storage, credentials, and security controls.