Agent Loop: Model Calls, Tools and Stop Conditions

The model proposes the next action. Your software decides whether that action may run, records what happened, and decides whether another model call is allowed. That division of responsibility is the starting point for a first agent and for investigating one that kept running.

The framework behavior below was verified against each maker's live documentation on 24 October 2026. The comparison normalizes what each framework counts and where its controls take effect. The support-ticket examples and suggested policies are illustrations, not measured production results.

How the Agent Loop Works

The useful loop is model call → tool call → observation → repeat, with an exit whenever continuing is unnecessary or disallowed.

Think of a dispatcher coordinating a technician. The dispatcher chooses the next job, the technician does it, and the returned work report informs the next decision. A request to inspect a machine is not the inspection itself; a reassuring message is not evidence that the repair succeeded.

In software, the dispatcher is a large language model, or LLM. The technician is a tool: a function that reads a database, searches documents, runs a command or changes a record. The surrounding runtime is the code that connects them.

For a hypothetical ticket-drafting task, the trace could be: the first model call requests the ticket; the second requests the relevant policy; the third returns a draft grounded in both. That is 3 model calls and 2 tool executions, inside one application request. If sending the reply needs approval, drafting can finish while sending remains pending.

Keep task state separate from the transcript. State should say which ticket is being handled, which policy was accepted, whether a draft exists and whether sending is authorized. The transcript explains how you got there. Repeatedly asking the model to infer all of that from a growing conversation makes the job harder to supervise.

What a Loop Agent Adds

A loop agent can choose its next action from the latest result. A fixed workflow already knows the sequence: fetch the ticket, fetch the policy, produce the draft. Use the adaptive loop when the next useful action depends on what the previous action revealed. Use the fixed sequence when that uncertainty is absent.

Where the ReAct Agent Loop Fits

The ReAct agent loop connects reasoning and action: a model uses observations to inform subsequent actions. The original ReAct project describes interleaving reasoning with actions in an environment. For application monitoring, record requested actions, observations and outcomes. A prose explanation of progress does not replace an execution receipt.

The Three Stop Conditions Every Production Loop Needs

Design three deliberate ways out: completion, exhausted limits, and required human input. These are engineering categories, not a claim that every SDK exposes the same three switches. Crashes, cancellations and unrecoverable errors also need explicit failure handling.

Stop When the Task Is Complete

Define what completion means before the first model call. For a drafting assistant, it might mean a valid draft with the relevant source references. For an action-taking assistant, it might require a confirmed write receipt as well.

Separate “the model stopped requesting tools” from “the requested job succeeded.” The former is a runtime signal. The latter needs task-specific evidence. A model can stop because it cannot proceed; your application should record that as blocked or incomplete instead of presenting it as successful work.

Do not put the loop back into motion automatically whenever an answer fails validation. A correction attempt must consume the same job's limits, or a validator can become another source of endless retries.

Stop When a Limit Is Reached

Use independent limits for steps, resource use and elapsed time. A step cap bounds repetition. A token or spend budget bounds consumption. A deadline stops a slow model or tool from holding the job open indefinitely. None substitutes for the others.

Check limits before admitting new work, and update usage after it finishes. A completed-call counter cannot prevent an already-running request from consuming resources. If the application promises a strict ceiling, reserve capacity for the next operation and account for concurrent work before starting it.

Set limits around the business job, not just an SDK invocation. A retry, a resumed approval or a child agent should not silently create a fresh allowance. If more work is justified, extend the allowance through an explicit application decision.

Pause a Human in the Loop AI Agent Before the Action

A human in the loop AI agent should pause before the operation that needs approval. Show the proposed action, its target and its relevant arguments. Save the pending call and the current job state, then wait for an explicit decision.

For the ticket assistant, approve the specific outgoing reply to the specific recipient. Approval of a draft should not become blanket permission for later messages. If the model changes the recipient or content after approval, reassess that action.

Record a pause as awaiting_approval, not completed. Rejection should lead to a defined alternative or a stop. It should not trigger repeated attempts to get the same operation through another tool. The human-in-the-loop guide covers approval queues and escalation.

A Minimal Agent Loop in Pseudocode

The loop stays small when policy checks surround each operation. This is pseudocode, not executable SDK code. The example cap of 8 model calls is an illustrative application choice; choose your own limits from the task and observed traces.

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

The helper names carry important obligations. Reservations must account for work already in flight. Tool retries must be bounded. A timeout with an unknown write outcome must stop or reconcile before retrying. A fatal model or tool error exits with a recorded failure instead of falling through to another iteration.

Saving a pause must include the remaining tool calls, completed results and consumed allowance. On resume, continue that saved work and recheck its authorization and limits. Starting the entire task again can repeat earlier effects.

Notice where the checks sit: approval is before tool execution, usage accounting follows completed work, and the next iteration cannot begin merely because the model asked for it.

How the Frameworks Expose the Loop

OpenAI Agents SDK, Claude Agent SDK, Vercel AI SDK and LangGraph package the loop differently. Compare their counting units and stopping boundaries before comparing option names.

These names come from the respective OpenAI loop docs, Claude loop docs, Vercel loop docs and LangGraph Graph API. Approval behavior is linked in each section below.

OpenAI Agents SDK: The Runner Owns Continuation

OpenAI Agents SDK is a framework whose Runner calls the model, executes requested tools, appends results and continues. A handoff switches the active agent and continues the run. The documented normal finish is output of the expected type with no tool calls; exceeding max_turns raises MaxTurnsExceeded unless handled. OpenAI running-agents documentation.

For a ticket assistant, that gives you a straightforward place to bound model turns. Its wall is the difference between a completed run and a completed business action: configure the output contract and check the evidence your task requires.

For approvals, Python tools can declare needs_approval; pending calls surface in interruptions. Save the RunState, apply the approval or rejection, and resume. A paused run is not a new user request. OpenAI human-in-the-loop documentation.

Claude Agent Loop: Set Both Turn and Spend Limits

Claude Agent SDK embeds the loop behind Claude Code, including file and command tools. Its maxTurns option counts tool-use turns; maxBudgetUsd sets an estimated-spend threshold. Both are unlimited when unset. Python uses max_turns and max_budget_usd. Claude agent-loop documentation.

Inspect the result subtype: success, error_max_turns and error_max_budget_usd are different outcomes. In single-shot mode, an error result is followed by an exception, so handle both the result and failure path. Claude result handling.

The permission boundary needs equal care. allowedTools auto-approves listed tools; omitting a tool from that list does not remove it. In the default permission mode, calls that need approval and match no allow rule reach canUseTool. Check the full permission policy before using this SDK for unattended writes. Claude permissions.

For accounting across child agents, Claude distinguishes main-loop usage from whole-tree modelUsage or Python's model_usage. Use the appropriate total when investigating a job's consumption. Claude cost and usage documentation.

Start with the site's Claude Agent SDK guide for the implementation walkthrough.

Vercel AI SDK: stopWhen Controls the Next Step

Vercel AI SDK exposes continuation through stopWhen. Its current docs use isStepCount for a step limit and allow multiple conditions, stopping when any matches. ToolLoopAgent defaults to 20 steps, while generateText and streamText default to one generation. The entry point matters. Vercel loop control, tool-calling documentation.

A step includes a generation and its local tool executions. Crucially, stopWhen is evaluated when the last step contains tool results. It cannot undo the tool work that produced those results. That makes it a continuation control, not approval before an action. Vercel multi-step calls.

Use the documented toolApproval mechanism for explicit user approval. Current docs mark the older needsApproval tool property as deprecated. Vercel tool approval.

For context management, prepareStep runs before each step and can change messages or settings. Use that boundary to provide relevant state instead of repeatedly carrying every raw result. Vercel prepareStep.

LangGraph and the LangChain Agent Loop

LangGraph is a graph runtime: you connect nodes, which perform work, with edges, which determine what runs next. For a LangChain agent loop built on a graph, make the route back to the model and the route to END explicit. Python's recursion_limit bounds graph super-steps, with parallel nodes sharing a super-step. It is not a tool-call counter. LangGraph Graph API.

Set recursion_limit at the top level of the invocation config, not inside configurable. Reaching the bound raises GraphRecursionError; a deliberate completion route should normally finish before that emergency exit. LangGraph recursion limit.

For human review, interrupt() pauses the graph. Use a checkpointer and a stable thread_id, then resume with Command(resume=...). The important wall: resumption restarts the interrupted node from its beginning. Code before the interrupt can run again. Place effects after approval or make them idempotent, meaning repeated execution has no additional effect. LangGraph interrupts.

