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

# 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 discusses, tracks, and reviews software work. Each intake path preserves source context and returns results to the same workflow.

Integrations provide provider authentication and writeback. Automations decide which events become factory work and how those runs execute.

## Choose a source

| Source | Best for | Context continuity | Typical outputs |
| --- | --- | --- | --- |
| Slack | Chat requests and support reports | Thread or direct message | Acknowledgment, summary, issue or pull request links |
| GitHub | Issues, pull requests, reviews, and CI | Issue, pull request, or review thread | Reactions, comments, branches, and pull request links |
| Linear | Planned issue work | Issue and agent session | Plans, issue updates, and pull request links |
| Jira | Issue work in Jira Cloud | Issue and comment history | Comments, issue updates, and artifact links |
| Factory MCP | Work exchanged with local agents | Work item and foreman conversation | Context, notes, and transferred artifacts |
| Direct or scheduled automation | One-off or recurring work | Work item and run history | Summaries, code changes, and pull request links |

## Connect and verify intake

1.  Create or select the factory that owns the work. Follow the [Warp Factories quickstart](./quickstart) if the factory is not running.
2.  Authorize the provider with the narrowest supported scope, or configure the Factory MCP, a direct run, or a schedule.
3.  For provider events, define the automation’s agent, run configuration, subscriptions, and filters. For recurring work, configure a schedule for the automation. Manual requests go directly to the foreman.
4.  Send a representative request. Confirm the factory creates or continues the expected work item and returns updates to the source.

## How intake works

```
flowchart LR  Provider["Provider event"] --> Integration["Integration"]  Integration --> Match["Subscription and<br/>filter matching"]  Match --> Automation["Configured automation"]  Schedule["Schedule tick"] --> Automation  Automation --> Foreman["Foreman run"]  Manual["Manual request"] --> Foreman  Foreman --> Work["Work item"]  Work --> Output["Updates and<br/>artifacts"]
```

1.  **Enter through the source.** A provider event reaches its integration, a schedule tick invokes its configured automation, or a manual request starts a foreman run.
2.  **Resolve provider events.** The integration matches a provider event against subscriptions and filters, then selects the configured automation. Schedules and manual requests skip this matching step.
3.  **Create or continue work.** The foreman receives the source context and creates a work item or continues the existing workstream.
4.  **Return results.** Provider integrations acknowledge requests where supported and write back. Manual and scheduled work retain results and artifacts on the work item.

See [how Warp Factories work](./how-factories-work) for routing after intake.

## Intake boundaries

| Concern | Boundary and behavior |
| --- | --- |
| Authorization | Slack uses one app per factory. GitHub uses a GitHub App installation and repository grants. Linear uses an OAuth workspace connection. Jira uses a site connection. Grant the narrowest provider-supported scope. |
| Routing | Subscriptions and filters select an automation for provider events. A schedule tick invokes its configured automation directly. A manual request starts a foreman run directly. Filters can select repository, channel, team, project, label, author, or status when available; they do not reduce integration access. |
| Duplicate delivery | Providers can retry events. Warp avoids duplicate work when the source identifies a repeated delivery, but receiving workflows must remain safe to retry, especially for Jira. |
| Continuation | A new reply is not a duplicate. Slack threads, GitHub issues, pull requests, and review threads, Linear issues and agent sessions, and Jira issues can continue an existing work item. |

## Provider differences

### Slack

Each factory has a dedicated Slack app. Mentions and direct messages create work; replies in the same thread continue it. The app acknowledges requests with a reaction, shows the current user’s tasks in **App Home**, and returns issue or pull request links. See [Slack integration setup](../platform/integrations/slack).

### GitHub

Automations can route supported issue, pull request, review, and CI events. Activity in the same issue, pull request, or review thread can continue a work item. Writeback includes reactions, comments, branches, and pull request links.

GitHub App credentials do not grant private-repository access or writes outside the installation’s repository grant. Public repository access and separately configured credentials follow separate rules. See [GitHub integration setup](../platform/integrations/github).

### Linear

Linear uses an OAuth workspace connection. Automations can route supported issue, comment, and agent-session activity by team, project, and issue attributes. Related activity continues the issue’s work item. Writeback can include plans, progress, errors, issue updates, reactions, and pull request links. See [Linear integration setup](../platform/integrations/linear).

### Jira

Jira uses an app connected to a Jira Cloud site. Automations can route supported issue, comment, mention, status, and assignment activity. The issue history continues the work item, and writeback includes comments, issue updates, and artifact links. Each requester connects their Jira identity.

Design Jira-triggered work to tolerate repeated delivery. Use narrow filters and duplicate-safe actions. See [Jira integration setup](../platform/integrations/jira).

## Factory MCP

The Factory MCP connects local coding agents and other MCP clients to a factory. Use it to find work, inspect context, coordinate with the foreman, and return notes or completed artifacts to the same work item. See the [Factory MCP guide](./factory-mcp).

## Direct and scheduled automation

Start a manual factory run for one-off work without an external source. Use a scheduled automation for recurring maintenance or reports. Event-driven automations use a connected provider instead. See the [triggers overview](../platform/triggers/).

Next, define the receiving agents and intake rules with [factory definitions as code](./factory-as-code).