Factories > Operate
The Factory control room
# The Factory 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. ## Pages at a glance 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. | Page | What it shows | What you do there | | --- | --- | --- | | **Dashboard** | Factory metrics: autonomy, time saved, PR latency, cost, and run volume | Compare periods and find work worth investigating | | **Activity** | Work items grouped by stage | Search, filter, open, and stop work items | | **Agents** | The factory's agent roster | Create and edit agents | | **Automations** | Triggers that start runs | Create, edit, and delete automations | | **Runs** | The factory's individual agent runs | Start, stop, and score runs | | **Scorers** | Scorer definitions and results | Define rubrics and review classifications | | **Benchmarks** | Benchmark suites and their runs | Compare harness, model, and runner configurations | | **Code** | The factory's definition files | Browse and edit a Warp-managed definition | | **Settings** | Configuration the factory owns | Change identity, repos, runners, and integrations | ## Track work items on Activity **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 pull requests it produced, and its cost. **Event history** lists the runs behind the work item, and **Stop task** cancels the current one. :::caution **Stop task** takes effect immediately, with no confirmation prompt. ::: ## Inspect runs 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. :::note The control room is for observing runs, not steering them. There is no in-page way to chat with an agent or approve its actions. Direct the work through your integrations and your repository's review process. ::: ## Read dashboard metrics **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](/factories/measure-and-improve/) for its limitations. The page also charts opened versus merged PRs and a breakdown of runs, and lists the Self-improvement PRs your foreman agent has opened. When scorers are set up, scorer cards summarize recent classification results. ## Manage agents and automations **Agents** is the factory's roster. Create agents and edit their instructions, model, 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. Harness and environment are 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, both pages are read-only; make changes there through pull requests. ## Edit definitions in the Code tab What **Code** offers depends on where the factory's definition lives: * **Warp-managed** - Browse and edit the definition files. Saving validates the definition and commits all changes together. * **Managed in GitHub** - Read-only. Edit the definition through pull requests in the repository. * **Managed through the API** - There are no definition files to browse. ## Score and benchmark 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. **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](/factories/measure-and-improve/). ## Change factory settings **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. ## Next steps * [How Warp Factories work](/factories/how-factories-work/) - The lifecycle behind Activity's stages and where humans stay in the loop. * [Factory definitions as code](/factories/factory-as-code/) - Define agents, automations, runners, and source ownership in code. * [Measure and improve a factory](/factories/measure-and-improve/) - Configure the scorers and benchmarks behind the Dashboard.Tell me about this feature: https://docs.warp.dev/factories/control-room/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.
Pages at a glance
Section titled “Pages at a glance”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.
| Page | What it shows | What you do there |
|---|---|---|
| Dashboard | Factory metrics: autonomy, time saved, PR latency, cost, and run volume | Compare periods and find work worth investigating |
| Activity | Work items grouped by stage | Search, filter, open, and stop work items |
| Agents | The factory’s agent roster | Create and edit agents |
| Automations | Triggers that start runs | Create, edit, and delete automations |
| Runs | The factory’s individual agent runs | Start, stop, and score runs |
| Scorers | Scorer definitions and results | Define rubrics and review classifications |
| Benchmarks | Benchmark suites and their runs | Compare harness, model, and runner configurations |
| Code | The factory’s definition files | Browse and edit a Warp-managed definition |
| Settings | Configuration the factory owns | Change identity, repos, runners, and integrations |
Track work items on Activity
Section titled “Track work items on Activity”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 pull requests it produced, and its cost. Event history lists the runs behind the work item, and Stop task cancels the current one.
Inspect runs
Section titled “Inspect runs”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.
Read dashboard metrics
Section titled “Read dashboard metrics”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 lists the Self-improvement PRs your foreman agent has opened. When scorers are set up, scorer cards summarize recent classification results.
Manage agents and automations
Section titled “Manage agents and automations”Agents is the factory’s roster. Create agents and edit their instructions, model, 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.
Harness and environment are 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, both pages are read-only; make changes there through pull requests.
Edit definitions in the Code tab
Section titled “Edit definitions in the Code tab”What Code offers depends on where the factory’s definition lives:
- Warp-managed - Browse and edit the definition files. Saving validates the definition and commits all changes together.
- Managed in GitHub - Read-only. Edit the definition through pull requests in the repository.
- Managed through the API - There are no definition files to browse.
Score and benchmark
Section titled “Score and benchmark”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.
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.
Change factory settings
Section titled “Change factory settings”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.
Next steps
Section titled “Next steps”- How Warp Factories work - The lifecycle behind Activity’s stages and where humans stay in the loop.
- Factory definitions as code - Define agents, automations, runners, and source ownership in code.
- Measure and improve a factory - Configure the scorers and benchmarks behind the Dashboard.