Automations

What it is

An Automation is its own thing, not a ticket. It holds a prompt, a trigger, and the settings a run needs. When it fires, it creates a ticket and dispatches a Worker.

This is how recurring engineering work stops depending on somebody remembering.

Triggers

Metric triggers are the interesting ones. Because Fredrin already holds your connectors, an Automation can watch real production data and open a ticket about it. Error rate crosses a line, and a Worker is already investigating before you read the alert.

A metric trigger measures an explicit window and can carry a deadband, so a noisy number does not open forty tickets. The deadband is yours to set; there is none by default.

What to automate

Good candidates share a shape: valuable, repetitive, and safe to attempt unattended.

• Fix the failing tests. Run the suite, open a ticket for what is red, fix it.
• Dependency bumps. Update, run the suite, open a PR.
• The daily lint sweep.
• Investigate a metric. Triggered rather than scheduled.

Bad candidates share a shape too: anything where a wrong answer is expensive and nobody is watching. Automations run unattended by definition.

Unattended runs behave differently

An automated Worker cannot stop and ask you a question, so it does not. Instead of blocking, it proceeds on its own recommended answer and records the assumption in the plan's Open questions.

The degrade drops the asking, never the finding. You see what it assumed when you review the diff.

Pair this with approval gates when the stakes justify it: an Automation can be allowed to do the work while still requiring a human to approve the merge.

Runs land on the board

An Automation's output is an ordinary ticket in the ordinary Review column. There is no separate automation inbox to check, and no second review workflow to learn.

Next steps

• Connectors - the data a metric trigger reads.
• Review and merge - gating what an Automation produces.
• Goals - hands-off runs that are a milestone rather than a routine.