Factory shipped its Automations feature to general availability on September 30, 2026, and it answers a question developer tools usually dodge: what happens when a coding agent has to do the same job every week?

The short version is that Automations turns Droid, Factory's Factory AI coding agent, into something closer to a teammate. You describe a workflow in plain language, pick what triggers it, and it runs on its own. Here's what that means in practice and where it still needs a human.

What Factory Automations Actually Is

An automation is a job that starts a Droid session when a trigger fires. That's the whole idea, and it's narrower than it sounds in a good way.

Each automation has four parts. A trigger decides what starts a run: a schedule, a Slack message, a GitHub event, or an incoming webhook. Instructions are the prompt Droid follows every time, with an optional model and reasoning level. A run identity decides who the run acts as, either you or a shared service account. A run target decides where Droid works: a Droid Computer, your own machine through the desktop app, or GitHub Actions for GitHub workflows.

That structure is the point. You're not writing a script. You're writing a standing instruction and attaching it to a repeating event.

How to Create a Factory Automation

The path from idea to running automation is short.

Open the Automations page from the Factory App sidebar.
Select New automation to open the marketplace of starting points.
Search or filter by trigger type: Scheduled, Slack, Webhook, or GitHub.
Pick a starter that matches your job, then point it at your repositories and channels.
Set the instructions, model, and run identity, then create it.

Factory groups starters by how much they set up for you, and it surfaces up to three recommended picks once it knows your role and connected apps. If you'd rather talk it through, choosing Create with Droid opens a session with a draft request already written, and Droid explains how automations work before asking what to run.

Ready-Made Factory Automation Starters

The marketplace ships with useful jobs out of the box, which is the fastest way to see what the feature does.

Ticket to PR runs every 15 minutes, picking up ready tickets from Linear or Jira one at a time and driving each to an open pull request.
PR Reviewer runs every 30 minutes during weekday hours and posts one review comment per head commit.
Daily Status Digest sends a weekday morning digest of your PRs and tickets, split by what needs you and what waits on others.
Code Health rotates through dependency audits, dead code, coverage gaps, and stale docs, landing one small maintenance PR per run.
Error Triage polls your error source hourly, investigates what matters, and opens a fix pull request when it's safe.
Slack Digest DMs you the threads waiting on you, plus mentions and channel highlights.
Slack Bug Fixer turns bug reports into tickets, posts a root-cause hypothesis in the thread, and opens a fix PR for small changes.

The pattern is telling. Factory expects teams to automate coding workflows, the boring, repeating parts of engineering, rather than the creative parts. Any developer automation tool that ignores the boring 80% is solving the wrong problem.

Factory Automations Triggers Explained

The trigger is where most of the value sits, because it decides how much babysitting you avoid.

Scheduled triggers run on a timer, which suits audits, digests, and anything that should happen regardless of what else is going on. Slack triggers fire when a message lands in a channel, so a bug report becomes a ticket without anyone filing it. GitHub triggers respond to repository events, and Factory reads GitHub automations from workflow files in your repos. Webhook triggers accept an HTTP POST to the automation's URL, which lets any service kick off a run.

Between the four, you can cover most recurring engineering chores without a cron server or a glue script.

Factory Automations Visibility and Identity

Two settings decide who sees a run and who it acts as, and getting them right matters.

Visibility controls whether an automation is private to you or shared with your organization, and who can open the sessions its runs create. A private automation keeps its output to you. A shared one lets the team see and audit what it did.

Run identity decides the account a run uses: you, or a service account your team shares. Service accounts are the safer default for shared automations, because a run that lives under one person's identity breaks when that person changes roles. Pair a service account with a shared automation and the job keeps running no matter who set it up.

Factory Automations Limits and Watch-Outs

Automations are powerful, and they can also quietly do the wrong thing on a schedule.

The first risk is prompt drift. Your instructions are fixed, but your codebase isn't, so a job written in October may misread a repository by December. Review shared automations periodically, not just when they break. The second is run cost. A job that fires every 15 minutes burns model tokens around the clock, and a poorly scoped prompt can waste a lot of them. The third is identity. A run under your personal account carries your access everywhere it goes, so scope it carefully.

The visibility controls carry a real upside. Because each run creates an openable session, you can inspect what an automation did and correct it, rather than trusting a black box. That audit trail is what makes standing jobs tolerable.

How Factory Automations Fits Into a Team's Day

The realistic use of Automations is to drain the queue of small, recurring jobs that nobody wants to own.

Think about a review that should happen on every pull request, a dependency audit that should run weekly, or a bug report that should become a ticket within minutes. Each one is small. Together they're a steady tax on a team's attention. Automations moves those jobs off a person's plate and onto a schedule or an event, which is the difference between a tool that helps and a tool that disappears into the background.

The starter library reflects exactly that worldview. Ticket to PR, PR Reviewer, Error Triage, and Slack Bug Fixer all exist because teams do those things repeatedly and manually. If your team's pain looks like that, the fit is obvious. If your work is mostly novel, one-off problems, Automations will sit unused, and that's fine.

Check other tool: