Loop engineering basics: the agent control loop

A single LLM call answers one prompt. Many real tasks need information the model can't have until it acts — read a file, search a doc, run a calculation. The result of one action decides what to ask next. That's the loop: the model picks an action, the harness runs it, the result feeds into the next prompt, repeat.

The loop is the difference between a chatbot and an agent. A chatbot answers in one shot from prior knowledge. An agent gathers evidence, takes steps, and decides when it's done. If you can solve a task with a single prompt and no tools, skip the loop — it adds latency, cost, and failure modes for no gain.

ReAct stands for reason + act. Each iteration the model emits two things together: a brief thought ("I should check the price first") and an action (a tool call like get_price("BTC")). The harness runs the action, captures the observation, and feeds all three back into the next prompt.

You don't have to literally use the word "thought" — Claude's tool-use, OpenAI's function calling, and Google ADK's tool callbacks are all variants of this shape. The pattern is the same: a structured turn that combines reasoning and one action, external execution, then the result joins the conversation. Surfacing the thought is what makes mistakes and dead ends visible to the model next turn — without it, the model steers blind.

Each box is the model's view; each edge is something the harness or the world does.

Here's the entire control flow in pseudo-Python. Production loops add error handling and caps; the spine is this:

messages = [{"role": "user", "content": user_request}]
for step in range(MAX_STEPS):
    reply = model(messages, tools=AVAILABLE_TOOLS)
    messages.append(reply)
    if reply.stop_reason == "end_turn":
        return reply.text
    for call in reply.tool_calls:
        result = TOOLS[call.name](**call.args)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

Three moving parts: messages (the running history), tools (the dispatch table), MAX_STEPS (the hard cap). Every other loop you'll see — plan-act-reflect, sub-agents, verification panels — is this with extras stapled on.

The model signals "done" via a stop reason: end_turn for Anthropic, stop for OpenAI, or simply a turn with no tool call. That's the happy path. The unhappy path is a model that keeps calling tools forever — usually because the last observation didn't actually answer the question and it doesn't know what else to try.

Always stack three termination layers:

• Model signal — exit when the model says it's done.
• Iteration cap — MAX_STEPS = 20 (or 5, or 50; pick on purpose). Hard exit on hit.
• Token or wallclock budget — exit if cumulative usage crosses a threshold.

Production loops also detect repeats — same tool, same args, twice in a row — and exit. "I'll just trust the stop reason" is how one stuck request bills four hundred dollars in tool calls overnight.

On iteration 1 the prompt is the user's request and the tool list. On iteration N the prompt is every previous turn concatenated: assistant messages, tool calls, observations. This is the per-turn state, and it grows linearly with the number of steps.

That growth shapes the loop:

• The model loses focus when iteration-1 context is buried ten turns deep.
• Tokens add up. A 5KB observation across twelve iterations is 60KB of prompt before the model even thinks.
• Mistakes from iteration 2 still influence iteration 12.

Two practical rules: be terse in observations — don't dump a 50KB file when one line answers the question — and exit if the loop drifts (iteration 5 looks like iteration 3, you're not making progress).

Task: "What's the capital of France, in Spanish?" Available tools: lookup_capital(country) and translate(text, target_lang).

Three iterations, two tool calls, then a stop. The order is decided by the model — it could equally have used a single combined tool, or asked the user to clarify. The loop just runs whatever the model picks next. That flexibility is the agent's power, and the reason every termination layer above exists.

A loop is for tasks where step N depends on the result of step N-1. If one prompt answers the question, use one prompt. If one tool call answers it, use the model's native tool-use without looping.

Common false positives where people reach for a loop they don't need:

• Retrieval-augmented prompts — one search, one synthesis, no loop.
• Form filling / extraction — call the model once with a JSON schema, validate, done.
• Chat — the user's next message is the next iteration; you don't loop programmatically.
• Single-tool answers — "fetch this row" doesn't need a harness; just call the tool.

The loop adds latency, token cost, three new failure modes (drift, runaway, repeat), and an evaluation burden. Pay that cost only when the task structurally needs it.