Factories > Configure
Factory agents
# Factory agents Warp Factories uses role-specific agents to move a work item from intake to human handoff under the default seeded workflow. Each agent owns a defined responsibility, while the foreman coordinates the work and maintains one continuous conversation with the requester. ## Default agent roles Factory setup offers five default role types. The foreman is fixed, and selecting one to four subagents creates an initial roster of two to five agents. The roles separate orchestration, investigation, planning, implementation, and review so each part of the workflow has a clear owner. | Role | Primary responsibility | Typical output | | --- | --- | --- | | Foreman | Route work and communicate with the requester | Decisions, questions, status, and final handoff | | Triage | Investigate the request and establish scope | Evidence, issue context, complexity, and ambiguity | | Spec | Resolve requirements and define validation criteria | Product and technical specifications in a draft pull request | | Implement | Change and validate the code | Code, tests, validation results, and visual evidence | | Review | Examine the implementation independently | Findings and an advisory verdict | Roles are responsibilities, not a fixed sequence. Small, clear work can skip specification, and review can return work to implementation. In the seeded workflow, any work that enters the spec stage requires human approval before implementation. For the complete lifecycle, see [how Warp Factories work](./how-factories-work). ## Seeded context and memory The selected issue tracker changes the seeded roster's tracker skill and prompt appendix. Linear adds Linear-specific context, Jira adds Jira-specific context, and no tracker omits those additions. The seeded GitHub skills and the foreman's Slack skill remain in all three cases. Each seeded agent receives its own [Auto-memory store](../agents/agent-memory). Warp periodically consolidates eligible conversations into memory, which can change the agent's behavior over time. Account for memory state in before-and-after configuration comparisons; matching visible settings do not guarantee matching accumulated context. ## Foreman The **foreman agent** selects the next role, dispatches work, and preserves context by continuing existing specialist conversations for revisions and follow-ups. It is the only default role that communicates with the requester. Specialists return findings to the foreman, which asks human questions and routes the answers back. The foreman presents the final pull request and evidence, then marks the work item complete after handoff. Completion does not mean that the factory merged or deployed the change. ## Specialized agent responsibilities ### Triage Triage researches the codebase, related issues, and source context. It reproduces a problem only when research does not establish the cause. Triage returns issue context, scope, complexity, and ambiguity so the foreman can request clarification, specification, or implementation. ### Spec Spec interviews the requester through the foreman and turns the answers into product and technical specifications with validation criteria. It opens a draft pull request on a branch that implementation continues. The seeded foreman requires human approval before dispatching implementation, but teams can change this policy in the foreman's instructions. ### Implement Implementation continues the spec branch and draft pull request when they exist. It changes code, adds tests, runs repository validation, reviews the diff, and gathers visual evidence for user-facing changes when computer use is available. It can revise the change after review, but it never merges. ### Review Review examines the change independently and adversarially against requirements, conventions, tests, security expectations, and evidence. It separates clear defects from ambiguous tradeoffs, then returns an advisory verdict to the foreman: accept, revise, or request a human decision. The verdict does not approve or merge the pull request. ## Verification is part of implementation and review The default roster has no separate verify agent. Implementation produces regression, repository, and applicable visual evidence. Review checks that evidence, reruns or extends validation when necessary, and compares the result with the criteria. Custom quality agents can add coverage, but they do not remove these responsibilities. ## Configure agent behavior In the control room, the agent editor supports description, model, runner, host, MCP servers, secrets, and instructions. Configure the harness, environment, and credential strategy through [factory definitions as code](./factory-as-code). Factory setup does not set per-role models. ## Choose models and harnesses by role Each role can use a different model or harness. Supported harnesses include the Warp Agent harness, Claude Code, and Codex. Choose by responsibility rather than relying on mutable default model IDs. | Role | Selection guidance | | --- | --- | | Foreman | Favor orchestration, instruction following, and continuity | | Triage | Favor research, evidence gathering, and connected-tool use | | Spec | Favor requirement synthesis, technical reasoning, and precise criteria | | Implement | Match the coding harness and model to the repositories and toolchain | | Review | Use an independent configuration to reduce correlated mistakes | See [model choice for agents](../agents/inference/model-choice) and [harnesses for cloud agents](../platform/harnesses) for available options. Define reusable procedures with [skills](../agents/capabilities/skills), and scope each role's external access through [MCP servers](../platform/mcp) and [cloud agent secrets](../platform/secrets). ## Extend the roster with custom agents and automations Custom agents can own narrow responsibilities such as documentation, security analysis, migrations, or release checks. They do not need to become mandatory stages. Automations start a selected agent from an event or schedule; they are intake mechanisms, not a replacement for foreman coordination. See [connect your factory](./connect-your-factory) for intake options. ## Human gates and permissions | Decision or control | Default behavior | Source of enforcement | | --- | --- | --- | | Requirements and spec approval | The foreman asks humans to clarify ambiguity and approve every specification | Seeded workflow policy that teams can change | | Pull request merge | Implementation never merges, and the foreman hands the result to a human | Repository permissions determine who can approve or merge | | Runtime access | Each role's environment, managed secrets, and MCP servers follow its effective configuration; built-in harness tools, platform-issued runtime credentials, provider permissions, and network access follow separate controls | Platform configuration and provider permissions | Warp Factories does not define a factory-specific approver role. Human gates in the seeded workflow are not platform-enforced role-based access control, and instructions do not grant authority beyond configured access. Next, encode role instructions, model and harness choices, and access boundaries with [factory definitions as code](./factory-as-code).Tell me about this feature: https://docs.warp.dev/factories/factory-agents/Warp Factories coordinate role-specific agents for triage, specification, implementation, review, and human handoff.
Warp Factories uses role-specific agents to move a work item from intake to human handoff under the default seeded workflow. Each agent owns a defined responsibility, while the foreman coordinates the work and maintains one continuous conversation with the requester.
Default agent roles
Section titled “Default agent roles”Factory setup offers five default role types. The foreman is fixed, and selecting one to four subagents creates an initial roster of two to five agents. The roles separate orchestration, investigation, planning, implementation, and review so each part of the workflow has a clear owner.
| Role | Primary responsibility | Typical output |
|---|---|---|
| Foreman | Route work and communicate with the requester | Decisions, questions, status, and final handoff |
| Triage | Investigate the request and establish scope | Evidence, issue context, complexity, and ambiguity |
| Spec | Resolve requirements and define validation criteria | Product and technical specifications in a draft pull request |
| Implement | Change and validate the code | Code, tests, validation results, and visual evidence |
| Review | Examine the implementation independently | Findings and an advisory verdict |
Roles are responsibilities, not a fixed sequence. Small, clear work can skip specification, and review can return work to implementation. In the seeded workflow, any work that enters the spec stage requires human approval before implementation.
For the complete lifecycle, see how Warp Factories work.
Seeded context and memory
Section titled “Seeded context and memory”The selected issue tracker changes the seeded roster’s tracker skill and prompt appendix. Linear adds Linear-specific context, Jira adds Jira-specific context, and no tracker omits those additions. The seeded GitHub skills and the foreman’s Slack skill remain in all three cases.
Each seeded agent receives its own Auto-memory store. Warp periodically consolidates eligible conversations into memory, which can change the agent’s behavior over time. Account for memory state in before-and-after configuration comparisons; matching visible settings do not guarantee matching accumulated context.
Foreman
Section titled “Foreman”The foreman agent selects the next role, dispatches work, and preserves context by continuing existing specialist conversations for revisions and follow-ups. It is the only default role that communicates with the requester. Specialists return findings to the foreman, which asks human questions and routes the answers back.
The foreman presents the final pull request and evidence, then marks the work item complete after handoff. Completion does not mean that the factory merged or deployed the change.
Specialized agent responsibilities
Section titled “Specialized agent responsibilities”Triage
Section titled “Triage”Triage researches the codebase, related issues, and source context. It reproduces a problem only when research does not establish the cause. Triage returns issue context, scope, complexity, and ambiguity so the foreman can request clarification, specification, or implementation.
Spec interviews the requester through the foreman and turns the answers into product and technical specifications with validation criteria. It opens a draft pull request on a branch that implementation continues. The seeded foreman requires human approval before dispatching implementation, but teams can change this policy in the foreman’s instructions.
Implement
Section titled “Implement”Implementation continues the spec branch and draft pull request when they exist. It changes code, adds tests, runs repository validation, reviews the diff, and gathers visual evidence for user-facing changes when computer use is available. It can revise the change after review, but it never merges.
Review
Section titled “Review”Review examines the change independently and adversarially against requirements, conventions, tests, security expectations, and evidence. It separates clear defects from ambiguous tradeoffs, then returns an advisory verdict to the foreman: accept, revise, or request a human decision. The verdict does not approve or merge the pull request.
Verification is part of implementation and review
Section titled “Verification is part of implementation and review”The default roster has no separate verify agent. Implementation produces regression, repository, and applicable visual evidence. Review checks that evidence, reruns or extends validation when necessary, and compares the result with the criteria. Custom quality agents can add coverage, but they do not remove these responsibilities.
Configure agent behavior
Section titled “Configure agent behavior”In the control room, the agent editor supports description, model, runner, host, MCP servers, secrets, and instructions. Configure the harness, environment, and credential strategy through factory definitions as code. Factory setup does not set per-role models.
Choose models and harnesses by role
Section titled “Choose models and harnesses by role”Each role can use a different model or harness. Supported harnesses include the Warp Agent harness, Claude Code, and Codex. Choose by responsibility rather than relying on mutable default model IDs.
| Role | Selection guidance |
|---|---|
| Foreman | Favor orchestration, instruction following, and continuity |
| Triage | Favor research, evidence gathering, and connected-tool use |
| Spec | Favor requirement synthesis, technical reasoning, and precise criteria |
| Implement | Match the coding harness and model to the repositories and toolchain |
| Review | Use an independent configuration to reduce correlated mistakes |
See model choice for agents and harnesses for cloud agents for available options. Define reusable procedures with skills, and scope each role’s external access through MCP servers and cloud agent secrets.
Extend the roster with custom agents and automations
Section titled “Extend the roster with custom agents and automations”Custom agents can own narrow responsibilities such as documentation, security analysis, migrations, or release checks. They do not need to become mandatory stages. Automations start a selected agent from an event or schedule; they are intake mechanisms, not a replacement for foreman coordination. See connect your factory for intake options.
Human gates and permissions
Section titled “Human gates and permissions”| Decision or control | Default behavior | Source of enforcement |
|---|---|---|
| Requirements and spec approval | The foreman asks humans to clarify ambiguity and approve every specification | Seeded workflow policy that teams can change |
| Pull request merge | Implementation never merges, and the foreman hands the result to a human | Repository permissions determine who can approve or merge |
| Runtime access | Each role’s environment, managed secrets, and MCP servers follow its effective configuration; built-in harness tools, platform-issued runtime credentials, provider permissions, and network access follow separate controls | Platform configuration and provider permissions |
Warp Factories does not define a factory-specific approver role. Human gates in the seeded workflow are not platform-enforced role-based access control, and instructions do not grant authority beyond configured access.
Next, encode role instructions, model and harness choices, and access boundaries with factory definitions as code.