The Agent Loop

The loop in one picture.

The loop has four positions. The model and the harness alternate; the environment sits outside, touched only through tools.

                 ┌─────────────────────────────────────┐
                 │                                     │
                 ▼                                     │
        ┌──────────────────┐                           │
        │   1. MODEL CALL  │   harness sends: goal +    │
        │  (the "reason")  │   full history so far      │
        └────────┬─────────┘                           │
                 │ model emits ONE of:                 │
                 │   (a) a tool call                   │
                 │   (b) a final answer                │
                 ▼                                     │
        ┌──────────────────┐                           │
        │  2. BRANCH        │                          │
        │  tool call? ──────┼── final answer ──► STOP  │
        └────────┬─────────┘                           │
                 │ yes, a tool call                    │
                 ▼                                     │
        ┌──────────────────┐                           │
        │  3. ACT           │  harness executes the    │
        │  run the tool     │  requested tool against  │
        │                   │  the ENVIRONMENT         │
        └────────┬─────────┘                           │
                 │ tool returns a result               │
                 ▼                                     │
        ┌──────────────────┐                           │
        │  4. OBSERVE       │  harness appends the     │
        │  feed result back │  result to the history ──┘
        └──────────────────┘  (now loop again)

Read it as a sentence: the model reasons about the goal and decides on one action; the harness performs that action against the environment; the result is appended to the history; the model reasons again with that new information. Repeat until the model produces a final answer instead of a tool call, or a guardrail stops it.

What the model actually emits — and who runs the tool.

A subtle point that trips up almost everyone new to agents: the model never runs the tool itself. The model only emits a structured request — "I would like to call get_weather with city="Berlin"". It is the harness (your code) that decides whether to honor that request, executes it, and reports back. The model is the brain; the harness is the hands and the gatekeeper.

Concretely, one turn of the loop looks like this on the wire:

# Turn N: harness → model (the request)
messages = [
  {"role": "user",      "content": "What's the weather in Berlin, in Fahrenheit?"},
  # ... any prior turns/tool results would be here ...
]
tools = [{"name": "get_weather", "input_schema": {...}}]

# Turn N: model → harness (it asks for a tool, does NOT run it)
{ "type": "tool_use", "name": "get_weather",
  "input": { "city": "Berlin", "units": "metric" } }

# Turn N: harness runs the real function, then appends the result
result = get_weather(city="Berlin", units="metric")   # → 14°C
messages.append({"role": "tool",
                 "content": '{"temp_c": 14}'})

# Turn N+1: harness calls the model AGAIN with the result attached.
# Model now reasons: "14°C is 57°F. The user wanted Fahrenheit and
# asked nothing else." → emits a FINAL answer, no tool call → STOP.

Three things to lock in. First, a tool result re-enters as just more conversation — the model "observes" by reading text appended to its context, exactly like a new user message. Second, the model decided to convert °C to °F itself; tools handle what the model can't do reliably, the model handles the reasoning glue. Third, the loop ended because the model chose to answer instead of calling another tool — nobody told it the task was done; it decided.

How the loop knows to stop.

Termination is where naïve agents go wrong, so it deserves its own treatment. There are exactly four ways a well-built loop ends, and a robust agent has all four:

• Natural completion. The model emits a final answer with no tool call. This is the intended exit: the model has judged the goal satisfied. It is also the least reliable on its own, which is why the other three exist.
• Step budget. The harness counts iterations and hard-stops at, say, 20. This is the seatbelt against infinite loops. It does not care whether the model thinks it's done; it just refuses to call the model a 21st time.
• Resource budget. A ceiling on tokens, wall-clock time, or money spent. A loop that's making no progress still burns context on every turn (recall: context is the most expensive thing an agent consumes), so a cost cap is a safety mechanism, not just an accounting one.
• Guardrail / human gate. An external check fires — a tool returned a forbidden action, a policy filter tripped, or a step requires human approval and none was given. The loop halts and hands off.

Why the loop is so powerful — and so failure-prone.

The loop's power is compounding: each step's decision is informed by the actual result of every prior step, so the agent can recover from a wrong turn, react to a surprising error, and find a path no one scripted. A workflow with fixed branches cannot do this; the moment reality deviates from the flowchart, it's stuck. The loop's whole value is that it does not need the flowchart.

That same property is the source of its characteristic failures, and naming them now pays off in the later "where agents fail" entry:

• Looping / no progress. The model keeps acting but the state isn't advancing toward the goal — the classic "stuck in a loop." The step budget contains it; good observation design prevents it.
• Goal drift. Over many turns the accumulated context buries the original objective, and the model starts optimizing something subtly different from what was asked. Long loops drift more; restating the goal periodically helps.
• Error cascades. One bad observation (a misleading tool result) leads to a wrong decision, which produces a worse observation, and the loop amplifies its own mistake instead of correcting it.
• Over-acting. The model takes a consequential action (deletes, sends, pays) that a human would have paused on, because nothing in the loop forced a pause. This is why the human-in-the-loop dial, covered separately, exists.

Hold the structure firmly: reason → act → observe → repeat, with explicit stop conditions. Every architecture later in this wiki — ReAct, plan-and-execute, multi-agent systems, reflection loops — is this same skeleton with one part elaborated. If you can trace a tool call from the model's emission, through the harness, into the environment, and back into context as an observation, you understand the engine of agentic AI. The rest is tuning.