Key takeaways
Agent iteration is a controlled observe, decide, act, and observe cycle. Bounded goals, state, budgets, traces, evals, approval gates, and stop conditions keep that cycle under control. Every run needs an explicit outcome: success, stop, or handoff.
What is agent looping and how does it work?
Agent looping is repeated model execution through tools until the task finishes or reaches a stopping condition. In a basic AI agent loop, a large language model chooses a tool, receives the result, and uses that observation to decide what happens next. The cycle is straightforward: perceive, reason, act through a tool, observe the result, then decide whether to continue.
That persistence is the practical difference between a single response and an agent. A chatbot responds in one pass, while an agent persists across multiple steps. It can perceive, reason, act, and observe before choosing another step. Iteration in AI means one pass through that continuing cycle. Each pass changes the state available to the following pass.
For example, an agent may decide that it needs a tool result, invoke the tool, observe what came back, and then choose whether the task is complete. If the result does not complete the task, another iteration begins. If a stopping condition has been reached, the loop ends instead.
That answers what agent iteration is at the execution level, but repeated execution alone is not enough. A useful agent harness has to make every pass visible to the operator. Without that record, the model may continue acting while the person responsible for the system cannot see what changed or why another action was allowed.
The decision at the end of a pass is as important as the tool call inside it. A loop can continue toward the goal, stop at a declared condition, or hand control to a person. Those outcomes make iteration different from simply asking the model to try again. The cycle carries an observed result into a new decision, and that decision determines whether another pass is allowed.
Write the cycle as a contract: observe the current state, decide on an action, act through a tool, observe its result, and apply the stopping condition. This makes the control question visible at every pass. The model chooses what to do, but the surrounding loop determines whether the run continues.
Make every agent iteration inspectable
Start each pass with a declared plan and end it with a declared decision. In a plan-act-verify loop, the agent states its intended step, executes tools, and receives an independent check before another iteration. Six state fields keep that pass inspectable.
| State field | What happened | Control check | Next decision |
|---|---|---|---|
| Intended step | The agent stated the step it planned to take. | Is the step inside the bounded goal, tool scope, and any approval gate? | Act through the allowed tool, stop, or hand off. |
| Observed tool result | The tool returned a result for the recorded call and arguments. | Is the returned result present in the run record? | Send the result to independent verification. |
| Verification result | A separate check graded what happened in the run. | Does the check allow another iteration? | Continue only after the check, or stop at a defined condition. |
| Loop trace | The record connects model reasoning, tool call, arguments, result, and interpretation. | Can the operator trace the decision through the recorded sequence? | Use the trace to inspect the run or evaluate a change. |
| Budget and retry status | The record shows execution caps, retry limits, and token monitoring. | Has a cap, retry limit, or cost threshold been crossed? | Continue within the limit, alert a human, or stop. |
| Continue, stop, or handoff decision | The run reached a declared exit decision. | Was there an answer, satisfied done condition, approval need, exhausted budget, repeated failure, safety denial, or unavailable tool with no safe fallback? | Continue, stop, or transfer control. |
What should happen when a tool call fails?
A failed tool call should return useful error context to the model, but it should not open an unlimited retry path. The harness can feed the tool error back to the model and let it retry. The new iteration then has the failure available as part of its state.
The retry path is short and explicit:
- Return the tool error to the model.
- Let the model retry within a defined cap.
- At the retry cap, stop and report the attempted action, the failure, and the resulting state.
The cap is what prevents a permanently failing call from becoming an infinite loop. There is no universal retry count in this design. The relevant control is a declared limit that the runtime can enforce and expose in the iteration record.
At the cap, the failure should remain legible. The stop record can say what the agent tried, what failed, and where the run ended. That gives the operator a bounded failure instead of a loop that keeps consuming attempts without changing its exit decision.
This recovery path also keeps retry logic separate from task completion. Feeding back an error creates another chance to act. It does not itself establish that the task has succeeded. Verification and stop conditions still decide whether the run can proceed.
A retry therefore has two pieces of state: the error returned from the failed tool call and the number of attempts still allowed. The model receives the error as context for another attempt. The harness enforces the cap around that attempt. Keeping both visible prevents the model's choice to retry from silently becoming permission to retry forever.
The stop report is part of the recovery path, not an afterthought. It preserves the action the agent attempted, the failure it received, and the resulting state at the end of the bounded run. A person or another control can inspect that state without guessing which attempt ended the loop.
Claude Code hooks can gate completion and lint edits
A Claude Code agent loop offers two concrete places to apply checks. A Stop hook can run a test suite and block completion, while a PostToolUse hook can lint after each edit.
These hooks sit at different points in the work. PostToolUse can run after an edit, which puts a lint check close to the tool action that changed the code. A Stop hook can run when Claude Code is about to finish, which lets a test suite gate that completion point.
These behaviors are specific to Claude Code. PostToolUse places a lint check at an edit boundary, and Stop places a test-suite check at the proposed completion boundary. That gives the Claude Code loop a check close to the event it governs, while preserving the different roles of editing and completion.
Human oversight belongs at defined risk and failure boundaries
Human oversight should be tied to conditions the harness can recognize. An agent can transfer control when it cannot complete a task, and retry or action limits can set the failure threshold that triggers that transfer. This makes handoff a declared loop outcome, not an improvised response after repeated failure.
The first boundary is inability to complete the task. A human-intervention mechanism allows the agent to transfer control, while retry and action limits can define when escalation occurs. The state record should therefore show the limit and the handoff decision together. When the threshold is crossed, the runtime has a reason to stop acting and return control.
The second boundary is the nature of the action. Sensitive, irreversible, or high-stakes actions should trigger human oversight until confidence in the agent's reliability grows. This is a different control from a retry cap. A tool call can work exactly as invoked and still sit behind an approval gate because of its consequence, reversibility, or stakes.
Early oversight also helps contain bad state. One bad decision in an autonomous workflow can change the context for the next step. It can feed incorrect data into later steps, which makes the original cause harder to identify. A handoff boundary limits how far that altered context can travel before a person reviews the decision.
This does not mean inserting a person into every routine step. It means defining where the run must stop or transfer control. A failure threshold can be tied to attempts or actions. An approval gate can be tied to sensitive, irreversible, or high-stakes work. The iteration record then shows which boundary fired and the state being handed over.
The operator receives something more useful than a generic request for help: the intended action, observed result, verification, trace, remaining budget, and reason for handoff. Those fields do not decide the issue for the person. They preserve the path that produced it.
The handoff rule should be visible before the run reaches it. Retry and action limits can define a failure threshold. Approval gates can hold sensitive, irreversible, or high-stakes actions for oversight. The agent can then transfer control with the current run state when it cannot complete the task, rather than continuing without a defined boundary.
This allocation keeps oversight connected to consequence and failure. Routine actions can remain inside the bounded loop, while named risk conditions and exhausted limits move control to a person. The system still records the reason for that move, so the human checkpoint begins from the trace and resulting state instead of an unexplained interruption.
A Microsoft workflow turns agent outputs into a typed decision
Microsoft Agent Framework provides a specific example of iteration ending in either automated progress or human review. In its fraud workflow, three specialized agents analyze usage, location, and billing data. Their outputs become an aggregated typed risk assessment. The workflow then auto-clears low risk or routes high risk to a human checkpoint.
The example shows a clear control path. Separate analyses produce inputs to one typed assessment, and that assessment determines which of two defined routes the workflow takes. Low risk follows the auto-clear route. High risk reaches the human checkpoint. The typed result gives the routing decision a structured object instead of leaving the boundary implicit in free-form output.
The same Microsoft framework example also uses checkpointed execution. A checkpointed runtime can restart a failed agent or executor node without rerunning completed steps. The recovery point is the failed node, while earlier completed work remains completed.
This example is scoped to Microsoft Agent Framework. It does not establish that every framework offers the same checkpoint or routing behavior. Its value is concrete: it connects specialized agent outputs, a typed assessment, explicit auto-clear and human-review paths, and restart behavior inside one named workflow.
That is what a worked iteration example should expose. You can see the inputs to the decision, the form of the decision, the boundary between automated action and human control, and the state from which failed execution resumes.
Agent improvement connects traces to the next harness change
Iteration also applies to the harness itself. An agent-improvement loop can connect behavioral traces, human judgment, evals, ranked harness changes, and implementation of the next pass. The run trace supplies observed behavior. Human judgment and evals assess it. Candidate harness changes can then be ranked before one is implemented for another pass.
This is where operational records become development inputs. A trace preserves what the model did, which tools it called, and what came back. Evals can turn observed failures into test cases, help prevent regressions, and replace guesswork with metrics. A later change can be checked against the run behavior that motivated it instead of relying only on a final answer.
The improvement pass begins with behavior, not an abstract wish to make the agent better. A trace records the trajectory that occurred. Human judgment supplies a view of that behavior. Evals turn the relevant failures into repeatable checks, and ranked harness changes create an order for what to alter. The chosen change is then implemented in the next pass.
The evaluator-optimizer pattern is useful when you need to reason about that feedback relationship. Evaluation is not merely a score attached at the end. In an improvement loop, it helps connect a recorded trajectory to the next ranked change in prompts, tools, orchestration, or another part of the harness.
There is also a restraint built into this approach. Agentic complexity should be added only when simpler prompts and comprehensive evaluation are insufficient. More loops, agents, and control paths create more behavior to inspect. A simpler prompt remains the right starting point when it can do the task under comprehensive evaluation.
When an agentic loop is justified, improvement should follow the same control posture as execution. Record behavior, apply human judgment, evaluate the run, rank possible harness changes, implement the chosen change, and test the next pass. That chain keeps system change connected to observed behavior.
The improvement chain keeps behavioral traces beside human judgment and eval results. It connects a proposed harness change to observed agent behavior, then sends the implemented change through another evaluated pass. That pass can confirm a change or expose a regression.
Start with one bounded task. Use the six-field iteration-state table for a complete run, then inspect whether its verification, retry limit, budget, stop condition, and handoff rule are visible. Use the loop engineering guide to shape those controls before increasing the loop's autonomy.