GOAL LOOPS AND INTERVAL COMPOSITION
3. The Goal Loop: Verifiable Autonomy
3.1 The separate-evaluator architecture
The mechanism that makes a goal loop trustworthy — rather than merely convenient — is that the model doing the work and the model deciding whether the work is done are different instances, often different model classes entirely (a smaller, faster model such as Haiku typically serves as the evaluator). After each turn, the transcript and the stated condition are passed to this evaluator, which answers one question: is the condition met? A “no” returns a reason, which becomes the instruction for the next turn; a “yes” clears the loop.
This separation exists for the same reason peer review exists in any engineering organization: a single actor grading its own work is subject to confirmation bias and will converge on “looks done” rather than “is done.” Splitting execution from judgment is the architectural primitive that everything else in this builds on — it recurs at the orchestration level (Section 5), at the self-improvement level (Section 8), and in the governance controls an enterprise reviewer will actually ask about (Section 9).
3.2 The one constraint that governs condition design
The evaluator can only read the transcript — it cannot execute commands, inspect files, or run tests itself. This single constraint dictates the entire craft of writing a usable condition: the condition must describe an observable end state, and the work itself must print its own proof into the conversation.
A condition like “clean up this file” or “improve the test coverage” gives the evaluator nothing concrete to check, so the loop either spins indefinitely or the evaluator hallucinates completion. A condition like “npm test exits 0 with no failures in test/auth, and npm run lint is clean” succeeds because the proof — the command’s output — lands directly in the transcript.
A well-formed condition has four components, and treating this as a checklist materially improves reliability in practice:
| Component | Purpose | Example |
|---|---|---|
| End state | The measurable result being targeted | “all tests in test/auth pass” |
| Stated check | The command that produces the proof | “run pytest test/auth -q and show output” |
| Constraints | What must not change in pursuit of the goal | “do not touch the schema or migrations” |
| Cap | The circuit-breaker | “stop after 20 turns and summarize” |
Goal-conditioned execution is not limited to “make the tests pass.” Any target for which a runnable check exists is a candidate: type-checking after a refactor, coverage thresholds on a specific module, latency budgets surfaced by a load-test report, reproduction-then-fix of a reported bug, removal of every reference to a deprecated API, or invariants over a structured data file. The unifying requirement is always the same — if you cannot name the command whose output flips from “no” to “yes,” the goal is not yet ready to run unattended.
A recurring failure mode worth naming explicitly: the cheapest way for a model to satisfy a check is often to weaken the check rather than do the work — deleting a failing test, stubbing a call site, or narrowing scope quietly. Conditions should include explicit negative constraints (“no call site is deleted or stubbed to achieve this”) specifically to close that path.
4. Interval Loops and Composition
Where a goal loop has a finish line, an interval loop has a clock. It re-runs a body of work on a schedule or in response to a trigger, with no notion of “done” — it is designed for standing, continuous concerns: watching a deployment, polling for new work, or running a recurring maintenance chore.
The architecturally important point is that cadence and completion are independent concerns that compose. A production pattern is a scheduled trigger whose body is itself goal-bounded: the schedule decides when a cycle starts, and the goal decides when that cycle is finished. Conflating the two produces two predictable and expensive failures: a continuously re-firing interval loop wrapped around already-finished work burns budget forever on the clock, while a goal condition applied to genuinely open-ended monitoring work never terminates because no state exists that would satisfy it.