The Loop Files Its Own Work

How an autonomous coding loop can discover missing work, track dependencies and verify live behavior. A hypothetical architecture with explicit authority, budgets and completion checks.

The Loop Files Its Own Work — AI

An autonomous worker can discover prerequisites that were missing from the original plan. The useful response is a controlled change to the work queue: describe the gap, record dependencies and continue only within existing authority. This article develops that design through a hypothetical monitoring workflow; it is not a report of private production results.

From request to executable scope

Suppose a team wants to detect a failed background job and notify the responsible operator. Before a worker starts, define the observable outcome, the permitted environments, the notification boundary and the evidence needed for acceptance. Break the request into tasks with dependencies, rather than assuming the first prompt contains every prerequisite.

A readiness check should distinguish an unanswered design question from an external permission boundary. Resolve what can be resolved from authorized sources. Record the remaining boundary explicitly; do not silently expand permissions to make a task easier.

The controller

# Illustrative controller: helper interfaces need an implementation.
# Oracle statuses: 0 verified complete, 1 work remains, other = verification failure.
# An external supervisor must also enforce wall-clock and spend limits.
attempt=0
while :; do
  ./done_oracle.sh "$BATCH"
  status=$?
  case "$status" in
    0) exit 0 ;;
    1) ;;
    *) printf '%s\n' 'Verification unavailable; stopping.' >&2; exit 2 ;;
  esac
  if [ "$attempt" -ge 20 ]; then
    printf '%s\n' 'Attempt budget reached; work is not complete.' >&2
    exit 6
  fi
  ticket="$(./ready_set_next.sh "$BATCH")" || exit 3
  [ -n "$ticket" ] || exit 4
  ./run_one_ticket.sh "$ticket" || exit 5
  attempt=$((attempt + 1))
done
The loop: one iteration DONE-ORACLE accepted evidence complete? yes -> EXIT SCHEDULER ready set (deps met) no fresh worker worktree - empty context fresh worker worktree - empty context fresh worker worktree - empty context code -> 2nd-model review -> merge -> deploy -> VERIFY LIVE -> tracker: Done verify accepted revision AND required live behavior re-ask the oracle

The example separates task selection, worker execution and completion checking. Its helper scripts are illustrative interfaces, not a distributed package. The controller must fail closed when it cannot obtain verification evidence. Attempt limits alone are insufficient: a supervisor also needs time and spending bounds and a reliable cancellation mechanism.

Fresh context and durable state

A fresh worker per task limits how much stale conversation is carried forward. It still needs the current specification, accepted revision, prior failure evidence and applicable constraints. One invocation can still fill its context window or compact; freshness at launch is not unlimited context.

Keep recovery state in durable, reviewable artifacts. Record which operation was attempted and inspect the external result before retrying a mutation after a crash. A second attempt must not duplicate a deployment, message or ticket.

Independent completion evidence

Tracker labels are useful coordination data, but a worker that can update a label can also claim completion. The acceptance check must inspect evidence tied to the accepted revision and required behavior through a protected verification path. Missing or inaccessible evidence means unknown, not success.

Report verified completion separately from human-gated work. A batch may have reached the limit of its automated authority while still containing unfinished tasks. That is a valid handoff, not a completed outcome.

Parallel work and review

Depth in the worker, breadth in the loop THE WORKER strongest model, max reasoning effort, one ticket, boxed parallel tickets second-model review retries verify-live scheduling + deps the oracle the harness supplies breadth so the worker can spend everything on depth

Schedule tasks whose dependencies are satisfied. Separate worktrees prevent ordinary file collisions; they do not isolate host access. Shared mutations such as infrastructure changes may require additional locks. Independent model review can find different mistakes, but agreement between models is still advisory evidence rather than proof.

When merged code has no effect

The most seductive lie in shipping software is a green merge. The pull request is approved, the checks pass, the branch goes in, and every ritual tells you it's done. But a merge is a statement about code, not about behavior. The feature can be merged and still dark: a flag gated off, a job pinned to an image built before the feature existed, a metric that nothing has emitted yet so the thing that reads it has nothing to read, a downstream step that simply hasn't run. Everything is "shipped" and nothing is happening.

"Shipped" means live, not merged code merged deployed live? effect real? DARK flag off / metric never emitted / job on a pre-feature image no loop files its own ticket adds it to the batch + dep edge, drives it to LIVE DONE behavior verified in prod yes

In the hypothetical monitoring workflow, deployment could succeed while no fresh events reach the intended destination. The next task should identify the missing prerequisite, its owner and its allowed resolution. If completing it would change access beyond the authorized scope, stop at that boundary with a concrete handoff.

An infrastructure apply shows that configuration was accepted, including whatever validation the provider performed. It does not show that fresh telemetry arrives, values are correct or alert delivery works. Test the behavior with a controlled event and inspect the destination. Keep unverified runtime checks outstanding.

Why live checks complement review

A filter can be syntactically valid and still select the wrong events. Parenthesize intended logic, test representative matching and nonmatching cases, and then verify the deployed path. No error message is not evidence that the desired behavior occurred.

Changing the controller

Self-heal: rewrite the machine, never the finish line loop about to stop self-heal pass harness gap or real wall? MAY REWRITE (root cause) loop scripts - prompts - scheduler retries - portability - resilience FROZEN - tripwire guards it the verifier / the oracle the definition of "done" weaken it -> heal rejected, stop surfaces each repair requires a reviewed change

Letting a worker propose improvements to its controller can be useful. Applying those changes should use a separate review and validation path. Keep acceptance definitions, checking code and expected hashes outside the worker’s write authority; a hash only detects change when the reference and verifier are protected.

Freezing one definition does not make self-modification generally safe. Credentials, inputs, dependencies and deployment controls also affect the effective boundary. Do not infer sandbox strength from a prompt, a worktree or a permission-bypass flag.

What to measure

Track accepted outcomes, failed checks, recoveries, intervention reasons, time and observed billing. Include false completion claims and work that remains gated. A useful system improves these measures without weakening the verification that gives them meaning.

The architecture earns trust through repeatable evidence. A worker may propose, implement and report; the surrounding system must decide what is authorized, what actually happened and what remains unfinished.