An agent loop repeatedly asks a model for the next action, executes an allowed action and returns the observation for the next decision. The loop ends when the task is complete or another stop condition applies.
The surrounding application owns that loop. It decides which tools are available, which requests are authorised and how much work the agent may perform.
Follow the decision, action and observation cycle
A basic cycle has five stages:
- Assemble the goal, relevant state and available tools.
- Ask the model for a final response or proposed action.
- Validate and authorise the proposed action.
- Execute it and record the result.
- Update state and decide whether another step is allowed.
A failed tool call is still an observation. It should report a meaningful status so the next step can distinguish a temporary failure from a definitive result.
The ReAct paper studied interleaving reasoning and actions. Production systems need not expose private reasoning to use an action observation loop. Tool requests, observations and state transitions provide observable execution evidence.
The loop below separates the model’s proposal from the application’s decision to act. Each return through the loop uses the tool observation from the previous step.
ReAct and plan and execute designs
A reactive design chooses the next step after each observation. This can adapt well when a lookup reveals new information, but repeated local decisions can also drift from the original goal.
A plan and execute design first proposes a sequence or set of milestones. Execution then follows and revises that plan as needed. The plan helps organise work, but it can become stale when an assumption fails.
Neither design removes the need for checks. A plan is a proposal, and each consequential action still requires current authorisation and valid arguments.
Define completion outside the final sentence
“Done” is not sufficient evidence that a task succeeded. A document task might require a saved file at the requested location. An account task might require an authoritative service to confirm the expected state.
Define the completion condition before starting. If the task is informational, the condition may be a supported answer with required sources. If it changes state, include a verifiable postcondition.
A model can propose that completion has been reached. The application or evaluator should check the conditions it can verify.
Enforce budgets across the whole run
Set limits for iterations, elapsed time, tokens or spend, and consequential actions. Nested workers must consume a shared allowance or explicitly allocated portions of it.
Before dispatching work, check the remaining budget and reserve enough for expected completion. Reconcile estimated usage with actual usage afterwards. A check performed only after an expensive call cannot prevent that call from exceeding the budget.
Record the stop reason as a distinct value such as completed, deadline, budget_exceeded, cancelled, approval_required or failed. These states support different recovery and user messages.
Detect repeated work without blocking legitimate progress
A repeat detector can compare a tool name, normalised arguments and relevant state. Repeating an unchanged failing query may indicate a loop.
Some repetition is legitimate. Polling a job or rechecking a changed record can be necessary. Use elapsed time, state changes and retry rules to distinguish progress from repetition.
A deadline should apply to tool execution as well as model calls. When cancellation occurs, stop scheduling new work and handle any in flight side effects explicitly.
Test a loop under failure conditions
Simulate an unavailable tool, an invalid argument, an approval pause, an output limit and a task that cannot be completed. Verify that each run stops with a useful reason and an accurate account of completed work.
Measure final success together with action count and resource use. A loop that eventually succeeds after dozens of avoidable calls may still fail the product's requirements. See agent evaluation for assessing both outcomes and trajectories.