Factory agents

The foreman is the agent that coordinates a factory’s work and communicates with you. It delegates work to other agents, asks for your decisions when needed, and returns results. Default agents each cover one part of the software development lifecycle: triage scopes the request, spec writes the plan, implement writes the code, and review checks it. Together, they turn a work item into a pull request ready for your team to review.

The default agents

Every factory gets a foreman. You choose which of the four default agents to include. These defaults are a starting point, and you can add custom agents and automations for work they don’t cover.

The default agents’ prompts, descriptions, and models are available in 00-warp-default-agents in the warp-factory-examples repository.

Agent	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	Independently checks the finished change	Findings and a recommendation

These are responsibilities, not a fixed pipeline. A small, well-understood change can skip the Planning stage entirely. If the review agent finds problems, the foreman sends work back for another pass. By default, work that goes through Planning needs a human to approve the spec before the Building stage starts.

For the complete lifecycle, see how Warp Factories work.

Foreman

The foreman agent assigns work and is the only default agent that communicates directly with you. It relays questions and answers between you and other agents, and continues their existing conversations for revisions and follow-ups.

When finished, it returns the pull request and supporting evidence, then marks the work item complete. Complete means handed off to your team, not merged or deployed.

Foreman name

Use the foreman’s handle to @-mention it in Slack and Linear. Factory setup defaults the handle to the factory’s name. For example, a factory named payments gets the handle @payments.

In the web app sidebar, expand your factory and click Settings, then Identity to change the foreman’s handle. You can also edit alias in the definition. The factory name and foreman handle can differ.

Triage

Triage researches the codebase and related issues, reproducing problems when research doesn’t establish the cause. It reports scope, complexity, and open questions so the foreman can choose clarification, planning, or implementation.

Spec

Spec defines requirements through the foreman. It writes product and technical specifications with validation criteria in a draft pull request. By default, the foreman waits for human approval before implementation starts. You can change this policy in the foreman’s instructions.

Implement

Implement builds on the spec’s branch and draft pull request. It adds tests, runs repository checks, and captures visual evidence of user-facing changes when computer use is available. It revises changes after review but never merges.

Review

Review independently checks requirements, code conventions, tests, security, and supporting evidence. It reruns or extends validation when needed, then recommends acceptance, revisions, or a human decision. It doesn’t approve or merge the pull request.

Built-in skills

Every default agent includes GitHub skills; the foreman also includes a Slack skill. Choosing Linear or Jira during setup adds that tracker’s skill and instructions. Add custom procedures with factory skills.

Configuring and extending agents

For settings, prompts, models, and third-party authentication, see Configuring factory agents.

For new roles, skills, and foreman dispatch, see Creating custom agents. Start agents from schedules and events with factory automations.

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 reaches only the repositories, secrets, and MCP servers in its configuration	Platform configuration and the permissions of the connected providers

The first two rows are conventions: they live in the foreman’s instructions and your repository settings, and your team can change them. Access is different. What an agent can reach comes from its configuration and the permissions of the connected providers, never from its instructions — changing what an agent is told to do doesn’t change what it’s able to do.

So enforce with the real controls: branch protection and repository permissions decide who merges, and each agent’s configuration decides what it can reach.

Related pages

• Configuring factory agents
• Creating custom agents
• How Warp Factories work
• Factory skills
• Definitions as code