Foundations
MDX
The Agent Loop: Observe, Decide, Act, Repeat
The control cycle behind most tool-using AI agents, from initial goal to a verified stopping point.
Editorial review: clarity, operational relevance, safety boundaries, and source quality.
Observe
The loop begins with a representation of the current state: the user goal, prior messages, tool results, stored facts, and remaining limits. Poor state representation causes the agent to reason from incomplete or stale information.
State should be compact and decision-relevant. Preserve the goal, confirmed facts, open questions, prior actions, and remaining limits; summarize or discard conversational material that no longer affects the task. Each observation should include source, timestamp, and status so stale or failed calls do not look like current facts.
Decide and act
The model chooses a next action, such as calling a search tool, updating a record, or returning an answer. The application validates the request, executes the allowed action, and returns a structured observation.
Tool calls should be treated as proposed commands. The runtime checks their schema, the user's permission, and task state before execution, then returns a structured result. Expected failures—no record, rate limit, ambiguous match—should be modeled explicitly because they teach the agent whether to retry, choose another path, or escalate.
Stop deliberately
A reliable loop has explicit completion, failure, escalation, time, and budget conditions. Without them, an agent can repeat unproductive actions or declare success without evidence.
Stopping requires evidence. Completion means the declared success condition is satisfied, not merely that the model has produced an answer. Separate terminal states such as completed, needs input, denied, exhausted, and failed. Operators can then distinguish a healthy escalation from an actual system error.
Practical example
A loop with bounded retries
A research agent receives a company and a question. It searches approved sources, extracts claims, and checks whether two independent sources support each important fact. If evidence conflicts, it revises the query once; after two unresolved attempts it returns needs_review with the conflicting passages. The loop stops on verified coverage or a defined escalation, never on the model's feeling that it has searched enough.
Field checklist
Apply it in practice
- Represent observations with source and freshness metadata.
- Validate each action before it reaches a tool.
- Set step, time, and cost budgets.
- Give every terminal state a clear meaning and owner.
Decision framework
Questions to answer before you build
A reliable loop is a state machine with probabilistic decisions inside it. The runtime—not the model—owns action validation, budgets, persistence, and terminal states.
What belongs in current state?
Keep the goal, confirmed facts, open questions, action history, and remaining limits. Remove conversational detail that no longer affects the next decision.
What counts as progress?
Define observable state changes. Repeated queries, rewritten plans, or longer explanations are activity, not progress, when the underlying task state is unchanged.
How can the loop end?
Model completed, needs-input, denied, exhausted, failed, and cancelled separately so users and operators know what should happen next.
Common failure signals
Watch for these warning signs
- Returning raw tool dumps that crowd out the goal and verified facts.
- Retrying an identical action without new evidence or a changed parameter.
- Using a maximum turn count as the only protection against unproductive loops.
Selected primary references
Continue with the source material
These sources inform the wider editorial perspective for this topic. They are not presented as line-by-line citations for every statement.