Choose this explicit graph structure when branches and resumable state are central to the job. For a first read-only assistant with a simple tool cycle, start with the smallest runtime that meets your requirements.

Why a Run Reaches 40 Steps

Diagnose what changed between steps before raising the cap. A long run might be useful work, repeated failure, or a restart that lost track of what was already done. The number alone cannot distinguish them.

Endless Loops: Repetition Without New Evidence

A ticket agent may search for a policy, receive an empty result, and repeat the same search. The next observation adds nothing, so the next decision can reproduce the same action.

Record a normalized tool name and arguments, a result fingerprint, and a task-progress marker. Repetition with no state change should trigger a stall check. Legitimate polling can also repeat, so give polling its own bounded policy rather than treating every duplicate as an error.

Change something before retrying: a search term, a missing identifier, an available data source or the task scope. If nothing useful can change, return the unresolved requirement or ask for help. “Try again” is not a recovery strategy by itself.

Tool Errors: Separate Recoverable Failure From Unknown Outcome

A malformed argument, denied permission and transient service failure call for different responses. Return a concise error the model can act on. Bound recoverable retries and stop immediately on errors that cannot be fixed within the job's permissions.

A timeout during a write is harder: the write may have succeeded even though the reply never arrived. Before resending a customer message or creating another record, query the operation status or use an idempotency key, a stable identifier that lets the service recognize the same intended operation.

Preserve successful work during recovery. If reading the ticket succeeded but fetching the policy failed, rerunning the entire job adds work and may repeat effects that already happened.

Context Growth: Carry Decisions, Not Every Raw Byte

Every observation competes with the task instructions and earlier evidence for the next model call's attention. A large tool response can be technically valid while making the next decision less focused.

Bound tool outputs, store large artifacts outside the prompt, and return a compact result with a retrievable reference. Keep accepted constraints, approvals and confirmed actions in durable application state. A summary can describe those records; it should not become their only copy.

Claude's SDK documents automatic compaction near the context limit and warns that early instructions may be lost in the summary. That is a reason to preserve critical state deliberately. Claude compaction. The context-rot explainer covers why fitting inside a context window does not guarantee useful recall.

Make the Trace Answer the Operator's Question

For each job, record its identifier, model-call count, tool attempts, usage, elapsed time, pending approvals and stop reason. For each operation, record what was requested, what completed and whether it changed task state.

Keep separate counters for model requests, tool executions and runtime steps. A dashboard saying “40 steps” without a unit cannot explain the run. Include child work and retries in the parent job's accounting. The AI agent orchestration guide explains ownership when work crosses agents.

What Is Overhyped About Agent Loops?

More iterations do not establish more progress. A loop provides repeated opportunities to use feedback; the quality of that feedback and the definition of success determine whether repetition helps.

A model that says “done” has ended its part of the exchange. A step cap proves the run was bounded. Neither proves that a support reply is correct or that a requested change happened.

Nor does using a framework remove the need to define permissions, persistence and recovery. The framework supplies execution mechanisms. Your application supplies the meaning of success and the authority to act.

The Agent Test Loop Is a Separate Job

An agent test loop evaluates behavior against cases and acceptance criteria. It may wrap an execution loop with a checker that accepts the result or sends feedback for another attempt. LangChain's loop-engineering explanation distinguishes execution from verification and event-triggered work.

Keep the checker bounded too. Repeatedly asking another model whether an answer is good can consume the allowance without producing decisive evidence. Prefer concrete checks where possible: required fields exist, cited records match, a write receipt is present, or an expected test passes.

What Builders and Operators Should Do Next

Builders writing a first agent: begin with a narrow read-only task, an explicit completion contract and bounded operations. Add writes when you can show the proposed action, enforce authorization and recover from an ambiguous result. If the sequence is already known, a fixed workflow may be sufficient.

Operators investigating an expensive run: inspect repeated calls, retry chains and growing observations before changing the model or raising limits. Ask which step added useful evidence and which counter actually stopped the job.

Teams with a reliable fixed workflow: keep it until adaptive tool selection solves a concrete problem. A loop adds value when intermediate results determine the next action; repetition alone is not a reason to rebuild.

The Monday move: take one representative task and exercise its completion path, limit exit, approval pause, denied action and tool-failure path. Confirm that each leaves a clear status and that resuming it preserves both completed work and the remaining allowance.

Agent Loop FAQ

For practical guides to building and operating AI systems, join the newsletter.