warpdotdev · guyscherzer8 · Aug 18, 2026 · Aug 18, 2026 · Aug 18, 2026 · Aug 18, 2026
diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx
@@ -51,6 +51,7 @@ When you create a factory through the setup wizard, Warp adds default automation
 
 * **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge, completing a linked tracker issue when it can. See the [GitHub integration guide](/factories/integrations/github/).
 * **Jira** - Starts work when someone assigns or mentions Warp on a work item in one of the Jira projects you selected. See the [Jira integration guide](/factories/integrations/jira/).
+* **Linear** - Starts work when a new agent session arrives from one of the Linear teams you selected. See the [Linear integration guide](/factories/integrations/linear/).
 * **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](/factories/integrations/slack/).
 
 These defaults are starting points. Review each automation's filters, agent, and run settings, and adjust them to match your workflow.

diff --git a/src/content/docs/factories/control-room.mdx b/src/content/docs/factories/control-room.mdx
@@ -15,13 +15,13 @@ Select a factory in the sidebar to open its pages. **Runs**, **MCPs and apps**,
 
 | 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 |
+| **Dashboard** | Factory metrics: autonomy, PR cycle time, 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 |
-| **Self-improvement** | Pull requests filed to fix scorer-detected failures | Review fix PRs and open the runs behind them |
+| **Self-improvement** | Pull requests filed to fix Scorer-detected failures | Review fix PRs and open the runs behind them |
 | **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 the integrations the factory can access |
@@ -52,12 +52,11 @@ Run pages don't include a chat input, but you can still steer a run: **View sess
 
 **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.
+* **Autonomy** - The share of the factory's merged PRs that needed no human input beyond an approving review and the merge itself.
+* **PR cycle time** - The median time the factory's merged PRs took from run kickoff through PR, first review, and merge, with a median for each stage.
 * **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 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.
+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.
 
 ## Manage agents and automations
 
@@ -71,24 +70,24 @@ Environment is set in the factory definition, not the agent editor, and automati
 
 * **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.
+* **Live-managed** - The factory is managed through the API, 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**.
 
 ## 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. The **Self-improvement** page tracks the pull requests those fixes open, linking each one to the run that produced it.
+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](/factories/measure-and-improve/).
+**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, the integrations accessible to this factory, and deletion. Deleting a factory cannot be undone.
+**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 definition's [`credentialStrategy`](/factories/factory-as-code/#credentialstrategy)), the **Analysis model** [Self-improvement](/factories/measure-and-improve/#configure-and-review-self-improvement) uses to analyze failed runs, runners, the integrations accessible to this factory, 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.
+* [Measure and improve a factory](/factories/measure-and-improve/) - Configure the Scorers and benchmarks behind the Dashboard.
diff --git a/src/content/docs/factories/factory-agents.mdx b/src/content/docs/factories/factory-agents.mdx
@@ -62,7 +62,7 @@ Each default agent also has its own [Auto-memory store](/agents/agent-memory/).
 
 ## Configure agent behavior
 
-Use the agent editor in the control room to change an agent's description, model, runner, host, MCP servers, secrets, and instructions.
+Use the agent editor in the [control room](/factories/control-room/) to change an agent's description, model, runner, host, MCP servers, secrets, and instructions.
 
 You can also manage the whole factory as version-controlled code, with [factory definition files](/factories/factory-as-code/) in a Git repository, where changes get the same review, history, and rollback as any other code. A few agent settings can only be set in the files: harness, environment, and credential strategy. Where the repository lives determines how the two editing paths work together:
 

diff --git a/src/content/docs/factories/factory-as-code.mdx b/src/content/docs/factories/factory-as-code.mdx
@@ -98,11 +98,11 @@ repositories:
 
 ### `secrets`
 
-Optional. Names of [managed secrets](../platform/secrets) granted to every agent in the factory, in addition to anything individual agents declare.
+Optional. Names of [managed secrets](/platform/secrets/) granted to every agent in the factory, in addition to anything individual agents declare.
 
 ### `mcpServers`
 
-Optional. [MCP servers](../platform/mcp) granted to every agent, keyed by the name the agent sees. Each entry references a Warp-managed MCP server by `warpId`.
+Optional. [MCP servers](/platform/mcp/) granted to every agent, keyed by the name the agent sees. Each entry references a Warp-managed MCP server by `warpId`.
 
 ```yaml
 mcpServers:
@@ -143,7 +143,7 @@ agentDefaults:
 
 ### `agentDefaults.model`
 
-The model runs execute with, as an Oz model ID. `model` is shorthand for running on the Warp Agent harness:
+The model runs execute with, as a `model_id` from [model choice for agents](/agents/inference/model-choice/). `model` is shorthand for running on the Warp Agent harness:
 
 ```yaml
 model: auto
