Skip to content

Loop Readiness Levels

loop-engine audit produces a numeric score (0-115), but a raw number doesn't tell you what's actually safe to turn on. Use these levels to decide how much autonomy a loop has earned - and re-run loop-engine audit --suggest after every change, since the score is only as honest as its inputs.

L0 - Draft

Intent is documented (loop.yaml exists with a name and pattern), but nothing has run yet. This is where loop-engine init leaves you.

  • Audit categories that matter: Configuration, Structure.
  • Do not point this at write-capable credentials yet.

L1 - Report Only

The loop reads state and produces a report, but takes no write actions (no merges, no closes, no pushes). Safe to run unattended earlier than L2, because a report-only loop's worst failure mode is a bad report, not a bad action.

  • Audit categories that matter: Configuration, Structure, Skills, Documentation.
  • Readiness check: loop-engine audit --suggest scores >= 60/115 with no fail status in Configuration/Structure/Skills.
  • Registry mapping: patterns with readiness_level: L1 in loop_engine/patterns/registry.yaml (daily-triage, changelog-drafter, post-merge-cleanup, issue-triage) are designed to stay report-only in week one - see each pattern's human_gates list for what's explicitly out of scope.

L2 - Assisted

The loop takes small, reversible write actions, but a maker/checker split is in place: the component that acts is not the same one that approves. Verification runs before anything is applied.

  • Audit categories that matter: everything from L1, plus Safety and Checkpoints (budget limits + checkpoint_preset configured in loop.yaml).
  • Readiness check: loop-engine audit --suggest scores >= 85/115, Safety and Checkpoints both pass, and budget.max_tokens is not flagged as too low for the pattern's typical action-run cost (the registry-aware suggestion in perform_audit() catches this).
  • Registry mapping: readiness_level: L2 patterns (pr-babysitter, ci-sweeper, dependency-sweeper) - all have early_exit_required: true in the registry, meaning they must bail out immediately when there's nothing actionable rather than spend budget looping.

L3 - Unattended

The loop runs without a human watching each run, on a real schedule, and you have evidence it is actually running - not just that the files exist.

  • Audit categories that matter: all of them, including the dynamic Activity category.
  • Readiness check: loop-engine audit --suggest scores >= 100/115, and the Activity category specifically is pass (score >= 8/15), which requires either a fresh loop-run-log.md (touched within the last 14 days) or a .github/workflows/*.yml with a real schedule: trigger. A loop that has never actually run cannot reach L3 no matter how complete its static configuration looks - this is the point of the Activity signal.
  • Run loop-engine init to scaffold a starter loop-run-log.md automatically; append one entry to it per run to keep this category pass over time.

Quick red flags

Stop and fix before raising a loop's level:

  • Activity category is fail (score 0) despite the loop being "in production" - the run log or scheduled workflow doesn't actually exist, so there's no evidence backing that claim.
  • budget.max_tokens in loop.yaml is below the registry's typical action-run cost for the configured pattern - runs will be cut short mid-action, which is worse than not running at all.
  • Checkpoints category is warn/fail for a pattern with early_exit_required: true in the registry - these patterns are higher-risk by design and need human oversight configured before L2.
  • Same failure appears across many consecutive loop-run-log.md entries with no progress - that's a stuck loop burning budget, not a working one.