Ask a normal chatbot to book you a table, and it will cheerfully tell you how to book a table. Ask an agent, and it will actually go and try to book the table: check the calendar, look up the restaurant, see it’s full, pick another night, and come back with a confirmation. Same underlying model. Completely different behaviour. One talks. The other acts, looks at what happened, and keeps going.

That gap is the most important idea in AI right now, and underneath all the noise it is shockingly simple. An agent is a language model wrapped in a loop. That’s the secret. Not a new kind of brain, a new kind of plumbing around the same brain, one that lets it take a step, see the result, and decide the next step, again and again, until the work is done.

I want to take you through that loop honestly: what it is, where it came from (a single 2022 paper that quietly started all of this), how modern agents changed it, and the part nobody warns you about, which is that the hard problem was never making an agent smart. It was making it stop. I’ve built a few of these, and that last part is where the real scars are.

The difference in one picture

A chatbot

Takes your message, produces one answer, and is finished. It cannot check whether the answer was right. It cannot do anything about it if it wasn't.

ask → answer → stop

An agent

Takes a goal, then works toward it in steps. Each step it can reach into the real world, see what came back, and adjust. It runs until the goal is met, not until it has said one thing.

goal → think → act → observe → think → … → done
The whole distinction. A chatbot is a function that returns once. An agent is a loop that keeps returning to the same model with an updated picture of the world, asking "given what just happened, what now?"

The loop itself: Think, Act, Observe

Here is the engine. Strip an agent down to nothing and this is what’s left, three moves in a circle:

  • Think. The model reasons about the goal and the situation right now. What’s the next best move?
  • Act. It does one concrete thing in the world: calls a tool, runs code, queries a database, searches the web.
  • Observe. It reads what came back, the result, the error, the data, and feeds that into the next Think.

Then it loops. The observation from this turn becomes part of the thinking for the next turn. That feedback, the fact that the agent sees the consequences of its own action before choosing again, is the entire source of an agent’s power.

THINK reason about next move ACT call a tool / run code OBSERVE read the result goal met? → stop
Think leads to Act, Act produces something to Observe, Observe feeds back into Think. Round and round. The dashed line is the way out: at the top of every loop the agent checks "am I done?" and only then breaks the circle. Hold onto that exit. We'll come back to it, because it's where agents go wrong.

Where this came from: a paper called ReAct

This wasn’t obvious. For a while, the clever trick was “chain of thought”, letting a model reason step by step out loud before answering. It helped, but it had a rotten failure: the model was reasoning in a sealed room. If it thought something false, it had no way to check, and the mistake carried through to the end. Confident, well-reasoned, wrong.

In October 2022, a group of researchers (Shunyu Yao and colleagues, out of Princeton and Google) published a paper called ReAct: Synergizing Reasoning and Acting in Language Models. The idea in the title is the whole thing: don’t make the model only reason, and don’t make it only act. Interleave them. Let it write a thought, take an action based on that thought, observe the real result, and use that to correct its next thought.

That one move fixed the sealed-room problem. Now when the model reasoned toward something false, its very next action bumped into reality, a real Wikipedia lookup, a real tool result, and reality corrected it. Reasoning kept the actions purposeful; actions kept the reasoning honest. A ReAct trajectory reads almost like a person thinking out loud while working:

Thought: The user wants the population of the author's birth city. I don't know the city yet, so first find the author.
Action: search("author of The Left Hand of Darkness")
Observation: Ursula K. Le Guin, born in Berkeley, California.
Thought: Good, birth city is Berkeley. Now I need Berkeley's population.
Action: search("population of Berkeley, California")
Observation: About 120,000.
Answer: Around 120,000. → done
A ReAct-style trace. Notice it never guessed the population from memory. It found the city, checked reality, then found the number, checking reality again. Each Observation grounds the next Thought. This interleaving is exactly what chain-of-thought alone couldn't do.

