Bodega Loops (Automations)

A Loop is a named agent task with a trigger and an apply policy:

• Task prompt - what the agent does each run (e.g. "Sync inline docs with the current implementation").
• Trigger - when it fires: a cron schedule, a fixed interval, or Bodega Map staleness.
• Apply policy - what happens to the changes: park for review (default), auto-apply when QEL passes, or dry run.

Each run is a normal headless agent session: it appears in your session history, respects your permission mode and tool allowlists, inherits air-gap mode, and counts against your cloud spend caps if it uses a cloud model. Local models run free.

1. Go to Settings → AI Behavior → Loops (or click + New in the Bodega Loops sidebar panel).
2. Turn on Enable Loops. The scheduler is dormant while this is off - nothing fires, including Run now. Flipping it takes effect within a minute; no restart.
3. Click New loop. Give it a name, a task prompt, and a project path - the project must be a git repository (scheduled runs require worktree isolation).
4. Choose what it runs with (see below), pick a trigger and an apply policy, then Create loop.
5. Use Run now on any loop to test it immediately and watch the result land in its History.

Each loop chooses its own brain, the same way a heterogeneous Fleet does - so you can point cheap, small jobs at a fast local model and reserve a cloud model for the heavy ones.

• Default agent (pick a model): leave it on the default agent and choose a provider + model from the picker (the same grouped picker the chat composer uses - it only lists models you've actually set up). Leave the model blank to inherit your default code model.
• A custom agent: pick one of your custom agents (Settings → Custom Agents). The loop then runs as that agent - its system prompt, tool allowlist, read-only setting, and pinned model all apply. A custom agent pinned to a cloud model routes to that cloud provider even when your active provider is local.

Either way the model drives the provider automatically; a loop never runs the wrong model on the wrong provider.

Loops fire while Bodega is open - the scheduler is in-process. Runs missed while the app was closed are not replayed. A loop can also be driven by inline code comments (the comment-trigger watch mode above).

The apply decision is made by the QEL verification gate, never by the agent grading its own work:

• Park for review (default) - every run lands as a reviewable diff with its QEL score. Nothing is applied, ever. Review and apply from the run's session like any Fleet session.
• Auto-apply when QEL passes - changes merge back automatically ONLY when the run's QEL score clears the threshold. Failing runs park as qel_failed with the diff preserved. Opt into this per loop once you've seen consistent scores you trust.
• Dry run - the agent runs in its isolated worktree and reports a score; the diff is kept for inspection but never applied.

The optional QEL threshold (0–100) sets the bar for auto-apply. Leave it empty to use the verifier's model-tier default; set it explicitly and your number is authoritative - stricter or looser.

The Bodega Loops panel - the loop icon in the Code-mode activity bar - is the dashboard: every loop with its trigger, a live running dot, Run now, and expandable run history. The same history also lives under each loop in Settings.

Each loop's History shows every run: status (applied, parked, qel_failed, no_changes, failed, cancelled), duration, files changed, iterations, and the QEL score. Expand a run to read the full QEL trace - file checks, pattern checks, proof gates, and the score breakdown.

The topbar pill shows a purple count while loops are running and a red dot when a run fails or misses its QEL bar. A loop can never fail silently - the badge stays until you click it (which opens this Settings section).

Hover for detail (beta.27): hovering the topbar pill shows each loop's name, last outcome, QEL score, and files changed.

Notifications (beta.27): when a run parks, applies, or fails, Bodega fires an in-app toast - and an OS notification if enabled - with the loop name, outcome, files changed, and QEL score ("Nightly docs sync: parked for review - 3 files, QEL 82%"). These share the Fleet notification and quiet-hours settings.

Next-run countdown (beta.28): interval and Map-staleness loops show a live "next in 14 min" countdown on their rows, so you never wonder whether a loop is about to fire.

Run now from the topbar (beta.28): the topbar pill's hover panel gained a per-loop Run now button. Runs that need a person - parked for review, failed, or below their QEL bar - also land in the topbar Runs Inbox, alongside Fleet sessions waiting on approval or apply.

Stop a running loop (beta.29): while a loop is running, the topbar pill shows a stop button - and a per-loop Stop in the hover panel. Stopping cancels the run mid-flight: the agent halts at its next checkpoint, the run is marked cancelled, and any partial work is left in its isolated worktree for review, never auto-applied.

• Scheduled runs require worktree isolation. If the project isn't a git repo (or isolation is unavailable), a scheduled run refuses and records failed rather than writing to your working copy. Run now keeps a warned in-place fallback for deliberate, watched runs.
• Concurrency cap - at most loops.max_concurrent runs at once (default 1); extra triggers skip and retry on their next natural firing.
• Spend caps apply. A loop on a BYOK cloud model is refused with the same "spend cap reached" behavior as a foreground chat once your daily/monthly cap is hit. Local models are never gated.
• Air-gap is inherited. Under air-gap, a loop that needs the network is blocked exactly like a foreground run.
• Iteration cap - each loop has its own max-iterations (clamped to your global agent ceiling).
• A crash mid-run can't wedge the scheduler: orphaned runs are marked failed on the next launch.