Loop Engineering

What it is

Designing the feedback system that selects work, invokes an agent, checks the resulting change, records what happened, and decides whether to revise, wait, escalate, stop, or take another item. Loop Engineering moves responsibility for the next instruction into an explicit controller. It does not make an agent's completion claim a trustworthy verdict.

The term also appears in discussions of model/tool iteration. Distinguish the inner loop within one run from the outer work loop that launches and evaluates runs. Useful feedback can improve a task without changing model weights or authorizing new objectives.

Two loops and their records

The outer controller can invoke the same agent repeatedly or several specialized workers. Scheduling is one source of wakeups; an event or an explicit user request can drive the same controller. A timer alone supplies neither a backlog policy nor a definition of successful work.

Worked example: bounded incident triage

An authorized automation inspects new incident reports for one project. It records each report as a durable item, claims an eligible item, and asks an agent to propose a classification and ticket draft. A checker validates the draft against the report and project requirements. Failures return specific issues for a bounded revision; missing evidence places the item in a waiting state rather than triggering endless redrafting.

Creation proceeds only under the configured permission and review policy. The controller stores the external ticket identifier, verifies the resulting record, and marks that item complete. A later wakeup observes the same item identity and does not create it again. Human judgment remains responsible for objectives, acceptance rules, and changes to the controller's authority; the automated cycle does not grant itself wider scope.

Controller decisions

Define item states such as eligible, claimed, running, verifying, waiting, complete, and failed. Associate each attempt with an artifact revision and criterion version. Decide how claims expire, which failures permit another attempt, and who may move blocked work back into eligibility. Retry allowances belong to the item as well as the run: spawning a fresh run must not reset the budget indefinitely.

Separate the producer from the acceptance check by authority and evidence. The checker may be deterministic code, a human, or a calibrated model using independent observations. A second model with the same unsupported assertion is not automatically independent evidence. Compare candidate loop designs on verified completed work, correction attempts, waiting time, and total cost, not on the number of runs launched.

Failure modes

• Each wakeup rediscovers the same report under a different identifier and duplicates work.
• Failed verification creates a fresh work item, bypassing the original attempt ceiling.
• The agent edits its own acceptance criteria until its output passes.
• A process dies holding a claim and nothing can reclaim or reconcile the item.
• Revisions are checked against stale requirements without recording that mismatch.
• The controller keeps polling a missing prerequisite instead of waiting for a relevant event.
• A successful run is mistaken for successful work even though the requested external effect was never verified.
• An unattended loop broadens its project scope because the backlog happened to include more items.

Related capabilities

• Execution Loop — the inner model/tool cycle
• Termination Conditions — trustworthy run endings and backstops
• Loop Detection — progress diagnosis within and across participants
• Scheduling and Event Triggers — admission and wakeup semantics
• Shared State Management — claims and authoritative progress
• Agent Harness Engineering — environment for each attempt
• Agent Graph Engineering — explicit transitions inside the controller
• Task Completion Evaluation — judging achieved work

Applies: Production readiness · Design questions