Agents & Multi-Agent Systems

We have built models that can reason (Chapter 25), use tools (Chapter 28), retrieve knowledge (Chapter 29), and remember long contexts (Chapter 33). This chapter brings them together into AGENTS — systems that pursue GOALS autonomously over many steps, deciding for themselves what to do next. An agent is where all the book's capabilities converge into something that can act in the world with a degree of independence.

A normal model call is a single round-trip: you ask, it answers, done. An AGENT is fundamentally different: given a GOAL, it operates in a LOOP — deciding what to do, taking an action (often a tool call), observing the result, deciding the next action, and continuing until the goal is achieved. The agent is not just responding; it is autonomously working toward an objective across many steps, charting its own course.

An agent combines several capabilities from across this book into a coherent goal-pursuing system. The model is the 'brain' that decides; tools let it act; memory lets it track progress; planning lets it sequence steps; reflection lets it correct mistakes. The agent loop ties them together. Each ingredient was covered earlier; the agent is their integration.

At the heart of every agent is a LOOP. The agent perceives its situation, decides what to do, acts, observes the result, and repeats — until the goal is met. This generalizes the tool-calling loop of Chapter 28 and the ReAct framework of Chapter 28 into the core engine of autonomous behaviour. Understanding the loop is understanding agents.

The agent loop is essentially the ReAct pattern (Chapter 28) — Thought, Action, Observation — scaled up with planning, memory, and the autonomy to pursue a multi-step goal. ReAct gave us the basic interleaving of reasoning and acting; the agent loop adds the structure to sustain it over long, goal-directed trajectories. Everything in the rest of this chapter — planning, reflection, memory, multi-agent — enriches this fundamental loop.

A complex goal cannot be achieved in one action — it must be broken into a sequence of smaller steps. PLANNING is how an agent decomposes a goal into a structured set of subtasks and decides the order to tackle them. Good planning is what lets agents handle complex, multi-step objectives rather than just simple ones.

Without planning, an agent reacts step by step with no overall strategy — it may pursue a dead end, miss a necessary prerequisite, or wander. Planning first — 'to book a trip I need to: choose dates, find flights, find a hotel, book both' — gives the agent a roadmap. It can then execute the plan, adapting as it goes. Planning is the difference between purposeful progress and aimless flailing.

Two broad styles. PLAN-THEN-EXECUTE makes a complete plan first, then runs it — good for predictable tasks, but brittle if reality diverges from the plan. INTERLEAVED planning (the ReAct style) plans a step, acts, observes, and replans based on what happened — more adaptive, handling surprises, but potentially less coherent over long horizons. Many agents combine them: a high-level plan that is refined and adapted as execution reveals new information.

Agents make mistakes — a wrong tool call, a flawed step, a misread result. REFLECTION is the ability of an agent to EVALUATE its own work, recognize problems, and correct course. It is one of the most powerful techniques for making agents reliable, and it builds on the 'models judge better than they generate' asymmetry we saw in RLHF (Chapter 23) and Constitutional AI (Chapter 26).

Reflection adds a CRITIQUE step to the agent loop. After producing a result (or completing a step), the agent steps back and asks: 'Is this correct? Does it achieve the goal? What's wrong with it?'. Based on this self-critique, it revises and retries. This catches errors the agent would otherwise propagate, and often dramatically improves output quality — the same way a writer improves a draft by re-reading it critically.

Several frameworks formalize reflection. Reflexion (Shinn et al., 2023) has agents verbally reflect on failures and store those reflections to do better on retries. Self-refine has the model iteratively critique and improve its own output. Critic/actor patterns separate a 'doer' agent from a 'critic' agent that reviews its work. All exploit the same insight: a model is often better at SPOTTING a problem in a result than at AVOIDING it in the first place.

An agent working over many steps needs MEMORY — to track what it has done, remember key facts, and recall relevant past experience. Memory is what lets an agent maintain coherence over a long task and learn across tasks. It comes in several kinds, mirroring human memory, and connects directly to the long-context and external-memory ideas of Chapter 33.

SHORT-TERM (working) memory is the agent's current context — the recent steps, the active task state — held in the context window (Chapter 33). It is fast but limited and lost when the context fills or the session ends. LONG-TERM memory persists across the limited window and across sessions: important information is written to an external store and retrieved when relevant (exactly the MemGPT/RAG idea from Chapters 29 and 33). Together they let an agent both focus on the now and draw on accumulated experience.

A capable agent has many tools (Chapter 28) — search, code execution, databases, APIs, file access — and must ORCHESTRATE them: choosing the right tool for each step, sequencing them, passing results between them, and combining their outputs. Tool orchestration is where the tool-calling of Chapter 28 scales up into coordinated, multi-tool problem-solving.

