13 — AI Agents: Tools, ReAct, and Multi-Agent Systems

"An LLM that does stuff" was the whole extent of my agent model, and it was too vague to build with. The definition that stuck: an agent is an LLM in a loop with tools, deciding what action to take next based on what it observes — and a multi-agent system is just several of those agents coordinated. [1] There's no new kind of model involved. The leap from "chatbot" to "agent" is entirely architectural: a loop, a set of tools, and a memory of what's happened so far.

The framing that finally landed is a strict cycle. The model looks at the current state (the user's request plus everything that's happened so far), emits a _thought_ about what to do, takes an _action_ by calling a tool, receives an _observation_ of what the tool returned, and loops back. It keeps going until it has enough to produce a final answer. That cycle — Reason, Act, Observe — is the ReAct pattern, and almost every agent framework implements some version of it.

What makes something an agent

The boundary between "an LLM call" and "an agent" is the loop and the tools. A single LLM call takes a prompt and returns a response — no actions, no observations, no memory beyond the prompt. An agent adds three things on top:

• A persistent state — the running memory of the request, the thoughts, the actions taken, and the observations received.
• Tools — external functions the model can decide to call: a search API, a calculator, a database query, a code interpreter.
• A control loop — the model decides, at each step, whether to call another tool or produce a final answer.

That's it. The model itself is the same next-token-predictor covered earlier. The agent architecture is what turns that predictor into something that can take real actions in the world, and the quality of the agent is mostly the quality of its tools and its loop, not the raw capability of its model.

Tools and function calling: how actions happen

The mechanism that makes agents practical is function calling. Instead of the model producing free text that I then have to parse, I declare a set of functions with typed schemas, and the model emits a structured call — function name plus arguments — when it decides an action is needed [2]. The system executes the function and appends the result to the context as an observation.

The reliability this gives is the whole reason agents are buildable at all. Free-text tool calls are fragile — the model might phrase the call slightly differently each time, and parsing breaks. Schema-constrained function calling turns "the model wants to use a tool" into a deterministic, typed event my code can act on. From Hugging Face's agents course, the unifying idea is that a tool is just a function the model can invoke, and good tool design — clear names, tight schemas, single responsibilities — is what makes an agent capable [3].

ReAct: the canonical loop

ReAct (Reason and Act) is the pattern most agent frameworks implement, and it's worth seeing named because it makes the loop explicit [4]. Each cycle:

1. Thought — the model reasons about the current state and what to do next.
2. Action — it calls a tool (via function calling).
3. Observation — the tool's result is appended to the context.
4. Repeat until the model emits a final answer instead of another action.

The Thought steps are the model writing its own scratchpad into the context, the same chain-of-thought idea from the context-engineering post. The Actions are where it touches the real world. The Observations are how it learns what happened. ReAct works because externalizing reasoning into written thoughts, combined with real observations from tools, lets the model decompose problems it couldn't solve in a single shot.

Agent use cases

Where agents earn their place is anywhere the task needs multiple steps, real-world data, or decisions about what to do next based on intermediate results [5]:

• Customer support that can look up an order, check a policy, issue a refund — a sequence of real actions, not one answer.
• Workflow automation that orchestrates several systems (CRM, email, database) to complete a business process.
• Research that searches, reads, summarizes, and follows citations across multiple sources.
• Cybersecurity, finance, sales — domains where the value comes from acting on current information the model wasn't trained on.

The pattern across all of them: a single LLM call can't do it, because the task requires iterating based on what's observed. That's the signal that an agent — not a prompt — is the right shape.

Multi-agent systems: coordination on top of the loop

A multi-agent system layers one more idea on top: instead of one agent doing everything, several agents interact — cooperating or competing — to achieve individual or collective goals [6]. Each agent is still just the loop above; the new part is the coordination between them.

Why bother with multiple agents? Specialization. A single generalist agent trying to do planning, retrieval, coding, and verification tends to do none of them well. Splitting the work across specialized agents — one plans, one retrieves, one writes code, one reviews — lets each focus on its job, and the coordination layer routes messages between them [6]. The cost is orchestration complexity: now I have to design how the agents communicate, who goes next, and how conflicts are resolved. Multi-agent systems earn their complexity when the task is genuinely decomposable into specialized roles; for simpler tasks, a single well-tooled agent is almost always simpler and good enough.

How I use this

The discipline is to reach for agents only when a single LLM call provably can't do the job — when the task needs iteration based on observation. For everything else, a good prompt with retrieval is cheaper, faster, and easier to debug. When I do build an agent, I invest most of my effort in the tools (clear schemas, single responsibilities) and the loop (when to stop, how to handle tool failures, how to keep the context window from bloating). I reach for multi-agent architectures only when the task has clearly separable roles that would step on each other in a single agent's context. And I always log the full Thought-Action-Observation trace, because debugging an agent without seeing its reasoning is mostly guesswork. The agent isn't a smarter model — it's a loop with good tools, and treating it that way keeps the complexity honest.

References

[1] LangChain, "Building an AI Agent Tutorial," 2024. [Online]. Available: https://python.langchain.com/docs/tutorials/agents/

[2] The New Stack, "A Comprehensive Guide to Function Calling in LLMs," 2024. [Online]. Available: https://thenewstack.io/a-comprehensive-guide-to-function-calling-in-llms/

[3] Hugging Face, "What are Tools?," Agents Course, 2025. [Online]. Available: https://huggingface.co/learn/agents-course/en/unit1/tools

[4] Prompting Guide, "ReAct Prompting," 2024. [Online]. Available: https://www.promptingguide.ai/techniques/react

[5] DigitalOcean, "AI Agents and Their Types," 2024. [Online]. Available: https://www.digitalocean.com/resources/articles/types-of-ai-agents

[6] IBM, "What is a multi-agent system?," 2024. [Online]. Available: https://www.ibm.com/think/topics/multiagent-system