What Is an Agent Loop?
An agent loop is the control structure a running agent is built out of: a body that produces a decision, an action carried out on that decision, and a result fed back in for the next pass. The loop is ordinary program code and it belongs to the runtime rather than to the step it is calling. Everything that determines whether a run ends is a property of the loop, not of the decision inside it.
One pass, and who owns which part of it
A pass has the same shape wherever it is implemented. State is assembled into a request. A decision comes back — either an action to take or a signal that the work is complete. If it is an action, the runtime carries it out and appends the outcome to state. Then, before the next pass begins, the runtime evaluates its bounds. The two halves are worth holding apart: the decision is produced by whatever the runtime is calling, and the bound is evaluated by the runtime itself, in plain code, against counters it keeps.
That separation is the substance of the design and it is regularly collapsed. A loop whose only stopping condition is the completion signal has handed termination to the thing being bounded — and a run that has gone wrong is precisely the run least likely to announce that it is finished. Bounds are held outside for the same reason a timeout is held outside the operation it times: whatever has stopped making progress is not a reliable judge of whether it has.
What varies between loops is smaller than it looks, and it is useful to know what it is not. It is not the shape above, which is common to every implementation of the pattern. Variation is in what the body is asked to emit — free text a parser recovers an action from, a typed call against declared schemas, a plan revised on each pass — in what the runtime chooses to place into the next request, and in which bounds it keeps. Give one body different bounds and it is a different run; give different bodies the same loop and it is the same program.
| Ending | What it says about the task |
|---|---|
| Completion signal from the body | The work was declared complete. It is a claim, and nothing has verified it. |
| Step bound reached | The runtime stopped the run. The task is in whatever state the last pass left it. |
| Time or spend bound reached | The same, on a different counter, and it can fire in the middle of a run that was going well. |
| Repeat rule fired | An action recurred with identical arguments, so the runtime stopped a pass that was not advancing. |
| Unhandled error | The loop exited by a path nobody designed. State is whatever it was when the error escaped. |
| Interrupted from outside | A person or a supervising process ended it. The run has no view on the matter. |
Exactly one of these six is the task being finished; the other five are the run being over. That is the argument for recording the exit reason as a value rather than inferring it afterwards from whether output exists — a run stopped at its step bound and a run that completed both leave a transcript that ends in something that reads like a result.
Why a loop fails to end
A loop ends when a condition it checks becomes true, so non-termination is always one of two things: the condition is never evaluated, or it is evaluated and never becomes true. The first is mundane and common. A bound checked only on the branch where an action was taken, so a pass returning no action skips it. A counter incremented in one branch of the body and not the other. An inner loop inside a tool the outer bound cannot see. Bounds that live in more than one place have gaps between them, and the gap is where a run continues.
The second is the interesting case and it has a characteristic shape: oscillation. Two states, each of which leads to the other. A pass undoes what the previous pass did, the next pass restores it, and each individual decision is a reasonable response to the state it was handed. Nothing here is stuck in the sense of repeating one action, so a repeat rule that compares a pass against its immediate predecessor never fires; and a rule that compares whole states never fires either if the state includes a step counter, a timestamp or an accumulating transcript, because then no two states are ever equal. Every detector has a window, and a cycle longer than the window is invisible to it.
There is a third case that is not a failure to end but a failure to end usefully. The loop terminates because a bound fired, and the caller receives whatever the last pass produced. Unless the exit reason travels with the result, that output is indistinguishable from a finished one — and it is the shape most likely to be mistaken for an answer, because a run that stopped early returns its partial working, which looks like work. The remedy is not a better bound. It is that a result and the reason its run ended are one object, handed over together.
How the Registry classifies an iterative task run
Running a task to completion by alternating a decision step with a tool call until a stopping rule is met is filed as information retrieval in this registry's classification. The classification reads the deliverable: what such a run produces is assembled from what its calls returned, and the iteration is the machinery by which it was assembled rather than a category of its own.
The Registry's canonical brief for this entry is filed as:
Run a task to completion by alternating a decision step with a tool call until a stopping rule is met.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
abc4d2912e5a4459…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about agent loop
How many passes a task takes, which bound fires first, and whether a run that ended has actually finished are properties of a deployment and its tools, and the canonical brief above fixes none of them. This registry runs no loop on an operator's behalf and observes no pass; it issues its assessment before the first one has been taken.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about agent loop
- What is an agent loop?
- An agent loop is the control structure of a running agent: assemble state into a request, receive a decision, carry out the action, append the outcome, check the bounds, repeat. The loop is code owned by the runtime, and the step it calls is one part of one pass.
- How does an agent loop stop?
- By a completion signal from the body, by a bound on steps, time or spend, by a rule that fires when an action repeats, by an unhandled error, or by an interruption from outside. Only the first of those is the task being finished, which is why the reason a run ended is worth recording as a value.
- Why does an agent loop need a step limit?
- Because without one, termination depends entirely on the body declaring itself done, and the runs that most need stopping are the runs least likely to do that. A limit held in the runtime is checked on every pass regardless of what the body returned, which is the property that makes it a bound rather than a suggestion.
- Why does a loop repeat the same action?
- Because the action returned nothing that changed the situation, so the next pass sees a state it has already responded to and responds the same way. The related and harder case is a cycle of two or more passes, where nothing repeats immediately and a rule comparing each pass with the one before it never fires.
- What is the difference between an agent loop and a ReAct loop?
- The agent loop is the general control structure. ReAct is one named instance of it, which fixes what the body emits — a reasoning step, then an action, then an observation appended before the next pass. Change what the body emits and the loop around it is unchanged.
- Where should a loop’s bounds be checked?
- In the runtime, outside the body, on every pass and on every branch. Bounds checked only where an action was taken leave the branches that took none unbounded, and a bound duplicated across two places is two bounds with a gap between them.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.