🤖 What Is an Agent: LLM + Tools + Loop

What Is an Agent: LLM + Tools + Loop: A chatbot is a brilliant consultant sitting behind a glass wall in a room full of tools; an agent is that SAME consultant handed a key to wa

A chatbot is a brilliant consultant sitting behind a glass wall in a room full of tools; an agent is that SAME consultant handed a key to walk through the glass and actually use the tools — the mechanism is exact: the consultant's expertise (the LLM) doesn't change between the two, what changes is whether anything connects their words to actual effects in the world. Here is the question worth sitting with: if the LLM inside a chatbot and the LLM inside an agent can be the exact same model, what makes one "just answer" and the other "get things done"? Because the agent architecture wraps that same model in a LOOP with access to tools: the model perceives the current state, decides on an action, a tool actually executes and returns a real result, and the model observes that real result before deciding the next action — a chatbot stops after one turn of "decide," an agent keeps looping through "perceive → decide → act → observe" until the task is done. Java comparison: this is the Strategy design pattern living inside a while loop — the LLM is a pluggable "decide what to do next" strategy object, called repeatedly inside a loop that also calls into real APIs/tools and feeds results back as the strategy's next input; swap the strategy (a different model) and the loop architecture doesn't change, exactly like swapping a Comparator without touching the sort algorithm around it. The QA stake: you already saw two commercial examples of exactly this loop on the Claude AI page — Claude Code and MCP — this tab names the general mechanism those two specific products implement.

Chatbot vs Agent: Answering vs Acting

A chatbot's job ends the moment it produces a text response — even a very good one. An agent's job is not producing text, it's accomplishing a task, and text (specifically, a request to call a tool) is just one of the things it can produce along the way. The dividing line is not intelligence, it's architecture: does anything wrap the model in a loop with real tool access?

Reasoning: why can't a plain chatbot "just decide" to run a command on its own? Because a chatbot has no execution environment connected to it — it can WRITE the text of a command, but nothing in a pure chat interface takes that text and actually runs it against a real file system or terminal. An agent framework is precisely the missing wiring that connects "the model wants to do X" to "X actually happens," plus feeds the real outcome back in.

The Loop: Perceive → Think → Act → Observe

Every agent, regardless of product, runs the same four-step loop: 1) perceive the current state (a file, a test result, a user request), 2) think — decide the next action based on that state, 3) act — call a tool or function, 4) observe the real result of that action, then loop back to perceive with the updated state. The loop ends when the model decides the task is complete, or a safety limit is hit (covered in the Risks tab later).

You have already seen two commercial examples of exactly this loop: Claude Code on the Claude AI page (perceive a failing test → decide to run it → act by executing → observe the real error → repeat) and MCP (perceive a task → decide a tool call is needed → act via the MCP server → observe the real result → repeat). This tab names the general mechanism those two products implement.

Step by Step: The Agent Loop in Action

The agent reads the current state — a failing test file, a user request.

The LLM decides the next action based on that state.

A tool or function is actually called and executes for real.

The real result of that action is read back.

The loop returns to perceive with updated state, or stops if the task is done.

Arrange an agent's perceive-think-act-observe loop in the correct order.