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.
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 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
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.
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
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.