The loop: state, goals, and stopping

At its simplest, an agent runtime repeats four operations:

1. assemble the current task state;
2. ask a model or policy to select a permitted action;
3. execute that action and record the observation;
4. test success, failure, and budget conditions.

The application owns the loop. It validates action names and arguments, invokes tools, stores results, increments counters, and decides when hard limits apply. The model proposes an action; it does not gain arbitrary access to the operating system or external services.

This separation matters during failure. If a model emits an unknown tool name, the runtime can reject it. If a network request times out, the runtime records a typed error. If the maximum step count is reached, code stops the loop even if the model asks to continue.

State is the information carried from one iteration to the next. Useful state commonly includes:

• the original goal and user constraints;
• facts already established and their sources;
• pending questions or incomplete fields;
• action and observation history;
• tool errors and retry counts;
• permissions, time, token, or money remaining;
• artifacts produced so far;
• current status and stop reason.

Not every byte belongs in every model prompt. The runtime may store a full event log while supplying a compact working state to the model. The key is that operationally important facts remain inspectable.

Do not make hidden chain-of-thought a required state field. Systems can request a short action rationale such as “search again because the primary source lacks a date,” but that rationale is an auditable justification, not a promise to expose internal reasoning. Evaluate whether the chosen action follows from observable evidence.

A goal describes the desired outcome; success criteria make completion testable. “Research three vendors” becomes:

• exactly three vendors meet the region and budget constraints;
• price, data-retention policy, and cancellation terms are present for each;
• every factual field links to a retrieved source;
• unresolved conflicts are clearly labeled;
• no purchase or outbound contact occurs.

Some checks are deterministic. Code can count vendors, verify required fields, enforce URLs, and block purchase tools. Other checks need judgment, such as whether a summary fairly represents a source. Keep exact rules in code where possible and reserve model judgment for semantic qualities.

Without completion criteria, agents often stop too early after finding plausible material or continue searching after the answer is adequate. Both failures arise from the same design gap: the system cannot distinguish “looks useful” from “done.”

Success is only one stop condition. A production loop should distinguish:

• completed: all required criteria passed;
• needs input: a missing user constraint prevents safe progress;
• needs review: a policy or consequence requires human judgment;
• budget exhausted: step, token, time, or spend limit reached;
• blocked: tools are unavailable or required evidence cannot be accessed;
• failed: repeated errors or invalid state make continuation unproductive;
• cancelled: the user or operator stopped the run.

The stop reason should be stored and shown. “Here is your answer” is misleading when the agent actually ran out of searches. A better response says which requirements were met, what remains uncertain, and why the run ended.

An invariant is a condition that must remain true throughout the run. Examples include “never send an email without approval,” “never search outside approved domains,” and “every artifact belongs to this task’s workspace.” The runtime checks invariants before or after actions.

Budgets limit variable behavior. A research agent might receive eight tool calls, 90 seconds, and a maximum estimated cost. Per-tool retry limits prevent a failing API from consuming the whole budget. A repeated-action detector can stop identical searches that produce no new evidence.

Budgets do more than control expense. They force the design to define a graceful incomplete result. When five calls produce only two qualified vendors, the correct behavior may be to return two with a visible gap, not fabricate a third.

Suppose an agent searches “venue cancellation policy,” opens the same result three times, and then declares success with the policy still missing. The trace exposes two distinct defects. Repeated actions suggest poor state summarization or no duplicate guard. False success suggests weak completion validation.

Fix the appropriate layer. Add a set of visited resources and reject duplicate opens. Add a deterministic requirement that each venue include a cancellation field or an explicit “not found” status. Simply prompting the model to “be more careful” leaves both defects implicit.

Good loop design turns vague behavior into inspectable transitions: state before, selected action, validated arguments, observation, state after, and stop test.