With many tools, the agent faces new challenges beyond single tool calls. It must SELECT the right tool from many (harder with more options). It must SEQUENCE tools correctly (some depend on others' outputs — the sequential calls of Chapter 28). It must PASS DATA between tools (the output of one becomes the input to another). And it must HANDLE failures gracefully so one tool's error doesn't derail the whole task. Good orchestration makes a many-tool agent feel coherent rather than chaotic.

As the number of tools grows, selection becomes harder — the model must pick correctly from dozens or hundreds. Techniques help: grouping related tools, retrieving only the RELEVANT tools for the current task (tool RAG — embed tool descriptions, retrieve the ones matching the step), and hierarchical organization (high-level tools that internally use lower-level ones). The same description-quality lesson from Chapter 28 applies: clear tool descriptions are what let the agent orchestrate many tools well.

So far, one agent. But some problems are better solved by MULTIPLE agents working together — each specialized, collaborating, debating, or dividing labor. Multi-agent systems are an active frontier, promising to tackle complex problems beyond any single agent. Let us understand when and how multiple agents help.

Several motivations. SPECIALIZATION: different agents can be experts at different things (a coder agent, a reviewer agent, a researcher agent), each with tailored tools and prompts. SEPARATION OF CONCERNS: breaking a complex task across focused agents can be more reliable than one agent juggling everything. DIVERSE PERSPECTIVES: multiple agents can debate or critique each other, surfacing errors a single agent would miss. PARALLELISM: independent subtasks can be handled by different agents simultaneously.

Multiple agents must be ORGANIZED — who decides what, who talks to whom, how work flows. Several coordination patterns have emerged, each suited to different problems. Knowing them helps you design multi-agent systems and understand frameworks like AutoGen and LangGraph.

The dominant multi-agent pattern is ORCHESTRATOR-WORKER (also called manager-worker or supervisor). One ORCHESTRATOR agent receives the goal, breaks it into subtasks, and delegates each to a specialized WORKER agent. The workers execute and report back; the orchestrator synthesizes their results and decides next steps. It mirrors a manager delegating to a team — clear responsibility, easy to reason about, and flexible.

In DEBATE patterns, multiple agents argue different positions or independently solve a problem, then compare and critique each other's answers — often with a judge agent deciding, or the agents converging through discussion. This can improve accuracy and surface errors (different agents catch different mistakes), echoing self-consistency (Chapter 25) and reflection. The diversity of independent attempts is the value: agents that reason differently are unlikely to all make the same mistake.

Multi-agent systems are promising but come with real challenges, and a sober view is essential. More agents introduce more coordination overhead, more places to fail, and more cost. Sometimes a single well-designed agent beats a complex multi-agent system.

Two challenges stand out. ERROR PROPAGATION: in a chain or team of agents, one agent's mistake feeds into the next, compounding (the same multiplication problem as multi-tool orchestration, now across agents). COST: each agent is one or more model calls, so a multi-agent system can make many times more calls than a single agent — multiplying both cost and latency. A debate among 5 agents over 3 rounds is 15+ model calls for one answer.

The recurring theme of agents is the gap between an impressive DEMO and a reliable SYSTEM. Agents that work in a demo often fail on the messy long tail of real tasks. Building agents that work CONSISTENTLY requires deliberate engineering for reliability, drawing together the lessons of this chapter and Chapter 28.

The core reliability challenge is COMPOUNDING. An agent that takes many steps, each with some failure probability, has a success rate that is the PRODUCT of the per-step rates — which decays fast. Twenty steps at 95% each gives ~36% end-to-end success. This is why per-step reliability matters so much, and why reflection, verification, and error recovery (which catch and fix per-step failures before they compound) are essential. The longer the agent's trajectory, the more this matters.

Agents are one of the most hyped and most rapidly-evolving areas of AI. A grounded view of where they actually work today — and where they struggle — helps separate the promise from the reality.

Notice the pattern in where agents succeed: VERIFIABILITY and BOUNDED SCOPE. Coding agents thrive because they can run tests and see whether the code works — grounded feedback closes the reflection loop. Bounded tasks with clear tools (support, automation) succeed because the agent's choices are constrained. Agents struggle most with open-ended, long-horizon, hard-to-verify tasks where mistakes compound and there's no clear feedback signal.

As of this writing, agents are powerful but unreliable for complex open-ended tasks. They shine in verifiable, bounded domains (especially coding) and increasingly handle real workflows, but long-horizon autonomous operation remains fragile — they get stuck, make compounding errors, and need human oversight. The trajectory is rapidly improving (better reasoning models, better tools, better frameworks), but the gap between agent demos and reliable agent products is still real. Deploy agents where the task is verifiable and bounded; be cautious where it is open-ended and high-stakes.

Let us consolidate the chapter into one picture of how an agent — single or multi — is built from the capabilities of this book.

If you remember three things about agents: First, an AGENT IS A LOOP, not a model — a system that pursues a goal over many steps by planning, acting, observing, and remembering, integrating everything in this book. Second, RELIABILITY IS THE CHALLENGE — errors compound across steps, so reflection, verification, and grounded feedback (run the test, fix the error) are what make agents work. Third, SIMPLER IS OFTEN BETTER — single agents often beat multi-agent systems, and agents shine in verifiable, bounded domains; add complexity only when it earns its place.

Exercises 1–10 are pen-and-paper; 11–20 require code.

Further reading: “ReAct: Synergizing Reasoning and Acting” (Yao et al., 2022). “Reflexion: Language Agents with Verbal Reinforcement Learning” (Shinn et al., 2023). “Self-Refine” (Madaan et al., 2023). “Generative Agents” (Park et al., 2023) for agent memory and behaviour. “AutoGen” (Wu et al., 2023) and the LangGraph documentation for multi-agent frameworks. “Toolformer” (Schick et al., 2023) and the SWE-bench / SWE-agent work for coding agents. “Debate” (Du et al., 2023; Irving et al., 2018) for multi-agent debate.

Next → Chapter 35: Open Problems & Future Directions

Across thirty-four chapters you have built a complete understanding of LLMs — from the mathematics of Part I to the autonomous agents of this chapter. But the field is far from finished. The final chapter steps back to survey what we still DON'T know and CAN'T yet do: the unsolved problems of interpretability, alignment, reliability, reasoning, and safety; the deep questions about what these systems are and where they are heading; and the frontiers where the next breakthroughs — perhaps yours — will come. Having learned how LLMs work, we close by honestly confronting their limits and the open horizon beyond them.