Goal vs Loop

June 30, 2026 · View on GitHub

Goals and loops solve different problems. Using the wrong primitive creates either endless chat or endless cron noise.

Summary

DimensionGoal (/goal)Loop (/loop)
Unit of workOne bounded objectiveRecurring discovery + action
Stop conditionVerifiable completionHuman cancels or task expires
CadenceContinuous until doneInterval (5m, 1d, …)
Primary stateGOAL.mdSTATE.md, LOOP.md
Agent telemetryupdate_goalState file append + optional run log
Best metaphorSprint to finish lineHeartbeat / watchman

Decision Tree

Do you know what "done" looks like?
├─ No  → Plan mode or exploratory session first
└─ Yes → Is the work recurring on a schedule?
         ├─ Yes → Loop (/loop or scheduler_create)
         └─ No  → Goal (/goal)

Production setups often use both. Loop Engineering v1.5.0 ships the discovery layer (loop-sync, loop-constraints, MCP server); this repo ships the finish layer (/goal, goal-verifier). Full day rhythm: stack-cookbook.md.

# Morning: loop triage (loop-engineering)
npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok

# Afternoon: finish top item (goal-engineering)
npx @cobusgreyling/goal init . --pattern fix-bug --tool grok
  1. Loop runs daily triage → writes priorities to STATE.md
  2. Human or loop picks top item → /goal for run-until-done execution
  3. Goal completes → loop's next run picks the next item

Example handoff prompt:

/goal Read STATE.md top priority item #1241. Fix the flaky auth test.
Done when CI is green on main and GOAL.md records the fix. Use goal-verifier before completed: true.

Anti-patterns

Anti-patternWhy it failsFix
/goal with no done conditionAgent declares victory earlyAdd tests, checklist, or verifier skill
/loop for one-off migrationWastes schedule slots; partial work each runUse /goal until migration completes
Goal without external stateContext compaction loses progressMaintain GOAL.md
Loop without state spineSame triage every run, no memorySTATE.md + skills

Cross-reference