And it worked, measurably. On interactive benchmarks, ReAct beat the previous best approaches by a wide margin, 34% better on a household-tasks benchmark called ALFWorld, 10% better on a web-shopping one called WebShop, using just one or two examples. On top of that, its step-by-step trajectories were far easier for a human to read and trust than a black-box answer. That combination, better results and more interpretable, is why this paper is widely treated as the seed of the whole agent era.

An agent is four things bolted together

The loop is the runtime, but what’s actually running inside it? A clean way to hold it, one that senior engineers use as a mental checklist:

LLMthe reasoning brain
+
Toolshands to act in the world
+
Memorywhat happened so far
+
Planningbreaking the goal into steps
Agent = LLM + Tools + Memory + Planning, and the loop is what ties them together. Take away tools and it can only talk. Take away memory and it forgets last turn. Take away planning and it can't handle anything multi-step. The loop is where all four meet, turn after turn.

If you’ve read my earlier posts, this is the moment they all click into one picture. MCP is how the Act step reaches real tools. Skills are packaged know-how the agent can pull in when a task matches. Modes (like Roo’s Architect/Code/Debug) shape how the Think step behaves. Embeddings power the Memory, recalling what’s relevant to now. None of those were separate topics. They were all pieces of this one loop, and now you can see where each one plugs in.

The developer’s version: same task, three ways

If you write code, here’s the comparison that makes it click for good. Forget booking tables. Take a real, ordinary developer moment: your test suite just went red, and you want it green again. Watch the same goal handled three ways, because the jump from the middle column to the right one is exactly what an agent is.

1 · Normal use
You, by hand
# you run it $ npm test # read the error # open the file # guess the fix # run it again # repeat, tired
Fully manual. All the intelligence and every decision is you. The computer only does exactly what you type, one command at a time.
slow, but you're in total control
2 · Automation (a script)
A script you wrote
# fix-tests.sh npm test if fail: npm run lint --fix npm test if still fail: exit 1 # give up
Fast and repeatable, but rigid. It only handles the exact failures you predicted in advance. A failure you didn't foresee? It has no idea. It can't reason, only follow.
breaks the moment reality surprises it
3 · Agent
An agent, given the goal
Think: tests fail on auth.ts Act: read auth.ts + the error Observe: null token on line 42 Think: missing await Act: edit, re-run tests Observe: green ✓ → done
You give the goal, not the steps. It reads the *actual* error, reasons about *this specific* cause, fixes it, and checks its own work, including failures nobody scripted for.
flexible, but needs guardrails (see below)
Left to right, the intelligence moves out of your head and into the loop. A script automates the steps you already know. An agent figures out the steps you didn't. That is the whole leap: a script follows a fixed path; an agent finds a path.

The trap is thinking an agent is just “a smarter script.” It isn’t. A script is a fixed decision tree you wrote at design time, it can only ever do what you anticipated. An agent decides at runtime, looking at the real situation, so it can handle the failure you never saw coming. That flexibility is the gift and, as we’re about to see, the danger.

Normal useAutomation / scriptAgent
Who decides the stepsYou, liveYou, ahead of timeThe model, at runtime
Handles the unexpectedYes (you adapt)No (only what you coded)Yes (it reasons about it)
Speed / repeatabilitySlow, manualFast, exactFast-ish, variable
PredictableFullyFullyMostly, needs guardrails
Best forOne-off, judgment callsKnown, stable, repeated tasksFuzzy, multi-step, changing tasks
None of these is "best." A stable, well-understood task wants a script, cheaper and 100% predictable. Save the agent for the messy, multi-step work where you can't write the path in advance. Using an agent where a script would do is how you get slow, expensive, unpredictable versions of things that used to just work.

How modern agents quietly changed the format

Here’s a nuance worth knowing, because people conflate two things. The original ReAct had the model literally write out “Thought:”, “Action:”, “Observation:” as text, and the surrounding code parsed that text to figure out what to do. It worked, but parsing free-form text is fragile.

Modern models learned to do the Act step natively, through tool calling (also called function calling). Instead of writing “Action: search(…)” as prose to be parsed, the model emits a clean, structured request for a specific tool with typed arguments, and the runtime executes it directly. Same loop, sturdier joints. So today you’ll meet two flavours, and both are the agent loop underneath:

