CI Runs Your Tests. Automations Runs Your Agents.

Every team already trusts one piece of automation completely: CI. You push, and something runs your tests without anyone asking it to. Nobody opens a terminal to run the suite by hand anymore — it just happens, and you find out if it broke.

Agent work has been stuck one step behind that. You still have to be the one who starts it: open the app, pick a repo, spawn an agent, write the prompt, watch it, then decide what to do with whatever it produced. The agent is fast. You are still the trigger, every single time.

Automations is the part of Sprint Engine Studio that takes you out of that loop. You wire up a trigger and an action once. After that a schedule or an event starts the run on its own, in an isolated worktree, and the work comes back as a pull request you review like any other.

A trigger, an action, and a run you can trust

The model is deliberately small. An automation is one trigger wired to one action, scoped to a single project. Three kinds of trigger ship today:

• Schedule — interval, daily, or weekly. A dependency-bump pass every morning, or a docs-sync every Friday.
• Repo event — fires when a GitHub or Jira item changes. Automations watches the source data Switchboard already syncs locally, so a new or updated issue can start a run without you pasting anything.
• Webhook — a local, HMAC-signed inbound endpoint for tools that can reach your machine. It is off by default and only listens once you give it a port, a path, and a secret.

The actions are where it pays off. The headline one is spawn-agent: launch a specialist with a directive and an autonomy level. But actions can also call the front doors of the rest of the product — kick a Switchboard queue, launch a Watchtower review, start a Sprint Engine run — so a single automation can drive a whole workflow, not just one prompt.

# A weekly, autonomous security pass that comes back as a PR
trigger:
  kind: schedule
  cadence: weekly        # Mondays, 09:00 local
action:
  kind: spawn-agent
  specialist: security   # runs in-role, fetches the role's Soul
  autonomy: review_only  # may read and propose, may not push on its own

Why each run gets its own worktree

The risky part of unattended agent work is not the agent. It is the blast radius. A run editing your working tree while you are away is how you come back to a tangle of changes you never asked for, sitting on top of whatever you were doing.

So every agent-backed run executes in its own git worktree, branched from HEAD. The agent works in isolation, and when it is done the run finalizes: the branch is committed, pushed, and opened as a pull request, then the worktree is torn down. You do not get a diff to reconcile. You get a branch and a PR, sitting exactly where a teammate's work would be.

The agent declares its own outcome by writing a small signal file as its last step, and the engine finalizes the moment it sees one. No babysitting, no manual "mark as done" — and because the signal file is kept out of the commit, it never leaks into the PR.

The safeguard that makes "autonomous" safe

Autonomy is a setting, not a leap of faith. A run is either review_only or allow_changes. A review_only run can read, reason, and propose — but the finalize step refuses to push a non-empty diff.

If such a run somehow produces changes anyway, Automations withholds them and records the run as blocked instead of quietly opening a PR. The guard lives at finalize time, so it holds even if the underlying CLI's permissions were set too loosely. You get the analysis without the surprise commit.

Failed and blocked runs raise a notification with a deep link straight to the run. Successful runs stay quiet on purpose — the pull request is the notification.

It composes the rest of the product

The second half of this feature is integration, and the design choice there matters. Automations does not reimplement Switchboard's intake, Watchtower's reviews, or Sprint Engine's runners. It calls them through the same module front doors you already use, and a missing or disabled module turns into a clearly blocked run rather than a fake success.

• Schedule a Watchtower security or brand-alignment review to run every night.
• Turn a freshly synced GitHub or Jira issue into a triaged Switchboard run.
• Let a webhook from your own tooling start a Sprint Engine run.
• Run any specialist — architect, security, tester — on a cadence, in-role.

That composition cuts both ways for trust. First-party actions run as-is; a third-party provider is re-checked against module trust and your settings every time it is about to fire. A denied provider stays visible with its reason — it simply cannot execute.

What it is, and what it isn't

Worth being precise about the edges, because over-claiming helps no one:

• It is local-first. The engine, definitions, and run history live under your project, not in a cloud control plane. The webhook receiver binds to localhost; it is not an internet-facing endpoint.
• Repo-event triggers read synced data, so they are as fresh as Switchboard's sync — not a real-time push from GitHub.
• Pull requests are opened through your gh setup, so a run finalizes as a PR when the repo has a remote it can push to.
• Schedules are interval, daily, or weekly today. A loaded cron schedule is preserved but not yet evaluated.

Why this matters

The first time an agent fixes something useful while you are asleep and leaves a PR waiting in the morning, the relationship changes. The tool stops being something you operate and becomes something that works on your behalf — with the same isolation, review gate, and evidence trail you would want from a careful teammate.

CI made running tests something that just happens. Automations makes agent work something that just happens — and still comes back for review.