Factory agents

Every factory has a small team of agents, and each agent has a specific job. Specialist agents investigate, plan, build, and check the work, while the foreman coordinates them and holds one continuous conversation with the person who requested the work. Together, they take a work item from the moment it reaches your factory to a finished pull request that’s ready for a human to review.

Default agent roles

When you set up a factory, Warp offers five default roles. Every factory gets a foreman; you choose one to four specialist roles to go with it, for a starting team of two to five agents. Each role owns one part of the workflow, so it’s always clear which agent is responsible for what.

Role	What it does	What it produces
Foreman	Coordinates the work and talks to the requester	Decisions, questions, status updates, and the final handoff
Triage	Investigates the request and establishes scope	Evidence, issue context, complexity, and open questions
Spec	Turns requirements into a concrete plan with validation criteria	Product and technical specs in a draft pull request
Implement	Makes and validates the code change	Code, tests, validation results, and visual evidence
Review	Checks the finished change with fresh eyes	Findings and a recommendation

These roles describe responsibilities, not a fixed pipeline. A small, well-understood change can skip the spec stage entirely, and review can send work back to implementation for another pass. By default, work that goes through the spec stage needs a human to approve the spec before implementation starts.

For the complete lifecycle, see how Warp Factories work.

Foreman

The foreman agent runs the factory floor. It decides which role a work item needs next, hands the work to that agent, and keeps the requester informed. It’s the only default agent that talks to the requester directly: when a specialist needs a human answer, the foreman asks the question and routes the answer back. For revisions and follow-ups, the foreman continues the specialist’s existing conversation instead of starting a new one, so no context is lost.

When the work is done, the foreman presents the final pull request and its supporting evidence, then marks the work item complete. Complete means the work was handed to a human, not that the change was merged or deployed. Merging stays with your team.

Specialist roles

Triage

Triage figures out what the request actually involves. It researches the codebase, related issues, and other available context, and only tries to reproduce a problem when research alone can’t establish the cause. It reports back with the relevant context, the scope and complexity of the change, and anything that’s still unclear. The foreman uses that report to decide what happens next: ask the requester for clarification, request a spec, or go straight to implementation.

Spec

Spec turns an ambiguous request into a concrete plan. It interviews the requester (through the foreman) to pin down requirements, then writes product and technical specifications with criteria for validating the change. It opens a draft pull request on a branch that implementation later continues. By default, the foreman waits for a human to approve the spec before starting implementation; you can change that policy in the foreman’s instructions.

Implement

Implement makes the change. When a spec exists, it continues the spec’s branch and draft pull request rather than starting over. It writes the code, adds tests, runs the repository’s validation, reviews its own diff, and, when computer use is available, captures visual evidence of user-facing changes. If review finds problems, implement revises the change. It never merges.

Review

Review checks the finished change with fresh eyes, deliberately hunting for problems: unmet requirements, broken conventions, missing or failing tests, security issues, and evidence that doesn’t hold up. It separates clear defects from judgment calls, then gives the foreman one of three recommendations: accept the change, send it back for revision, or ask a human to decide. The recommendation is advice for the foreman; it doesn’t approve or merge the pull request.

Where verification happens

There’s no separate verification agent, and the default team doesn’t need one. Implement proves its own change works: it runs the tests and repository checks, and captures visual evidence for user-facing changes. Review then checks that proof, reruns or extends validation when necessary, and confirms the results meet the criteria. You can add custom agents for extra quality coverage, but implement and review keep these responsibilities either way.

Built-in skills and memory

Every default agent comes with GitHub skills, and the foreman also comes with a Slack skill. The issue tracker you choose during setup adds to that baseline: choosing Linear or Jira gives the agents that tracker’s skill and instructions for working with it. If you don’t choose a tracker, the agents get only the baseline.

Each default agent also has its own Auto-memory store. Over time, Warp consolidates the agent’s conversations into memory, and that accumulated memory shapes how the agent behaves. Keep this in mind when comparing two agents: identical settings don’t guarantee identical behavior, because each agent remembers different things.

Configure agent behavior

You configure each agent in two places:

• In the control room - Use the agent editor to set an agent’s description, model, runner, host, MCP servers, secrets, and instructions.
• In your factory definitions - Set the harness, environment, and credential strategy in code. See factory definitions as code.

Factory setup doesn’t choose models for you. To change the model a role uses, edit that agent in the control room.

Choose models and harnesses by role

Each role can run on its own model and harness. Supported harnesses include the Warp Agent harness, Claude Code, and Codex, and any role can use any of them. A foreman running on Claude Code or Codex can still dispatch the factory’s other agents, and the runs it starts are still tracked as its children.

Default model IDs change over time, so choose based on what each role has to do well:

Role	What to optimize for
Foreman	Orchestration, instruction following, and long-running conversations
Triage	Research, evidence gathering, and working with connected tools
Spec	Synthesizing requirements, technical reasoning, and precise writing
Implement	Coding strength, with a harness that fits your repositories and toolchain
Review	A different model or harness from implement, so the two don’t share blind spots

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.

Add custom agents and automations

The five default roles aren’t a ceiling. Add custom agents for narrow jobs such as documentation, security analysis, migrations, or release checks. They don’t have to become required steps for every work item.

Automations start a chosen agent on a schedule or when an event fires. They’re one more way for work to enter your factory; the foreman still coordinates whatever they start. For all the ways to route work into a factory, see connect your factory.

Human decision points and permissions

Decision	Default behavior	What enforces it
Spec approval	The foreman asks a human to clarify ambiguity and approve every spec	Workflow policy in the foreman’s instructions, which your team can change
Merging	Agents never merge; the foreman hands the finished pull request to a human	Your repository’s permissions decide who can approve and merge
Runtime access	Each agent uses only the environment, secrets, and MCP servers in its configuration	Platform configuration and the permissions of the connected providers

A few capabilities sit outside an agent’s configuration: built-in harness tools, the runtime credentials the platform issues, provider permissions, and network access are governed by their own controls.

Treat the approval steps as workflow conventions, not access control. Warp Factories has no special approver role, and nothing written in an agent’s instructions grants it access beyond what it’s configured with. Real enforcement lives in your repository permissions and platform configuration.

Next, capture your role instructions, model and harness choices, and access boundaries in factory definitions as code.