Classic ReAct (text)Native tool-calling
How it actsWrites "Action: ..." as text, code parses itEmits a structured tool request directly
ReasoningFully visible in the traceOften more implicit, less to read
SturdinessFragile, parsing can breakRobust, no parsing guesswork
Best whenYou need transparency, or the model has no tool-callingSpeed and reliability at scale
Still the loop?YesYes, exactly the same Think→Act→Observe
ReAct is the founding idea; native tool-calling is the industrial version of the same idea. Transparency versus efficiency. Many production agents lean on tool-calling for speed but keep some visible reasoning for the hard, ambiguous steps. It isn't ReAct-or-nothing; it's a dial.

So, to answer the question directly: ReAct and “the agent loop” are not the same thing. The agent loop is the general Think→Act→Observe cycle. ReAct is the specific, historic technique that made that loop practical for language models by interleaving written reasoning with actions. Every ReAct agent is running the loop; not every agent loop is literally ReAct.

The part nobody warns you about: making it stop

Now the honest part. Building an agent that can act is the easy half. Building one that reliably stops is the half that keeps you up at night, and it’s where most demos quietly fall apart in production.

Think back to that dashed “am I done?” exit on the loop diagram. An agent decides for itself whether to keep going. That’s the whole point of autonomy, and it’s also the whole danger. What happens when it’s wrong about being done?

iteration 1 … 50 … 400 … still going, still spending
A loop with no hard ceiling. The agent hits a subtle dead end, a tool that keeps returning empty, a goal it can't quite satisfy, and instead of stopping, it tries again. And again. Each turn is a real model call costing real money. This is not hypothetical: teams have reported single runaway sessions burning thousands of dollars before anyone noticed.

The failure modes are famous enough that they have names now. The big ones:

  • The infinite loop. No stopping condition, so it never ends. The most common production failure, full stop.
  • The retry spiral. A tool returns nothing useful, the model assumes it just phrased it wrong, and retries the same doomed action forever.
  • Cost blowup. Every iteration is a paid model call plus paid tool calls. Uncapped loops turn a bug into a bill.
  • Wrong-tool drift. Vague tool descriptions lead the agent to keep reaching for the wrong tool, never making progress.

The fix is not “make the model smarter.” A smarter model can rationalize continuing just as easily. The fix is guardrails that don’t depend on the agent’s own judgment, an escape hatch it can’t argue its way out of:

1
A hard iteration cap. "You get at most 25 turns." Non-negotiable, enforced by the outer code, not the model.
2
A cost / token budget. Stop when spend crosses a line, no matter what the agent thinks it needs.
3
No-progress detection. If several turns produce nothing new, break out. Repetition is the tell.
4
Human-in-the-loop checkpoints. For anything irreversible (spending money, deleting data), pause and ask a person first.
The line between a slick demo and a production agent is almost entirely here. The industry even has a name for this discipline now: loop engineering. The clever prompt gets you the demo; the guardrails get you something you can actually deploy.

This is exactly the design principle behind the safer-agent work I’ve been building. When an agent can spend money or take irreversible actions, the sane default is deny-by-default with a human checkpoint, and a budget it physically cannot exceed. Autonomy is wonderful right up to the moment it isn’t, and the guardrails are what let you sleep while it runs.

The whole thing, in one breath

An agent is a language model in a loop. It thinks about the goal, acts on the world, observes what happened, and repeats, until it decides it’s done. That loop was made practical by ReAct in 2022, which interleaved reasoning with real actions so the model’s mistakes could be corrected by reality instead of compounding in a vacuum. Modern agents run the same loop with sturdier, native tool-calling. And the four pieces, LLM, tools, memory, planning, are what turn inside it.

The magic, when you finally see it, isn’t magic at all. It’s a very smart thing that learned to check its work by doing, one honest step at a time. And the craft of building one well is mostly the unglamorous discipline of knowing when to make it stop.

← Back to blog