01.01 · Concept · Free
The loop, not the model
Draw the agent loop: model, tool call, result, repeat, and say where each step can fail.
Curated for this lesson1/3
What an agent actually is
What is OpenClaw? Inside AI Agents, LLMs and the Agentic Loop
Directly targets the agentic loop, the exact mental model beginners need before implementation details.
An agent is a control loop around a model: choose an action, call a tool when needed, read the result, update context, and continue until a stop condition is met. Debugging agents means inspecting that loop, because failures often come from orchestration, state, tool use, or stopping logic rather than model capability alone.
What this lesson answers
- what is the agent loop
- why is an agent not just a model
- where do AI agent loops fail
Notes
An agent is not just a smarter model. The important idea is the loop around the model: give the model a goal and context, let it decide the next action, possibly call a tool, observe the result, update its context, and repeat until it stops or is stopped. The model is only one component inside a control flow system.
A useful mental model is a junior developer with a terminal, a browser, and a notebook. They read the task, choose a command or question, inspect the output, revise their plan, and continue. The tool result matters because the model does not magically know what happened after an action; the system must feed the observation back into the next model call.
The common misconception is that “the model is the agent.” That is wrong because a model call by itself is a one-shot text prediction. The agent behavior comes from orchestration: prompts, memory or context, tool schemas, permissions, stopping rules, retries, and error handling. Many agent failures are loop failures, not intelligence failures: the model chooses the wrong tool, passes invalid arguments, misreads the result, repeats an action, loses the goal, or never reaches a stopping condition.
After this lesson, you should be able to draw the loop as model, tool call, result, repeat. You should also be able to annotate failure points: bad instruction, bad plan, unavailable tool, malformed tool input, misleading tool output, missing state, infinite loop, unsafe action, or premature stop. That diagram is the starting point for debugging agents like production systems rather than treating them as mysterious chatbots.
Common questions
- What is the difference between a model and an agent?
- A model call predicts a response from the prompt it receives. An agent wraps that model in control flow: goal, context, tool definitions, permissions, observations, retries, and stopping rules. The agent behaviour comes from the repeated cycle of deciding, acting, observing, and updating state.
- Why does the tool result need to go back into the model?
- The model does not automatically know what happened after a tool ran. If the system does not pass the observation back into the next call, the model is reasoning from stale context. Feeding results back is what lets the loop revise its plan and decide the next useful step.
- What are common failure points in an agent loop?
- Failures can appear at every stage: unclear instructions, poor planning, unavailable tools, invalid tool arguments, misleading outputs, missing state, repeated actions, unsafe operations, or weak stop conditions. Treating these as loop failures makes debugging more like production incident analysis and less like guessing at model behaviour.
Short definition: what is loop, not the model?