An agent loop repeats a small sequence: assemble the current state, ask the model for the next proposal, validate it, execute an allowed action, and record the observation.
state -> model proposal -> policy checks -> action -> observation -> new state
The loop belongs to application code. A model can propose that the task is complete, but the application decides whether the proposal satisfies the completion rule.
- Observe
Read the goal, constraints, and current state before proposing another action.
- Decide
The model proposes one bounded next step. A proposal grants no permission.
- Act
Application code validates and authorizes the tool call before it executes.
- Record and stop
Record the result and update state. Stop on completion, exhausted budget, or policy; otherwise observe again.
A model proposes the next step. Application code controls authority, state, budgets, and when the loop stops.
How to read this model
A four-position indexing table with a guarded stop lever. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
State makes the loop inspectable
Store the information that the next step needs in a structured state object. Do not force the model to reconstruct progress from prose.
type AgentState = {
goal: string;
step: number;
completed: string[];
observations: Observation[];
remainingBudgetCents: number;
status: 'running' | 'waiting_for_approval' | 'completed' | 'failed';
};
The conversation can remain useful context, but it should not be the only execution record.
A proposal has several possible outcomes
The model may propose:
- A tool call
- A request for missing information
- A request for approval
- A delegation
- A final answer
- A declaration that the task cannot be completed
Represent these outcomes explicitly. Free-form text followed by string matching is a fragile control protocol.
Stop conditions belong outside the model
Every loop needs hard limits:
- Maximum iterations
- Maximum elapsed time
- Token and monetary budgets
- Maximum repeated action count
- Cancellation
- A terminal success or failure state
A model instruction such as “do not loop forever” is not an execution limit.
Detect no progress
Two calls may differ in wording while repeating the same action. Compare normalized tool names and arguments, state changes, and new evidence. If the same proposal produces no new observation several times, stop or ask for help.
The limit depends on the task. A polling tool may repeat legitimately when it has a delay and a known terminal condition. A database lookup repeated with identical arguments usually does not.
Verify before declaring success
Completion should depend on observable state. A coding agent should run the requested tests and inspect their exit status. A ticketing agent should receive the created ticket identifier. An operations agent should check the service health signal after a remediation.
The model's statement that an action succeeded is not evidence that the environment changed.