@@ -161,7 +161,7 @@ harness:
 
 ### `agentDefaults.harness`
 
-The harness and model runs execute with. Use the `harness` form to run a third-party harness or to set advanced options. `type` accepts `oz`, `claude` (alias `claude-code`), `codex`, or `gemini`; see [supported harnesses](../platform/harnesses/).
+The harness and model runs execute with. Use the `harness` form to run a third-party harness or to set advanced options. `type` accepts `oz`, `claude` (alias `claude-code`), `codex`, or `gemini`; see [supported harnesses](/platform/harnesses/).
 
 ```yaml
 harness:
@@ -173,15 +173,15 @@ harness:
     secretName: CODEX_API_KEY
 ```
 
-For a third-party harness, `auth` sets where credentials come from: `source: managedSecret` reads the [managed secret](../platform/secrets) named by `secretName`, and `source: workerEnvironment` reads them from your self-hosted worker's environment (and requires a self-hosted `workerHost`). The `oz` harness supplies its own credentials and takes no `auth` or `reasoningLevel`.
+For a third-party harness, `auth` sets where credentials come from: `source: managedSecret` reads the [managed secret](/platform/secrets/) named by `secretName`, and `source: workerEnvironment` reads them from your self-hosted worker's environment (and requires a self-hosted `workerHost`). The `oz` harness supplies its own credentials and takes no `auth` or `reasoningLevel`.
 
 ### `agentDefaults.runner`
 
 The name of a runner defined under [`runners/`](#runnersnameyaml) that provides the compute for runs.
 
 ### `agentDefaults.environmentId`
 
-The ID of an existing [environment](../platform/environments) runs execute in.
+The ID of an existing [environment](/platform/environments/) runs execute in.
 
 ### `agentDefaults.secrets`
 
@@ -193,7 +193,7 @@ MCP servers for agents that don't declare their own, in the same form as [`mcpSe
 
 ### `agentDefaults.workerHost`
 
-Where runs execute: `warp` for Warp-hosted compute, or the ID of a connected [self-hosted worker](../platform/self-hosting/).
+Where runs execute: `warp` for Warp-hosted compute, or the ID of a connected [self-hosted worker](/platform/self-hosting/).
 
 ## `agents/<name>/agent.md`
 
@@ -260,7 +260,7 @@ The providers and their events:
 * `schedule` - `cron_fired`
 * `factory` - `work_item_stage_changed`
 
-Slack, Linear, and Jira triggers require the matching [integration](../platform/integrations/) to be connected. GitHub triggers work through the factory's `repositories`.
+Slack, Linear, and Jira triggers require the matching [integration](/platform/integrations/) to be connected. GitHub triggers work through the factory's `repositories`.
 
 ### `triggers[].filter`
 
@@ -285,7 +285,7 @@ An automation may also declare `model` or `harness`, `runner`, `environmentId`,
 
 ## `runners/<name>.yaml`
 
-Optional. Each file defines a runner: the compute a run executes on. The runner's name comes from the file name, and agents and automations select it by that name. See [cloud agent runners](../platform/runners) for how runners behave.
+Optional. Each file defines a runner: the compute a run executes on. The runner's name comes from the file name, and agents and automations select it by that name. See [cloud agent runners](/platform/runners/) for how runners behave.
 
 ```yaml title="runners/linux-build.yaml"
 description: Linux runner for payments builds and tests
@@ -315,7 +315,7 @@ The operating system and architecture. `os` is `linux` (the default) or `macos`,
 
 ## Skills
 
-A skill is a directory containing a `SKILL.md`, not a YAML key. Skills under `skills/` are available to every agent in the factory; skills under `agents/<name>/skills/` are available only to that agent. See [Skills for agents](../agents/capabilities/skills).
+A skill is a directory containing a `SKILL.md`, not a YAML key. Skills under `skills/` are available to every agent in the factory; skills under `agents/<name>/skills/` are available only to that agent. See [Skills for agents](/agents/capabilities/skills/).
 
 ## Example factory definition
 

diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx
@@ -70,8 +70,8 @@ These checkpoints come from the factory's agent instructions and your repository
 
 Each completed work item leaves evidence behind, including run and pull request activity, costs, [Scorer](/factories/measure-and-improve/) evaluations, and benchmarks. Teams use this evidence to spot repeated failures and compare model or harness configurations.
 
-The factory can also act on that evidence directly. Its [self-improvement](/factories/measure-and-improve/#configure-and-review-self-improvement) capability groups the failures Scorers flag and files follow-up runs that propose changes to the application code or the factory's own definition. Nothing is adopted without your review.
+The factory can also act on that evidence directly. Its [Self-improvement](/factories/measure-and-improve/#configure-and-review-self-improvement) capability groups the failures Scorers flag and files follow-up runs that propose changes to the application code or the factory's own definition. Nothing is adopted without your review.
 
-Anyone on the team, or an agent, can also propose changes to the factory's instructions, skills, models, environments, or other [definitions](/factories/factory-as-code/). Definitions stored in GitHub can go through pull request review and configuration checks before a change reaches the production branch; Warp-managed definitions sync changes directly. Match your review policy to the definition source and the risk of the change.
+Anyone on the team, or an agent, can also propose changes to the factory's instructions, skills, models, environments, or other [definitions](/factories/factory-as-code/). Definitions stored in GitHub can go through pull request review and [configuration checks](/factories/factory-as-code/#pull-request-checks-for-github-backed-factories) before a change reaches the production branch; Warp-managed definitions sync changes directly. Match your review policy to the definition source and the risk of the change.
 
 Benchmarks organize the evidence; they don't replace your judgment about whether a change is correct. See [measure and improve](/factories/measure-and-improve/) for the evaluation workflow, or [build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent/) to apply the same outer-loop pattern to a standalone agent.
diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx
@@ -11,7 +11,7 @@ import { VARS } from '@data/vars';
 Warp Factories lets engineering teams define and operate **software factories**, cloud workflows where specialized agents move engineering work from intake to a reviewed pull request. Your team sets the policy and makes the final decisions; the factory does the repetitive work and records the evidence you need to improve it.
 
 :::note
-This feature is currently in **Early Access**. Warp Factories is available to a limited set of teams while Warp validates the product.
+Warp Factories is in **Early Access** and available to a limited set of teams.
 :::
 
 ## What is a software factory?

diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx
@@ -95,7 +95,7 @@ A factory handles four kinds of credentials, each with its own boundary:
 | **Inference credentials** | Model provider requests | Used only at the inference boundary; never injected into the sandbox |
 | **Execution secrets** | APIs, package registries, and tools an agent uses | Delivered from an explicit per-agent allowlist; factory agents that don't act as a specific user receive no managed secrets by default |
 | **Harness authentication** | Third-party harnesses such as Claude Code or Codex | Configured separately from the agent's secret allowlist |
-| **Repository identity** | Checking out code and pushing changes | Runs act with the creating user's authorization (changes are attributed to them) or as the agent itself for unattended work |
+| **Repository identity** | Checking out code and pushing changes | Runs act with the creating user's authorization (changes are attributed to them) or as the agent itself for unattended work; set by the definition's [`credentialStrategy`](/factories/factory-as-code/#credentialstrategy) |
 
 Scope each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction is a backstop, not a substitute for narrow external permissions and rotation. See [cloud agent secrets](/platform/secrets/), [harness authentication](/platform/harnesses/authentication/), [secret redaction](/support-and-community/privacy-and-security/secret-redaction/), and [team identity](/platform/team-access-billing-and-identity/) for the underlying controls.
 

diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx
@@ -63,7 +63,7 @@ All Jira work reaches the factory through a single event, `agent_session_created
 A session must match every field you set; within a field, any listed value is a match. Omit a field to match everything. For the matching rules shared by every source, see [automation filters](/factories/automation-filters/).
 
 :::caution
-Filters like `project_keys` decide whether *your* automation starts a run; they aren't an access boundary. A Jira event is evaluated against every team's automations in the connected workspace, so another team's automation with a broader or different filter can still start its own run on the same work item. Installing the Warp app doesn't scope its Jira access to specific projects either — scoping Jira project access by Warp team is coming soon.
+Filters like `project_keys` decide whether *your* automation starts a run; they aren't an access boundary. A Jira event is evaluated against every team's automations in the connected workspace, so another team's automation with a broader or different filter can still start its own run on the same work item. Installing the Warp app doesn't scope its Jira access to specific projects either.
 :::
 
 ## What happens during a run