Factories
Connect your factory
# Connect your factory Connect a factory to the tools where your team already discusses, tracks, and reviews software work. Integrations and automations preserve the source context, route the request to the factory's foreman, and return updates to the same tool. :::note Warp Factories is currently in closed beta. Access is limited while Warp works with participating teams to validate the product. ::: ## How work enters a factory Every supported intake path follows the same model: 1. **Install or authorize the integration.** Connect the provider and grant the narrowest provider-supported access the factory needs. Slack uses a dedicated app for each factory. GitHub authorization follows the GitHub App installation and its repository grants, Linear authorization follows the OAuth workspace connection, and Jira authorization follows the connected Jira site. 2. **Match an automation.** A provider event or schedule matches an enabled automation and its filters. The automation selects the receiving agent and run configuration. Filters route authorized events to factory work; they do not change the integration's access. 3. **Create or continue a work item.** New work becomes a work item. The foreman receives the source context, selects the next stage, and dispatches specialized agents. A related reply or update can continue the existing work item instead of creating another one. 4. **Return updates and artifacts.** The integration acknowledges the request where supported, posts progress and results, and links artifacts such as branches or pull requests back to the source. A manual factory run creates a work item without an external provider event. The [Warp Factories quickstart](./quickstart) walks through creating a factory and sending its first work item. ## Configure automations An automation connects an intake signal to an agent in the factory. It contains: * **An enabled agent and run configuration** - Selects the agent that receives matching work and defines how the run executes. * **Event subscriptions** - Listens for one or more supported events from a connected provider. * **Filters** - Narrows the authorized events that create work. Depending on the provider, filters can select repositories, channels, teams, projects, labels, authors, or statuses. * **An optional schedule** - Runs the automation on a recurring cron schedule instead of waiting for a provider event. Use filters to keep the automation's responsibility narrow. For example, one GitHub automation can handle failed CI runs in a specific repository, while another handles newly labeled issues. A Linear automation can watch one team and project without responding to every issue in the workspace. Provider authorization and automation routing are separate. The installation or connection defines provider read and write access. Filters choose which authorized events create factory work; they do not reduce credential access. Grant the narrowest provider-supported installation scope, then filter intake. Providers can retry events. When the source identifies a repeated delivery, the factory avoids duplicate work for the same automation. Overlapping subscriptions for one automation still run once. Delivery guarantees vary, so make the receiving workflow safe to run again. Continuation is separate from duplicate handling. A new reply, comment, or review event is a new delivery, but the factory can associate it with the existing Slack thread, GitHub issue or review thread, Linear issue or agent session, or Jira issue. The foreman then receives the new context as part of the same workstream. [How Warp Factories work](./how-factories-work) explains how the foreman preserves context across agent runs. ## Choose an entry point | Source | Best for | Context continuity | Typical outputs | | --- | --- | --- | --- | | Slack | Requests and support reports discussed in chat | Channel thread or direct-message conversation | Acknowledgment, status, summary, issue or pull request links | | GitHub | Repository events, issues, pull requests, reviews, and CI results | Issue, pull request, or review thread | Reactions, comments, branches, and pull request links | | Linear | Planned work and issue-driven development | Issue comments and Linear agent sessions | Plans, progress, issue updates, reactions, and pull request links | | Jira | Issue-driven work in Jira Cloud | Issue and comment history | Comments, issue updates, summaries, and artifact links | | Factory MCP | Work exchanged with local coding agents and MCP clients | Factory work item and foreman conversation | Context, notes, local results, and transferred artifacts | | Direct or scheduled automation | One-off tasks and recurring maintenance | Factory work item and run history | Run summaries, code changes, and pull request links | ## Supported integration entry points ### Slack Each factory connects through its own Slack app. This keeps the app's identity and incoming requests associated with one factory rather than requiring a shared app to choose among factories after every message. Mention the factory's app in a channel, send it a direct message, or reply in a thread it owns. A new request creates work for the foreman. Later replies in the same thread continue that work with the prior conversation as context. The app acknowledges accepted requests with a reaction so the requester knows the factory received the message. The app's **App Home** shows the current user's factory tasks with status and date filters. Slack updates can also include links to issues and pull requests produced by the work item. For workspace requirements and the underlying authorization model, see the [Slack integration documentation](../platform/integrations/slack). ### GitHub Install the GitHub App and grant it access only to the repositories the factory needs. Automations can respond to supported issue, pull request, review, and CI events, then filter those events by repository and other available metadata. GitHub issue, pull request, and review-thread activity supplies both the request and the surrounding repository context. Related follow-ups continue the existing workstream. Depending on the event and automation, writeback can include acknowledgment reactions, comments, branches, and pull request links. When an automation relies on GitHub App credentials, the agent receives a token limited to the repositories granted to that installation. The token does not provide private-repository access or write permission outside the installation's grant. Public repository access and separately configured credentials follow separate access rules. The agent uses normal Git and GitHub operations to push branches and open or update pull requests. See the [GitHub integration documentation](../platform/integrations/github) for installation and repository-access details. ### Linear Connect a Linear workspace through OAuth, then scope factory automations to the relevant teams, projects, and issue attributes. Supported issue, comment, and agent-session activity can create work or continue the work already associated with an issue. Linear supports detailed writeback during and after a run. Agents can publish plans, actions, responses, errors, and external links in the agent session. Depending on the workflow, they can also update issue state or delegation, add labels or reactions, and attach a GitHub pull request to the issue. See the [Linear integration documentation](../platform/integrations/linear) for workspace connection requirements. ### Jira Install the Jira app, connect the Jira Cloud site to Warp, and use automation filters to select the relevant projects and issues. Automations can respond to supported issue, comment, mention, status, and assignment activity. The issue and its comments remain the source context for the work item. The Jira connection writes results back to the issue through comments and permitted issue updates, including links to code artifacts. Each person who triggers factory work must connect their Jira identity so Warp can attribute the request to the correct team member. See the [Jira integration documentation](../platform/integrations/jira) for app installation and account-connection steps. Design Jira-triggered work to tolerate repeated delivery. Use narrow event subscriptions and filters, and make the receiving workflow safe to run again without creating duplicate comments, branches, or pull requests. ### Factory MCP The Factory MCP connects local coding agents and other MCP clients to a factory. Use it when work begins in a local development session, needs local-only context, or requires a developer to take over part of an existing factory work item. An MCP client can find factory work, inspect its context, coordinate with the foreman, and return notes or completed artifacts to the same work item. This preserves the factory's workflow record while letting the developer use the local agent and environment suited to the task. See the [Factory MCP guide](./factory-mcp) for setup, workflows, and the tool reference. ### Direct and scheduled automation Start a manual factory run for a one-off request that does not originate in another tool. The prompt becomes the work item's initial context, and the foreman routes it through the same factory workflow as integration-triggered work. Use a scheduled automation for recurring work such as repository maintenance, dependency review, or a periodic engineering report. A cron schedule starts the configured automation at the specified time. Event-driven automations use the connected provider instead. See the [triggers overview](../platform/triggers/) for the supported trigger patterns and scheduled-agent documentation. ## Connect an intake path 1. Create or select the factory that will own the work. Follow the [Warp Factories quickstart](./quickstart) if the factory is not running yet. 2. Connect the provider and scope its access. Use the setup guide for [Slack](../platform/integrations/slack), [GitHub](../platform/integrations/github), [Linear](../platform/integrations/linear), or [Jira](../platform/integrations/jira). 3. Define an automation with an enabled receiving agent, run configuration, event subscriptions, and the narrowest useful filters. Add a schedule only for recurring work. See [factory definitions as code](./factory-as-code) for the declarative configuration model. 4. Send a representative request or event from the source. Confirm that the source receives an acknowledgment where supported, the factory creates or continues the expected work item, and outbound updates return to the same context. The integration controls authentication and transport. The automation controls which events become factory work. The foreman controls how each accepted work item moves through the factory.Tell me about this feature: https://docs.warp.dev/factories/connect-your-factory/Route work into your factory from Slack, Linear, GitHub, and local coding agents via the Factory MCP.
Connect a factory to the tools where your team already discusses, tracks, and reviews software work. Integrations and automations preserve the source context, route the request to the factory’s foreman, and return updates to the same tool.
How work enters a factory
Section titled “How work enters a factory”Every supported intake path follows the same model:
- Install or authorize the integration. Connect the provider and grant the narrowest provider-supported access the factory needs. Slack uses a dedicated app for each factory. GitHub authorization follows the GitHub App installation and its repository grants, Linear authorization follows the OAuth workspace connection, and Jira authorization follows the connected Jira site.
- Match an automation. A provider event or schedule matches an enabled automation and its filters. The automation selects the receiving agent and run configuration. Filters route authorized events to factory work; they do not change the integration’s access.
- Create or continue a work item. New work becomes a work item. The foreman receives the source context, selects the next stage, and dispatches specialized agents. A related reply or update can continue the existing work item instead of creating another one.
- Return updates and artifacts. The integration acknowledges the request where supported, posts progress and results, and links artifacts such as branches or pull requests back to the source.
A manual factory run creates a work item without an external provider event. The Warp Factories quickstart walks through creating a factory and sending its first work item.
Configure automations
Section titled “Configure automations”An automation connects an intake signal to an agent in the factory. It contains:
- An enabled agent and run configuration - Selects the agent that receives matching work and defines how the run executes.
- Event subscriptions - Listens for one or more supported events from a connected provider.
- Filters - Narrows the authorized events that create work. Depending on the provider, filters can select repositories, channels, teams, projects, labels, authors, or statuses.
- An optional schedule - Runs the automation on a recurring cron schedule instead of waiting for a provider event.
Use filters to keep the automation’s responsibility narrow. For example, one GitHub automation can handle failed CI runs in a specific repository, while another handles newly labeled issues. A Linear automation can watch one team and project without responding to every issue in the workspace.
Provider authorization and automation routing are separate. The installation or connection defines provider read and write access. Filters choose which authorized events create factory work; they do not reduce credential access. Grant the narrowest provider-supported installation scope, then filter intake.
Providers can retry events. When the source identifies a repeated delivery, the factory avoids duplicate work for the same automation. Overlapping subscriptions for one automation still run once. Delivery guarantees vary, so make the receiving workflow safe to run again.
Continuation is separate from duplicate handling. A new reply, comment, or review event is a new delivery, but the factory can associate it with the existing Slack thread, GitHub issue or review thread, Linear issue or agent session, or Jira issue. The foreman then receives the new context as part of the same workstream. How Warp Factories work explains how the foreman preserves context across agent runs.
Choose an entry point
Section titled “Choose an entry point”| Source | Best for | Context continuity | Typical outputs |
|---|---|---|---|
| Slack | Requests and support reports discussed in chat | Channel thread or direct-message conversation | Acknowledgment, status, summary, issue or pull request links |
| GitHub | Repository events, issues, pull requests, reviews, and CI results | Issue, pull request, or review thread | Reactions, comments, branches, and pull request links |
| Linear | Planned work and issue-driven development | Issue comments and Linear agent sessions | Plans, progress, issue updates, reactions, and pull request links |
| Jira | Issue-driven work in Jira Cloud | Issue and comment history | Comments, issue updates, summaries, and artifact links |
| Factory MCP | Work exchanged with local coding agents and MCP clients | Factory work item and foreman conversation | Context, notes, local results, and transferred artifacts |
| Direct or scheduled automation | One-off tasks and recurring maintenance | Factory work item and run history | Run summaries, code changes, and pull request links |
Supported integration entry points
Section titled “Supported integration entry points”Each factory connects through its own Slack app. This keeps the app’s identity and incoming requests associated with one factory rather than requiring a shared app to choose among factories after every message.
Mention the factory’s app in a channel, send it a direct message, or reply in a thread it owns. A new request creates work for the foreman. Later replies in the same thread continue that work with the prior conversation as context. The app acknowledges accepted requests with a reaction so the requester knows the factory received the message.
The app’s App Home shows the current user’s factory tasks with status and date filters. Slack updates can also include links to issues and pull requests produced by the work item. For workspace requirements and the underlying authorization model, see the Slack integration documentation.
GitHub
Section titled “GitHub”Install the GitHub App and grant it access only to the repositories the factory needs. Automations can respond to supported issue, pull request, review, and CI events, then filter those events by repository and other available metadata.
GitHub issue, pull request, and review-thread activity supplies both the request and the surrounding repository context. Related follow-ups continue the existing workstream. Depending on the event and automation, writeback can include acknowledgment reactions, comments, branches, and pull request links.
When an automation relies on GitHub App credentials, the agent receives a token limited to the repositories granted to that installation. The token does not provide private-repository access or write permission outside the installation’s grant. Public repository access and separately configured credentials follow separate access rules. The agent uses normal Git and GitHub operations to push branches and open or update pull requests. See the GitHub integration documentation for installation and repository-access details.
Linear
Section titled “Linear”Connect a Linear workspace through OAuth, then scope factory automations to the relevant teams, projects, and issue attributes. Supported issue, comment, and agent-session activity can create work or continue the work already associated with an issue.
Linear supports detailed writeback during and after a run. Agents can publish plans, actions, responses, errors, and external links in the agent session. Depending on the workflow, they can also update issue state or delegation, add labels or reactions, and attach a GitHub pull request to the issue. See the Linear integration documentation for workspace connection requirements.
Install the Jira app, connect the Jira Cloud site to Warp, and use automation filters to select the relevant projects and issues. Automations can respond to supported issue, comment, mention, status, and assignment activity.
The issue and its comments remain the source context for the work item. The Jira connection writes results back to the issue through comments and permitted issue updates, including links to code artifacts. Each person who triggers factory work must connect their Jira identity so Warp can attribute the request to the correct team member. See the Jira integration documentation for app installation and account-connection steps.
Design Jira-triggered work to tolerate repeated delivery. Use narrow event subscriptions and filters, and make the receiving workflow safe to run again without creating duplicate comments, branches, or pull requests.
Factory MCP
Section titled “Factory MCP”The Factory MCP connects local coding agents and other MCP clients to a factory. Use it when work begins in a local development session, needs local-only context, or requires a developer to take over part of an existing factory work item.
An MCP client can find factory work, inspect its context, coordinate with the foreman, and return notes or completed artifacts to the same work item. This preserves the factory’s workflow record while letting the developer use the local agent and environment suited to the task. See the Factory MCP guide for setup, workflows, and the tool reference.
Direct and scheduled automation
Section titled “Direct and scheduled automation”Start a manual factory run for a one-off request that does not originate in another tool. The prompt becomes the work item’s initial context, and the foreman routes it through the same factory workflow as integration-triggered work.
Use a scheduled automation for recurring work such as repository maintenance, dependency review, or a periodic engineering report. A cron schedule starts the configured automation at the specified time. Event-driven automations use the connected provider instead. See the triggers overview for the supported trigger patterns and scheduled-agent documentation.
Connect an intake path
Section titled “Connect an intake path”- Create or select the factory that will own the work. Follow the Warp Factories quickstart if the factory is not running yet.
- Connect the provider and scope its access. Use the setup guide for Slack, GitHub, Linear, or Jira.
- Define an automation with an enabled receiving agent, run configuration, event subscriptions, and the narrowest useful filters. Add a schedule only for recurring work. See factory definitions as code for the declarative configuration model.
- Send a representative request or event from the source. Confirm that the source receives an acknowledgment where supported, the factory creates or continues the expected work item, and outbound updates return to the same context.
The integration controls authentication and transport. The automation controls which events become factory work. The foreman controls how each accepted work item moves through the factory.