What an AI agent is: anatomy and the ReAct loop
Agent = model + goal + tools + memory + autonomy. The piece that ties it all together.
7 min read
In previous lessons you learned how an LLM reasons, how to give it facts via RAG, and how it calls external tools. An AI agent is what happens when you connect all of that into a loop that runs on its own until the goal is reached — and understanding that loop is what separates people who build agents from people who just use chatbots.
Agent is not a synonym for LLM
There is a common market confusion: calling anything an "agent" just because it uses a language model. It is worth being precise.
Pure LLM receives a prompt, returns text. No state, no action, no loop. You ask, it answers — done.
Fixed workflow is a deterministic pipeline: step A calls the model, step B processes the result, step C saves to the database. The code decides the flow; the model just fills in blanks. Useful, predictable, but rigid.
RAG (Lesson 06) adds document retrieval before generation. Still not an agent — it is an enriched call. The model does not decide whether to search or what to do with the result beyond answering.
Agent is different in nature: the model receives a goal, decides how to reach it, chooses which tools to use, observes the results, and keeps reasoning until it finishes — or until it realizes it cannot. Control flow lives inside the model, not in your code.
This distinction matters in practice because agents fail in ways workflows do not: they can loop, take unexpected paths, or use tools in the wrong order. Designing an agent requires thinking about containment, not just functionality.
Four approaches side by side
| Approach | Who controls the flow? | Uses tools? | Has memory? | Autonomous? | |
|---|---|---|---|---|---|
| Pure LLM | Your code | No | No | No | — |
| Fixed workflow | Your code | Yes (hardcoded) | Optional | No | — |
| RAG | Your code | Vector search | Call context | No | — |
| Agent | The model | Yes (dynamic) | Yes (short + long term) | Yes | — |
Anatomy of an agent
Every functional agent has four pieces. This is not theory — if one is missing, the system degrades to something simpler.
Model (reasoning): the LLM is the brain. It reads the goal, the history, and the available observations, and decides the next step. Reasoning quality depends directly on the chosen model and the system prompt.
Tools: these are the agent's hands. Without tools, the model only produces text. With tools (Lesson 07), it can search the web, query a database, call an API, run code. Each tool has a name, a description, and a parameter schema — the model reads this and decides when and how to use it.
Memory: the agent needs to know what it has already done. Short-term memory is the message history in the context window — cheap to implement, expensive to keep long. Long-term memory is external storage (vector store, relational database) that the agent queries when needed. Lesson 12 covers this in detail.
Planner (optional but powerful): in more sophisticated agents, there is an explicit planning step before acting — the model decomposes the goal into sub-tasks. This reduces errors on long problems. We will see this pattern in Lesson 13.
In practice, you implement these pieces with simple code: a loop, a message array, a dictionary of available tools, and function calls. The model orchestrates; you just make sure the pieces are available.
The ReAct loop of an agent
Full flow of one reasoning-action cycle. The model perceives the current state, reasons about the next step, acts by calling a tool, observes the result, and decides whether the goal has been reached.
- Percepção · contexto + histórico
- Raciocínio · LLM decide próximo passo
- Ação · chamada de ferramenta
- Observação · resultado da ferramenta
- Objetivo atingido? · sim / não / erro
- Busca / RAG · recuperação de fatos
- API externa · ação no mundo
- Execução de código · cálculo / transformação
- Curto prazo · janela de contexto
- Longo prazo · banco vetorial / relacional
- Resposta final · entregue ao usuário
The ReAct loop step by step
ReAct is a reasoning pattern published in 2022 that combines Reasoning and Acting in an interleaved loop. In practice, it is the most common way to implement agents with LLMs today.
The loop has four phases that repeat:
- Perception: the model receives the current state — the user's goal, message history, results of previous actions, and relevant memory. All of this goes into the context.
- Reasoning (Thought): the model generates a natural-language thought explaining what it will do and why. This is not cosmetic — forcing the model to verbalize its reasoning improves the quality of the next decision (think chain-of-thought, Lesson 05).
- Action: the model emits a tool call — a JSON with name and parameters. Your code executes the tool and returns the result. Without tool calling (Lesson 07), this step does not exist.
- Observation: the tool result is added to the history as a system or tool message. The model reads this in the next iteration.
Concrete example: goal = "What is the current price of AAPL and how much did it change this week?"
- Thought: I need to fetch today's price and the price from 7 days ago.
- Action:
get_stock_price({"ticker": "AAPL", "date": "today"}) - Observation:
{"price": 213.40} - Action:
get_stock_price({"ticker": "AAPL", "date": "7d_ago"}) - Observation:
{"price": 198.10} - Thought: I have both values, I can calculate and answer.
- Final answer: "AAPL is at $213.40, up 7.7% this week."
The loop closed in two cycles. On more complex problems it can run dozens of times — and that is where guardrails (Lesson 10) and iteration limits matter.
Order an agent's loop (ReAct)
One reasoning-and-acting cycle.
- 1Act by calling a tool
- 2Observe the result and decide whether to repeat or finish
- 3Perceive the goal and current context
- 4Reason about the next step
The four phases of the ReAct loop
- 1
Perception
The model reads the goal, the full conversation history, results of previous actions, and any retrieved memory. All of this forms the decision context.
- 2
Reasoning (Thought)
The model verbalizes what it will do before acting. This step improves the quality of the next action and makes the agent's behavior auditable.
- 3
Action
The model emits a structured tool call. Your runtime executes the actual tool — search, API, code — and captures the result.
- 4
Observation
The tool result enters the history. The model decides whether the goal was reached or if another cycle is needed. If reached, it generates the final answer.
In practice, an agent without tool calling is just an LLM with a long prompt. What makes the ReAct loop real is the model's ability to emit structured function calls (Lesson 07) and your runtime's ability to execute them and return the result. Without that, the 'agent' is only simulating actions in text — useless in production. Before building any agent, make sure the model you chose supports function calling natively and reliably. Smaller or older models frequently hallucinate tool parameters, which silently breaks the loop.
When you need an agent — and when you don't
Agents are powerful and expensive to operate. Each loop cycle consumes tokens, latency, and potential for error. Use agents when the problem genuinely requires autonomy — when the workflow cannot be determined in advance because it depends on data that only exists at runtime.
Use an agent when:
- The number of steps to solve the problem is variable and depends on what is discovered along the way.
- The model needs to decide which tool to use, not just how to use a predefined tool.
- The goal is open-ended enough that different paths are valid.
- You need autonomous failure recovery — the agent tries a different approach if the first one fails.
Do not use an agent when:
- The flow is fixed and you know exactly the sequence of steps. A deterministic workflow is cheaper, faster, and more predictable.
- The task is a single LLM call with RAG. No loop, no agent.
- Latency is critical and each additional cycle is unacceptable.
- The domain is high-risk (financial, medical, legal) without a human in the loop.
The rule I use: start with the minimum. If a prompt + RAG solves it, do not build an agent. If a fixed workflow solves it, do not build an agent. An agent is the last layer of complexity, not the first.
Agent vs other approaches
Tap a concept, then its definition.
Key takeaways from this lesson
Frequently asked questions
Is ReAct the only loop pattern for agents?
No. ReAct is the most common and the most solid starting point. There are variations like Plan-and-Execute (the model plans all steps before acting) and Reflexion (the model critiques its own actions). Lesson 13 covers these advanced patterns.
What is the difference between an agent and a multi-agent system?
A single agent has one model and a set of tools. In multi-agent systems, multiple agents collaborate — each with its own model, tools, and scope. An orchestrator agent delegates sub-tasks to specialized agents. This is covered in Lesson 13.
How many iterations can an agent run before getting stuck?
It depends on your runtime and the limit you configure. Always set an explicit max_iterations — without it, a poorly instructed agent can run indefinitely consuming tokens and money. Typical values range from 5 to 20 iterations depending on the expected task complexity.
Where do MCP and skills fit in this architecture?
MCP (Lesson 14) is a standardized protocol for exposing tools and context to the agent — it solves the problem of how the agent discovers and invokes tools in an interoperable way. Skills (Lesson 15) are packaged, reusable capabilities that you can compose into different agents without rewriting logic.