Factories

A factory is a team of agents that works on one goal together. Use one when a job has several parts, such as planning, building and reviewing, and each part needs its own agent. This page shows you how to build, run and review a factory.

How a factory works

A factory is a pipeline of stages. Each stage is its own agent, in its own sandbox, with its own harness, model and skills. A stage starts when the stages it waits for are done, and it receives their summaries.

Agents never talk to each other directly. They send messages, hand off results and ask for approvals through Threadrun, so every step is logged in the run.

Start from a template

Open New factory. Three shelves offer ready-made teams:

Built-in: teams such as Plan → Build → Review, Spec-driven development and Dynamic team.
My templates: teams you saved.
Online gallery: teams published as agent plugins. Use loads one as stages, and its skills go into your library.

Pick a team, then change its stages to suit your work.

Build your own

Name the factory, for example SDD pipeline. A name is enough to save a template. Add a goal to run it.
Pick a project, or keep No project (scratch workspace).
Pick Run on: this computer or one of your servers.
Edit each stage (see below).
Set the guardrails.
Press Save as template, Run factory, or both.

Each stage has these settings:

Name, harness and instructions. The harness is Claude Code, Codex or OpenCode.
Model, effort, context window and mode. These come from the harness's options. They appear once the harness is connected in Settings → Accounts.
Skills & MCP. The skills and tools this agent gets. See Skills and MCP.
Starts after. The stages that must finish first.
Approval gate. The stage waits until someone approves it.
Can spawn agents. The stage can start helpers. See Dynamic teams.

Guardrails

Threadrun enforces these limits for the whole run. Your governance rules still apply to every agent.

Guardrail	Default	What it does
Max agents (incl. spawned)	8	Caps the agents in one run. The hard limit is 32.
Max working at once	4	Other agents wait their turn. 0 means no limit.
Run budget	$5	Covers all agents. When it is reached, every agent stops.
Harnesses spawned agents may use	The lead's	Empty means the lead's harness only.
Allowed models	Any	Limits the models that spawned agents may use.
A human approves every spawned agent	Off	Each helper waits in Approvals before it starts.

The last three appear once a stage can spawn agents.

Small servers run fewer agents at once. Threadrun allows about one agent for each 768 MB of server memory, so a 512 MB server runs one agent at a time. See Your server.

Dynamic teams

A stage with Can spawn agents acts as a lead. It splits the goal into tasks and starts a helper for each one. For each helper, the lead sets a name, instructions, and optionally a harness, model, effort and the agents it waits for.

A helper runs in its own sandbox. If it uses the lead's harness, it starts with the lead's settings.
A helper cannot start helpers of its own.
Its result returns to the lead as a message. The lead reviews it, sends fixes, or starts follow-ups.

The Dynamic team template is a lead with this setting on.

Run and watch a factory

Press Run factory. Each stage starts once the stages it waits for are done. The run opens in its own view.

Pipeline shows each stage's status. Click a stage to see everything its agent did.
Agent communication lists every message, approval and decision, with who made it. Messages are formatted, so lists, code and links read as the agent wrote them.
Approvals appear in the run when a stage waits for a decision. Approve or deny them there.

Change a stage's model mid-run

Open the stage in the pipeline and change its model in the composer. The change applies to that agent, and to any agent it starts later. To have a finished stage work again on the new model, send it a message such as "retry".

How work is handed off

With a GitHub project, every stage works on one branch, factory/<run>. Each stage commits and pushes its changes after every turn, and later stages start from that branch. You can open a pull request from it. See Review and ship. Without a project, there is no branch.

Review the run

When a run ends, its Run review appears. It uses no tokens: it reads the run's history with fixed rules, so it is instant and free.

Cost, tokens, the share served from cache, tool calls and failures, and time.
A cost bar for each stage, when the run has more than one.
Proposals, each with an estimated saving. A may affect quality flag marks changes that could lower the result.

Proposals can lower effort or switch to a cheaper model for light work, drop an unneeded 1M context window, stop repeated re-reads, warn about a failing step, or disconnect MCP servers no agent used.

Tick the ones you want, then press Apply and run again. The new run's review compares cost and outcome with the last one, for example "cost $0.42 → $0.25 (−40%)". If the result got worse, the review offers a Revert for each change. Every approval is logged with who made it.

Loop runs work the same way, but the changes go to the loop's next run. See Loops.