Connect your factory

Connect your factory to the tools where your team already discusses, tracks, and reviews work. Wherever work starts, the factory keeps the original context — the thread, issue, or pull request — and posts results back to the same place.

Choose a source

Pick the sources that match where work starts for your team. You can connect more than one.

Source	Best for	Where follow-ups continue
Slack	Chat and support requests	The Slack thread or DM
GitHub	Issues, pull requests, reviews, and CI	The issue, pull request, or review thread
Linear	Planned issues	The Linear issue and its agent session
Jira	Work items assigned to Warp	The Jira agent session
Factory MCP	Sending work from a local coding agent	The factory work item
Direct runs and schedules	One-off or recurring work	The factory work item

Connect a source

1. Pick the factory you want to connect. If you don’t have one yet, follow the Warp Factories quickstart.
2. Connect the source: install the provider integration, set up the Factory MCP, or create a schedule. Each integration guide below walks through authorization; grant only the access the factory needs.
3. Tell the factory how to respond. Provider connections come with default automations that decide which events start work and which agent handles them; review their filters and run settings. Schedules and direct runs skip this step.
4. Send a test request, such as mentioning the factory in Slack or assigning it an issue, and confirm it picks up the work and replies at the source.

How work reaches your factory

flowchart LR
  Event["Event from a<br/>connected tool"] --> Automation["Matching<br/>automation"]
  Schedule["Schedule"] --> Automation
  Automation --> Foreman["Foreman agent"]
  Direct["Direct request"] --> Foreman
  Foreman --> Work["Work item"]
  Work --> Results["Results posted<br/>back to the source"]

An event from a connected tool starts the automation whose filters match it, such as a specific repository, channel, or label. Schedules start their automation on a timer, and direct requests go straight to the factory.

Every request then lands with the foreman agent, the factory’s orchestrator. The foreman turns the request into a work item, works out which stage the work needs next, and dispatches a specialized agent for each stage: triage to scope the request, spec when the design needs agreement, implementation to write the code, and review to check it. Between stages it relays questions and progress back to the source, and it pauses wherever a decision belongs to a human, such as approving a spec or merging a pull request. See how Warp Factories work for the full lifecycle.

Review the default automations

When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately:

• 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.
• 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.
• Linear - Starts work when a new agent session arrives from one of the Linear teams you selected. See the Linear integration guide.
• Slack - Starts work from mentions and messages, as described in the Slack integration guide.

These defaults are starting points. Review each automation’s filters, agent, and run settings, and adjust them to match your workflow.

Integration guides

• Slack - Route chat requests, direct messages, and thread follow-ups through a dedicated factory app.
• GitHub - Route repository events with issue, pull request, review, or CI context.
• Linear - Route planned issues through issue activity and agent sessions.
• Jira - Route Jira work items assigned to Warp into factory work.

Factory MCP

The Factory MCP connects local coding agents and other MCP clients to your factory. Use it to send work to the factory from your terminal, check status, coordinate with the foreman agent, and hand finished work back to the same work item. See the Factory MCP guide.

Direct runs and schedules

Not every task starts in an external tool:

• Start a direct factory run for one-off work: describe the task and the foreman agent takes it from there.
• Create a scheduled automation for recurring work such as maintenance or reports.

See the triggers overview for how schedules and other triggers work across the platform.

Good to know

• Follow-ups continue the same work item - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira agent session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don’t create duplicate work either.
• One issue tracker per factory - A factory can use Linear or Jira, or no tracker at all, but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your factory definition.
• Filters route work; they don’t restrict access - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. See automation filters for the matching rules.
• The factory hands off at the pull request - It pushes branches and opens pull requests with the repository credentials you configure, and waits for a human to review and merge. Branch protection and required reviews apply as usual.

Next, customize which agents receive work and how it’s routed with factory definitions as code.