What Is the Foreman in a Software Factory?

The foreman is the orchestrator agent that takes in a work item and decides what happens to it next. It reads the trigger — a Slack message, a Linear ticket, a failing CI run — and dispatches specialized subagents to triage, spec, implement, review, or verify, choosing the model and context for each. The foreman coordinates the assembly line; it does not write the code.

Borrowed from manufacturing, where a foreman supervises the line rather than working a station, the term names the one role in a cloud software factory that holds the whole work item. You will see the same role called a lead agent, a supervisor, or an orchestrator; Anthropic formalized the underlying shape as the orchestrator-workers pattern, where a central model decomposes a task at runtime and delegates to workers.

What the foreman decides on every work item

A factory without a foreman is a set of agents that each do one job well and have no idea what came before them. The foreman's value is that it makes the same six decisions, in the same order, every time work arrives:

1. Is this for the factory at all? In a shared Slack channel or a busy issue tracker, most messages are not work items. The foreman filters first.
2. What stage is this work already at? A new bug report, a PR that needs review, and a merge notification all enter at different points. The foreman finds the stage rather than restarting the pipeline.
3. Does this need investigation? Unclear cause, no tracking issue, possible duplicate — all reasons to route to triage before anything else.
4. Does this need a human decision? Ambiguous or high-stakes work goes to a spec and stops for approval. Bounded work does not.
5. Which agent, model, and context next? The foreman picks the harness and the slice of context each subagent gets, which is where most of a factory's cost and quality live.
6. What does the requester need to know? The foreman is the one voice back to the human — subagents report to it, not to the channel.

What the foreman owns versus what it delegates

The single most useful design rule: the foreman decides and routes; it never executes. If your orchestrator is reading diffs and editing files, you have collapsed a factory back into one long agent run.

That split is also what makes a factory measurable. Because each stage is a separate run with its own inputs and outputs, you can score triage accuracy separately from implementation quality — impossible when one agent does everything in one context window.

How a work item actually moves through a foreman

A production crash is the clearest example, and it is the flow Warp describes for its own factories:

1. A monitoring integration detects a crash and files a Linear ticket, which triggers the foreman.
2. The foreman dispatches a triage agent, which reproduces the crash and assesses whether it is simple enough to fix automatically.
3. Given a bounded fix, the foreman skips the spec stage and dispatches implementation, which writes the change and can use computer use to verify it before opening a PR.
4. The foreman dispatches review, receives the findings, and decides which need a human.
5. The PR goes back to the requester with the findings attached. A human merges.

Two things happen at every arrow: the foreman hands forward only the context the next stage needs, and a human can step in, steer the run, or pull the work into a local session. That handoff discipline is what multi-agent orchestration means in practice: agents coordinating through defined handoffs rather than a shared session.

Four ways foremen go wrong

This is where most homegrown factories struggle, and the failure modes are consistent enough to design against up front.

Context amnesia is the expensive one. The agent that just implemented a change is the cheapest place to send review findings or a CI failure, because it still has the reasoning that produced the diff. A foreman that dispatches a fresh agent instead pays for the same investigation twice.

How Warp fits

Warp Factories ships the foreman as a first-class part of the factory rather than something you assemble yourself. Work enters from Slack, Teams, Linear, Jira, GitHub, GitLab, or a local coding agent through the Factory MCP, and the trigger starts the foreman, which splits off subagents for triage, spec, implementation, and review — each with its own skills, MCP servers, and memory, and each able to run on the model or harness that suits it.

Because factories in Warp are defined as version-controlled code, the foreman's routing rules are reviewable and revertible like any other config, and observer agents can open PRs that improve them based on scored runs. Warp reports that its own team currently automates 20–30% of its PRs through factories — a first-party signal that the goal is not full autonomy but a growing share of repeatable work moving through a governed path. Warp provides the control plane and the measurement; you own the workflow, the models, and the data.

Start with one workflow

You do not need the full assembly line to get value from a foreman. Pick one workflow with a clear trigger, a measurable outcome, and a human fallback — bug triage, dependency upgrades, or computer-use verification are all good first candidates — and give the foreman exactly two routes to choose between. Add stages once the routing decisions it already makes are reliably right.

See this in action with Warp Factories, or request access to the closed beta. Enterprises can learn more at Warp for Enterprise.

Sources

• A guide to cloud software factories for engineering leaders
• Introducing Warp Factories
• Building effective agents
• What Is Multi-Agent Orchestration, and How Do Agents Coordinate Work?
• What Is Agent Orchestration, and How Is It Different from Agent Management?
• How to build a cloud software factory - the automatic triage skill