Not a buzzword walkthrough — the actual loop running underneath: how a model decides what to do, calls a tool, reads the result, and decides again, until the task is done.
A plain call to a language model is a single round trip: you send a prompt, it sends back text, and that's the end of it. It has no way to check a fact, look something up, or take a second attempt if the first answer was wrong.
An AI agent wraps that same model in a loop. Instead of answering once, the model is given a goal, a set of tools it's allowed to use, and the ability to keep going: read the result of one action, decide what to do next, and repeat until the goal is met or it decides to stop. The "agent" part isn't a different kind of model — it's the loop, the tools, and the decision-making wrapped around it.
Nearly every agent framework, however it's branded, runs some version of the same four-stage loop. The model thinks about what to do, takes an action, observes what happened, and decides whether to act again or stop.
Strip away the branding and every agent has the same four parts. The model is the reasoning engine; everything else exists to feed it information and let it affect the world.
Example task: "Find last quarter's revenue in our spreadsheet and email a summary to the finance team."
The task, plus a system prompt describing what tools it has and how it should behave, is passed to the model as the starting context.
The model decides it can't answer directly — it needs the spreadsheet data first — and picks a tool suited to that: a file-reading or spreadsheet tool.
The agent framework executes that tool call for real — opening the file, running the query — and captures whatever comes back.
The tool's output (say, a table of revenue figures) is fed back into the model's context as the newest piece of information.
Now that it has the numbers, the model decides the next step: draft a summary, then use an email tool to send it — or it might realize it needs one more lookup first.
Once the model judges the task complete, it stops calling tools and returns a final answer or confirmation instead of continuing to loop.
The model alternates explicitly between writing out its reasoning and taking an action, one step at a time, checking results before deciding what's next.
The model first writes a multi-step plan up front, then works through it step by step, adjusting the plan if a step's result changes what's needed.
The simplest and most common pattern: the model is given a list of tools and just keeps calling them and reading results until it's satisfied — no separate planning stage.
One orchestrator agent breaks a large task into pieces and delegates each to a specialized sub-agent — a researcher, a coder, a reviewer — then combines their outputs.
A single agent handles everything itself, cycling through the loop with all the tools it has. A multi-agent system splits the work: an orchestrator hands off sub-tasks to smaller, more focused agents, then assembles what they return.
| Aspect | Chatbot / single LLM call | AI agent | Traditional script |
|---|---|---|---|
| Decides its own steps | No — one response per input | Yes — chooses actions as it goes | No — steps are fixed in code |
| Uses tools | Rarely, if at all | Yes, dynamically, as needed | Yes, but in a hard-coded order |
| Handles the unexpected | Can't react mid-task | Can re-plan after a bad result | Fails or errors on the unplanned case |
| Predictability | High — same input, same shape of output | Lower — path can vary between runs | Highest — always the same steps |
| Best fit | Q&A, drafting, single-shot tasks | Open-ended, multi-step, tool-dependent tasks | Well-defined, repetitive, high-volume tasks |
Without a clear sense of "done," an agent can loop on a task indefinitely, burning time and cost without converging on an answer.
Handing an agent dozens of loosely-described tools makes it more likely to pick the wrong one — fewer, well-documented tools usually work better.
Actions that send money, delete data, or contact people should require a confirmation step — an agent that reasoned incorrectly can act on that mistake just as fast as a correct one.
The same task can be solved a slightly different way on different runs. Systems built around an agent need to tolerate that variability, not assume identical output every time.