Autonomy

Autonomous loops

Some work needs more than one turn — keep going until the tests pass, the file exists, the task is actually done. Brigade's loop-runner drives an agent (or a planner/executor stage) step by step under hard guards, and stops only when independent checks say it is finished or a guard fires. It never stops just because the agent claims it is done.

The guards#

Every loop runs inside a budget and two progress detectors:

GuardWhat it does
BudgetHard ceilings on iterations, wall-clock time, and tokens (maxIterations / maxMs / maxTokens). The loop cannot run forever.
No-progressEach step reports a state fingerprint. If it stops changing for N steps (the patience), the loop halts — no silent spinning.
RepetitionEach step reports an action label. If the same action repeats too many times in a window, the loop halts.

Independent done-checks#

The preferred way to end a loop is an independent termination check — an objective signal the agent does not control: a test suite passing, a file existing, a tool call succeeding. The loop ends only when all the done-checks pass, or a guard fires. This is the project-wide principle in action: independent verification, never the agent judging itself.

Quality gate on every step#

Each step's output is gated through the anti-slop detector with one bounded repair retry, wired as a post-generation hook — so a loop that runs unattended still cannot ship low-effort text. See Quality & reliability.

Loop shapes#

  • A single agent driven step-by-step toward a goal.
  • A plan-and-execute shape, where the step callback alternates a planner and an executor stage.

Built to be safe by construction

The loop-runner is standalone and testable without a live gateway: the control logic (budget, no-progress, repetition, done-checks) is separate from the agent turn it drives. That is what makes "run autonomously toward a goal, but know when to stop" a property you can rely on rather than a hope.