Connect your factory

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

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.

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.

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.

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.

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.

Next, define the receiving agents and intake rules with factory definitions as code.