How Do You Send Work to a Software Factory from Slack, Linear, GitHub, or Your Terminal?

You send work to a software factory from wherever the work already lives: a Slack mention, a tagged Linear or Jira issue, a GitHub or GitLab event, or your terminal through the factory's MCP server. Every surface triggers the same orchestrating agent, so the integration you pick changes who can start work and what access that costs — not how the work runs.

Every integration is a door into the same factory

A cloud software factory is an automation loop around the SDLC — triage, spec, implement, review, verify, ship, monitor — with agents doing the repeatable work and humans at the decision points. Work enters that loop by triggering the factory's orchestrator, often called the foreman, which takes the context from the trigger and dispatches the right agent for the stage the work is in.

Triggers come in two shapes. Explicit ones are a person addressing the factory: an @-mention in a Slack thread, a command from a terminal. Implicit ones are events: a label added to a Jira issue, a review requested on a pull request, a monitoring agent filing a ticket after a crash. Implicit triggers are what turn a factory from a tool people remember to use into infrastructure that runs whether they remember or not.

Because every door leads to the same foreman, you don't need a workflow per tool. You need one factory definition and several ways in.

Which door for which work?

Notice the last column varies far more than the first three. That's the part teams underestimate.

The two-plane rule: intake access is not code access

Talking to a factory and letting a factory touch your code are two different grants, and conflating them is how integration setup quietly becomes a security review.

The intake plane is where a request arrives — a channel, a project, a repository's event stream. It needs enough access to see the trigger and post back. The execution plane is what the agent can read and write once work starts. It needs the specific repos the work touches, and nothing else.

The failure mode is granting execution-plane access to buy an intake-plane convenience. A concrete version: connecting a factory identity to your whole source-code organization so that repository or factory names autocomplete in a picker. The convenience is real and small. The cost is standing read access to every repository in the org, all the time, for a machine identity — and access follows that identity, not the task, so anyone who can act as it reaches everything it can reach. That is a poor trade, and infosec will say so.

Three questions before you approve any factory integration:

1. What does this grant see when nothing is running? Standing access should be the narrowest thing that still makes the trigger fire.
2. Is this an identity or a scope? A shared machine user carries its access everywhere. A per-repo, per-project scope expires with the work.
3. What am I actually buying? If the answer is autocomplete, decline and type the name.

Broad access is sometimes the right call — a factory that maintains dependencies across forty services genuinely needs forty repos. The rule isn't "grant less"; it's "grant for the work, not for the convenience."

What most teams get wrong

They wire every integration on day one. Five doors into a factory that has one reliable workflow just multiplies the ways a half-finished loop gets triggered.

They also forget the return path. Intake is half the integration; the other half is the factory reporting back into the same surface — status in the thread that asked, a comment on the issue, a review on the PR. A factory that only accepts work and reports elsewhere trains people to stop using it. And when a run needs a human, the handoff has to work in both directions: taking over a cloud agent mid-run is what keeps a stuck task from becoming a dead one.

How Warp fits

Warp Factories provides the control plane for operating a cloud software factory, rather than another coding agent alongside Claude Code, Codex, or Cursor. Intake from Slack, Teams, Linear, Jira, GitHub, and GitLab ships out of the box, with a complete API, SDK, and CLI for building the doors Warp doesn't provide.

The Factory MCP is the door most teams miss: any MCP-capable coding agent can push work into a factory, pull status, guide a running session, or bring in-flight work down to iterate on locally — so a developer's choice of local agent stops being a factory integration decision. Alongside it, the control room shows every live and historic run across all of those surfaces in one place, which is the visibility argument for consolidating intake rather than letting each team wire its own.

Because factories are defined as version-controlled code, which integrations exist and what they can reach is reviewable in a pull request instead of remembered from a settings page. Warp reports serving over 700,000 developers, including Docker, Ramp, and Peloton, and more than half of the Fortune 500 — context for the integration surface, not a promise about your workflow. On the access question, Warp's position is that you own your factory: bring your own inference, hosting, and data storage, with zero data retention available.

Start with one door

Pick the surface where the work you want to automate already arrives — usually Slack for reported bugs, the issue tracker for planned work, the forge for review. Wire that one, scope its access to the repos the workflow touches, and confirm the factory reports back into the same place. Add the second door once the first workflow is boring.

For the wider picture — the SDLC loop, orchestration, evals, and build-versus-buy — start with A guide to cloud software factories for engineering leaders, or read Get agents off your machine for why governed cloud runtimes beat laptop agents. Apply to the Warp Factories beta.