Skip to content

Factories > Operate

The Factory control room

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

Track work items, inspect runs, read factory metrics, and manage agents, automations, and settings from the control room.

The control room is the web app for operating a single factory. Use it to track the work your agents are doing, inspect the runs and pull requests they produce, and manage the agents, automations, and settings the factory owns.

Select a factory in the sidebar to open its pages. Runs, MCPs and apps, and Secrets sit above the factory list and cover your whole team, not a single factory.

PageWhat it showsWhat you do there
DashboardFactory metrics: autonomy, time saved, PR latency, cost, and run volumeCompare periods and find work worth investigating
ActivityWork items grouped by stageSearch, filter, open, and stop work items
AgentsThe factory’s agent rosterCreate and edit agents
AutomationsTriggers that start runsCreate, edit, and delete automations
RunsThe factory’s individual agent runsStart, stop, and score runs
ScorersScorer definitions and resultsDefine rubrics and review classifications
Self-improvementPull requests filed to fix scorer-detected failuresReview fix PRs and open the runs behind them
BenchmarksBenchmark suites and their runsCompare harness, model, and runner configurations
CodeThe factory’s definition filesBrowse and edit a Warp-managed definition
SettingsConfiguration the factory ownsChange identity, repos, runners, and integrations

Activity shows the factory’s work items grouped by stage: Triage, Planning, Building, and Reviewing.

By default, Activity shows only work items you created, and only the four active stages. Change the Created by filter to see a teammate’s work, and add a Stage filter for Complete or Cancelled to see finished work.

Click a work item to open its detail pane, which includes the prompt that started it, the ticket or thread it came from, the pull requests it produced, and its cost. View agent opens the agent’s session, Event history lists the runs behind the work item, and Stop task cancels the current run.

A run is a single agent execution. The team-level Runs page lists every run you have access to; a factory’s Runs page lists only runs from that factory’s agents.

Click New on a factory’s Runs page to send a prompt to the factory’s foreman agent. Open a run to see its timeline and cost, plus a Sub-agents tab for an orchestrator run’s child runs. From there you can view the agent’s full session, stop or score the run, or turn it into a benchmark task.

Dashboard summarizes the factory over a date range you choose:

  • Autonomy - The share of merged PRs that needed no human input beyond an approving review.
  • Time saved - Approximate engineer-hours saved, estimated from the line changes in merged PRs.
  • PR latency - The median time from run kickoff through PR, review, and merge.
  • Cost per PR - The median cost of PRs opened in the range. Treat it as a lower-bound estimate: it can miss some run usage and does not match billing. See Measure and improve a factory for its limitations.

The page also charts opened versus merged PRs and a breakdown of runs, and the Cost per PR card expands to list the most expensive PRs in the range. When scorers are set up, scorer cards summarize recent classification results.

Agents is the factory’s roster. Create agents and edit their instructions, model or harness, runner, host, secrets, and MCP servers. Automations defines the triggers that start runs: a schedule (including custom cron expressions) or a GitHub, Linear, Slack, or Jira event.

Environment is set in the factory definition, not the agent editor, and automations never override execution settings. When the factory’s definition lives in an external repository, Agents, Automations, and Scorers are read-only; make changes there through pull requests.

Code is the control room’s view of the factory’s definition files, which Factory definitions as code describes in full. What the tab offers depends on where the definition lives:

  • Warp-managed - Browse and edit the definition files. Saving validates the definition and commits all changes together.
  • Managed in GitHub - Links to the repository; edit the definition through pull requests there.
  • Live-managed - The factory is edited directly in the control room, so there are no definition files to browse.

When an agent proposes a change to a Warp-managed definition, its work item on Activity links to a review of the branch inside the control room. From there, comment on the diff, use Request changes to send feedback back to the agent, or Approve & merge.

A scorer is an LLM judge that classifies completed runs against a rubric you define, scoped to the agents you choose and sampled at a rate you set. Each scorer has a Self-improvement toggle: when it’s on, the factory periodically triages the runs that scorer marks as failing and files fixes for recurring issues. The Self-improvement page tracks the pull requests those fixes open, linking each one to the run that produced it.

Benchmarks compares harness, model, and runner configurations against a fixed set of tasks with success criteria. Benchmark results are only as reliable as the scorers behind them, so read them alongside Measure and improve a factory.

Settings holds the configuration the factory owns: the factory’s name and connected repos, whether pull requests are authored by the agent or the run creator, the Analysis model self-improvement uses to analyze failed runs, runners, integrations, and deletion. Deleting a factory cannot be undone.

For a file-managed factory, runners/*.yaml in the repository is the source of truth. Anything managed in an external repository is read-only in Settings.