> For the complete documentation index, see [llms.txt](/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# The Factory 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

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.

-   **Search** - Type in **Search tasks…** to match work item titles.
-   **Filter** - Add a **Stage**, **Created by**, or **Created on** filter. Active filters appear as chips with a result count and a **Clear** action.
-   **Sort** - Order work items by **Created** or **Updated**, in either direction.

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

Filters and the open work item are stored in the URL, so you can reload or share a filtered view. Search text and sort order reset on reload.

### Open and stop a work item

Click a work item to open its detail pane. The pane shows the work item’s stage, current agent activity, the prompt that started it, external references, pull requests, environment, cost, and run time. Click the short ID in the pane header to copy the full work item ID.

-   **Event history** - A timeline of the runs behind the work item, newest first.
-   **Stop task** - Cancels the work item’s current run. Available only while a run is in progress.

Caution

**Stop task** takes effect immediately, with no confirmation prompt.

## Inspect runs

A run is a single agent execution. Runs appear in two places:

-   The team-level **Runs** page lists every run you have access to, across all factories.
-   A factory’s **Runs** page lists only runs executed by that factory’s agents.

Both pages support search, sorting, and filters for status, source, agent, creator, creation date, and execution location.

On a factory’s **Runs** page, click **New** to send a prompt, with optional attachments, to the factory’s foreman agent.

Click a run to open its detail pane, which shows the run timeline, triggering prompt, cost, environment, and harness. An orchestrator run adds a **Sub-agents** tab listing its child runs. From the pane, click **View session** to open the agent’s session in a new tab. Where the run supports it, you can also **Stop run**, **Score run**, or create a benchmark task from the run.

Note

The control room is for watching work, not steering it. Pages refresh every few seconds, and there is no in-page way to chat with an agent or approve its actions. Direct the work itself through your integrations and your repository’s review process.

## Read dashboard metrics

**Dashboard** summarizes the factory over a date range you choose with the presets or the date picker. Three cards lead the page:

-   **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.

Below the cards:

-   **Cost per PR** - The median cost of PRs opened in the range, with **By complexity** and **By size** views and an expandable list of the most expensive PRs. 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.
-   **Pull requests** - PRs opened versus merged over the range.
-   **Run breakdown** - Total runs, with drill-downs by agent type, status, source, root runs versus subruns, model, and harness.
-   **Insights** - Self-improvement PRs opened by your foreman agent, each linked to your code host.

When scorers are set up, scorer cards below the charts summarize recent classification results.

## Manage agents and automations

**Agents** lists the factory’s roster, with search and a type filter (Foreman, Triage, Spec, Code, Review, Monitor, or Custom). Click **New** to create an agent, or click a card to edit its name, description, instructions, model, runner, host, secrets, and MCP servers, along with the automations that target it.

**Automations** lists the triggers that start runs, showing each automation’s trigger, target agent, and creation date. An automation runs on a schedule (hourly, daily, weekly, or a custom cron expression) or on a GitHub, Linear, Slack, or Jira event, with per-provider filters.

Two things live outside these editors:

-   **Harness and environment** - The agent editor sets the model, runner, and host; set the harness and environment in the factory definition. Automations never override execution settings.
-   **Externally managed factories** - When the factory’s definition lives in an external repository, both pages are read-only and link to the repository. Make changes there through pull requests.

## Edit definitions in the Code tab

What the **Code** tab offers depends on where the factory’s definition lives:

-   **Warp-managed** - A file tree and editor. Browse the definition, edit files, and save your changes as a single commit. Warp validates the whole definition before saving and lists any problems with their file and line. If you try to navigate away with unsaved edits, the page prompts you first.
-   **Managed in GitHub** - Read-only, with an **Open repository** button. Edit the definition through pull requests in the repository.
-   **Managed through the API** - No definition files exist, so there is nothing to browse.

## Score and benchmark

A scorer is an LLM judge that classifies completed runs against a rubric you write. On **Scorers**, define each scorer’s rubric, labels, and pass threshold, choose which agents it covers, and set its sampling rate and judge model. You can pause and resume a scorer at any time.

Each scorer also 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 configurations on a fixed set of tasks. A suite defines an agent and its tasks, each with success criteria. When you launch a suite, choose the harness, model, and runner combinations to compare, the scorers to apply, and the number of repetitions. Results include a scoreboard, pass rates, and per-task comparisons across configurations.

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:

-   **General info** - Rename the factory, change its avatar, connect repos, and choose whether pull requests are authored by the agent or by the run creator. The factory alias is read-only.
-   **Self-improvement** - Choose the **Analysis model** that analyzes failed runs and groups recurring issues before fixes enter the factory.
-   **Runners** - Create and edit the factory’s runners. For a file-managed factory, `runners/*.yaml` in the repository is the source of truth, and this section links there instead.
-   **Factory repo** - See where the factory’s definition is hosted.
-   **Factory integrations** - Review the connected Slack app and set up, edit, or remove cloud provider configurations.
-   **Danger zone** - Delete the factory. Deletion cannot be undone.

If you lack edit access, or a setting is managed in an external repository, the control is disabled and the page points you to where the change belongs.

## 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.