Skip to content
Recent Articles
4/5 - When Done Actually Means Done: Loop Engineering for Long-Running Agents
8 min · readRECENT ARTICLES

4/5 - When Done Actually Means Done: Loop Engineering for Long-Running Agents

#Loop Engineering #AI Agents #Workflow Orchestration #Agent Reliability
Abhishek Kumar
Abhishek Kumar

Most agents are built around a loop. The model receives context, proposes a response or tool call, the runtime executes the tool, the result returns to context, and the model gets another turn. The loop is short. Knowing when to run it, what counts as progress, and when to stop is not.

Loop engineering begins when a human no longer writes every next prompt. A schedule, event, queue, or goal starts the run. The system can execute many turns and perhaps several helpers before a person returns. That is useful, but it changes the core contract. “The model said it was finished” is an observation. It is not proof that the work is finished.

The mental model: a finite control system

A long-running loop needs a goal, a definition of success, an action budget, a progress signal, and a stop policy. It also needs durable state so a restart resumes from a known checkpoint rather than redoing unknown work. This is closer to a workflow controller than to a chat transcript.

The autonomous loopLoop engineering turns repeated model calls into a finite, observable, and resumable workflow.
The autonomous loop
A loop should make progress visible, keep its budget finite, and let an independent check decide whether the goal is complete.
Goal and successDefine the desired state and an observable completion predicate
Plan next stepChoose one bounded action from current state and evidence
ActCall a model, tool, or specialist with a remaining deadline
ObserveRecord result, cost, errors, and state changes
Verify progressCompare the new state with the goal and previous checkpoint
DecideStop, pause, retry, revise, or continue under budget
A new iteration is allowed only when the state changed or a bounded recovery policy explicitly permits it.
Autonomy is not the absence of a human prompt; it is a controlled system for producing and verifying the next state.
Loop engineering turns repeated model calls into a finite, observable, and resumable workflow.

Description: The return path is deliberately conditional. If a turn produces no state change, repeating it should require a reason and a decreasing budget. Otherwise the loop can pay repeatedly for the same call while reporting activity as progress.

Define completion before autonomy

A goal should be written as a state transition, not a mood. “Improve the service” is not directly verifiable. “The test suite passes, the error budget is unchanged, the deployment has the target digest, and the smoke check returns 200” is much closer. The completion predicate may combine deterministic checks and a human approval. Record the predicate version with the run so a future policy change does not rewrite history.

There are at least three different stops: success, safe pause, and failure. Success means the goal predicate passed. Pause means the system lacks authority, budget, or information and can resume safely. Failure means continuing automatically is unsafe or unlikely to help. A cancelled run should be distinct from both. These states make the operator UI meaningful and prevent a timeout from being reported as a successful completion.

Budgets are control surfaces

Set a maximum number of turns, maximum wall time, maximum input and output tokens, maximum tool calls, maximum spend, and maximum parallel work. Use one overall deadline and pass the remaining time to each child operation. A per-call timeout of five minutes does not make a run safe if the loop can execute one hundred calls.

Use a progress ledger. Each iteration should record the state hash, planned action, observed effect, verifier result, and cost. A no-progress detector can flag repeated state hashes, identical tool arguments, alternating states, or an error class that never changes. A detector is not a substitute for verification, but it is a valuable brake against a doom loop.

A loop should earn its next iterationA controlled loop makes every iteration pay for itself with progress, evidence, or an intentionally bounded recovery action.
A loop should earn its next iteration
Every turn consumes budget and must produce either verified progress or an explicitly bounded recovery attempt.
1 · TriggerSchedule, event, or user goalCreate run and deadlineLoad durable checkpoint
2 · PlanSelect next actionEstimate cost and riskCheck available capability
3 · ExecuteCall model or toolCapture output and errorsEnforce timeout and scope
4 · VerifyRun deterministic checksCompare state and evidenceClassify pass or no progress
5 · Stop or continueComplete, pause, or failConsume remaining budgetCheckpoint before retry
No state change means the default action is to stop or pause, not to repeat forever.
Operator rule
Make the run explainable: goal, current state, next action, remaining budget, last evidence, and exact reason for continuing.
A controlled loop makes every iteration pay for itself with progress, evidence, or an intentionally bounded recovery action.

Context rot and the doom loop

Long runs accumulate their own history. Earlier plans become stale, tool output crowds out the goal, and the model starts optimizing for the most recent text rather than the actual state. This is context rot. A doom loop is the operational form: the agent repeatedly calls the same tool, applies and reverts the same change, or keeps asking for information that cannot exist.

The remedy is not always another prompt. Compact state at checkpoints, keep durable artifacts outside the context window, re-read authoritative sources, and make the verifier’s result prominent. Use a fresh context when the working set is no longer legible, but preserve a structured handoff: goal, facts, decisions, open risks, changed artifacts, and last verification.

Failure modes and brakes

The tempting design is to add a larger turn cap whenever the agent fails to finish. That increases cost while hiding the actual defect. A better design has separate brakes for repeated calls, repeated state, rising failure rate, tool latency, budget exhaustion, and missing authority. Each brake should say whether to retry, pause for a person, switch to a fallback, or terminate.

The loop needs brakes before it needs autonomyA loop is safe when it can stop for success, pause for uncertainty, and fail closed when progress disappears.
The loop needs brakes before it needs autonomy
Long-running execution fails when activity is mistaken for progress or when recovery has no bound.
The loop cannot prove that the last turn advanced the goalThe model reports completion, repeats an action, or changes state without a verified improvement
Premature stopAgent says doneAcceptance check still fails
Doom loopSame state and argumentsTokens and time keep rising
Runaway scopeMore tools or agents spawnCost and blast radius expand
Containment and recoveryPause on no progress, checkpoint state, require a bounded human decision, and resume only with a new hypothesis or verified evidence.
A completion check must be independent enough to catch a confident but incorrect stop.
A loop is safe when it can stop for success, pause for uncertainty, and fail closed when progress disappears.

Parallelism is not free

Parallel sub-agents can reduce elapsed time when work is independent, but they increase coordination, context assembly, cost, and failure surface. Give each child a scoped goal and output contract. The parent must reconcile outputs, detect contradictory evidence, and remain responsible for completion. “Five agents finished” is not the same as “the task passed.”

Use a work queue when the number of tasks is dynamic. Make leases, retries, cancellation, and ownership explicit. A worker that is alive but has lost its lease should not continue mutating shared state. A parent that has timed out should cancel or quarantine its children rather than leaving orphan work behind.

A production recipe

Start with a single loop and a deterministic completion check. Add pause and resume before adding more turns. Then test timeout after a side effect, worker restart between action and receipt, stale context, repeated tool errors, a verifier outage, and a goal that is impossible under the available tools. Observe queue age, turn count, cost, state changes, verifier outcomes, and stop reason. Make stop reason a first-class field in the run record.

For a code change, the run might stop when tests pass, the diff is clean, and a reviewer approves. For a data pipeline, it might stop when the expected partition exists, row counts match, and a quality check passes. For a research task, completion may require a human because “good enough” is a judgment. The engineering is to make that judgment explicit instead of hoping the model guesses it.

Primary references

The takeaway

Loop engineering is the discipline of making repeated work finite and accountable. Define success before the run, preserve state, spend a bounded budget, detect no progress, and verify completion independently. Autonomy is not measured by how long an agent keeps working. It is measured by how reliably the system reaches a true, observable state and stops there.

3/5 - The Agent's Operating System: Harness Engineering Without the Hype5/5 - Four Layers, One Agent System: Choosing the Right Engineering Lever