- 1Observe the environment or prior tool result
- 2Feed the result back as the next observation
- 3Select and invoke the appropriate tool or action
- 4Reason about what action to take next
- 5Execute the tool call and receive the result
Each turn of an agent loop runs in one fixed order: observe state, reason, choose and invoke a tool, execute it, then feed the result back as the next observation.
Imagine cooking a dish you have never made before. First you look at what is on the counter. Then you think about the next move. Then you pick up a tool, maybe a knife or a pan. Then you actually do the step, like chopping an onion. Then you look again to see how it turned out before deciding what comes next. An agent works the same way, round after round. It reads the situation, decides, grabs a tool, runs it, and checks the result. The order matters: it has to look before it can think, think before it can pick a tool, and run the tool before any result exists. Each round feeds the new result back in, so the next decision is based on what actually happened rather than a guess made at the very start.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An agent loop is the control structure that turns a single language model call into a multi-step problem solver. Rather than answering in one shot, the model sits inside a runtime that calls it again and again, lets it act on the world through tools, and stops only when the goal is met or a budget runs out. The model is the brain that decides; the runtime is the machinery that observes, executes, and feeds results back. Neither half is an agent on its own. The loop is the thing that joins them.
This question is about the order of the five core steps in one iteration of that loop: observe, reason, choose and invoke a tool, execute and receive the result, then feed that result back as the next observation. The order is not a stylistic choice. Each step consumes the output of the step before it, so the sequence is fixed by data dependencies. Getting the order right is the difference between describing a real agent and describing a vague act then think muddle.
A useful way to hold the order in your head is to compare it to how a careful person tackles an unfamiliar task. They look at the situation, decide what to try, reach for a tool, use it, then look again at the result before choosing their next move. The five steps below are that same instinct made mechanical and repeatable, and the rest of this explanation walks each step in turn, says why it sits where it does, and shows what breaks if you move it.
Step one: observe the current state
The loop opens with observation. The agent reads the current state, which is the running record of everything seen so far. On the very first turn that state is just the user's goal. On a later turn it is the goal plus every prior action and the result each action produced. In practice the runtime assembles this state into the model's context window: the system prompt, the original task, the conversation so far, and the most recent tool results all get packed together before the model is called.
Observation has to come first for a simple reason: the model cannot reason about a situation it has not read. The state is the only input the model gets. Whatever is in it shapes the decision that follows. A model that is shown a stale or partial state will reason about the wrong situation, no matter how good its reasoning is.
This is also why state quality matters so much. If the prior result was truncated, malformed, or missing, the observation is poor, and every step downstream inherits that weakness. It is also where long runs start to strain, because the state only grows as more action and result pairs accumulate. Teams manage this with sliding windows, summarisation of older turns, or retrieval that injects only the relevant slices, but the principle of the step does not change. Observe first, and observe accurately.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangGraph's prebuilt ReAct agent encodes this order as graph nodes: observe state, call the model to reason, route to a tool node, execute, then loop the result back to the model node.
- Claude's computer use mode observes a screenshot, reasons about the next action, emits a click or keystroke tool call, executes it, and feeds the resulting screenshot back as the next observation.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy is the feedback step the one that actually makes the system an agent rather than a chain?
Argue from data dependency: in a chain the next step is fixed at design time, but feeding the result back means the next decision is conditioned on the actual observed outcome, so the trajectory is chosen at runtime.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Putting tool execution before the reasoning step, or dropping the feedback step so the result never returns as the next observation that shapes the following decision.
60 second bullets to scan on the way to the call.
Explain why the model needs to read state before it can deliberate.
Describe what the reasoning step produces and how it gates tool selection.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.