Recurring workflows (/loop) and Autopilot

Most of the time you hand the agent a single task and get a PR. A workflow is the next step up: a standing objective that the agent keeps working toward on its own, opening a PR each time it makes progress. It's how you point a fleet at a repo objective and walk away.

Start a loop

In the composer, type /loop followed by what you want done:

/loop keep the test suite green and fix any new type errors

• Self-paced (no interval) — the agent works toward the goal, decides how long to wait between attempts, and stops on its own once the objective is provably met. Good for "get this done" objectives.
• On a schedule — lead with an interval and it re-runs every period:

/loop 6h triage new GitHub issues labelled bug and open a fix PR

Supported interval units are s, m, h, d (e.g. 30m, 6h, 1d).

Each iteration runs as a normal autonomous goal — it plans, writes code, runs your tests, and opens a PR on a flarecode/task-* branch for you to review. You stay the merge gate, exactly like a one-off task.

Autopilot: point it at your backlog

Instead of a standing prompt, an autopilot works through a real backlog — one item per iteration, each shipped as its own PR. Open Workflows → New autopilot in a project and pick what it works on:

• GitHub issues — the repo's open issues, oldest first (optionally only a label, e.g. bug).
• Linear project — un-started issues from a project you pick, highest priority first. Done work is written back to the issue (the PR link is commented; GitHub issues auto-close on merge).
• Standing objective — the classic /loop, in form shape.

Then set two numbers — a per-task cap and a total budget — and start. That's the whole setup.

While it runs:

• It picks up the next item the moment the previous one ships.
• An issue it already attempted is never picked up again on its own — you decide whether to retry.
• When the backlog is clear it idles and watches for new issues instead of stopping; file an issue and it picks it up.
• When something only you can answer comes up — a clarifying question, a plan that needs review, a PR waiting on you — the loop pauses on that item only, and you get an email/Slack ping with the question and a one-tap link to answer from any device. Answer, and it carries on.

While you were away

The Workflows view opens with a digest of the last 24 hours: what shipped (and where), what failed, total spend, and — front and center — anything waiting on you, one click from answering or reviewing.

Watch it, pause it, stop it

The loop shows up as a live card in the session it was launched from: status, how many iterations have run, spend so far, when the next run is due, and the recent runs (each links to its PR). The same loops are listed across sessions under Workflows in a project's menu. You can pause (finish the current iteration, then hold), resume, or stop at any time.

It can't run away

Every workflow is bounded, on top of the per-task cost cap that already protects every run:

• a per-task cap — a task that hits it is killed, not the loop,
• a maximum number of iterations,
• a total budget cap across the whole loop, and
• it halts on a streak of failures.

When you don't set your own limit, a loop uses your default iteration cap — editable under Settings → General → Automation. When any limit is hit — or a self-paced loop decides the objective is met — the workflow completes and you get a notification. There is no way to start an unbounded loop.

Loops that start themselves

A workflow doesn't have to begin with you typing /loop. A recurring trigger on a project can stand one up automatically — pointed at the project's objective — so ongoing work (dependency upkeep, issue triage, chipping away at a backlog) keeps moving without a person kicking it off each time. The same caps apply.

Related

• Interactive vs goals — the single-task building block a loop iterates on.
• Costs and limits — the per-task cap each iteration respects.
• Hooks — add your own guardrails around what agents (and loops) may do.