AI Agents in Depth by Bojie Li: a chapter-by-chapter review

Getting started, and the argument for the harness

The first chapter is the map for everything that follows. It opens with examples you have probably already used without calling them agents: Cursor editing several files and rerunning tests until they pass, a deep research tool reading and searching in a loop, an assistant that controls a browser to finish a task, a service that negotiates your phone bill down for you. From there it works backward to the three components and then to the ReAct loop, which is the beating heart of every agent. The loop is almost embarrassingly simple once you see it stated plainly: the model thinks, acts, observes the result, and you append that result to the trajectory and run the model again. The whole art is in what you append and when you stop.

To make the point that context is decisive and not just a container, the chapter runs a small ablation, its first experiment, stripping the context down piece by piece and watching the agent degrade. Remove the system prompt, remove the tool definitions, remove the running history, and each removal visibly hurts. It is a cheap experiment with a lasting lesson: the trajectory is not scaffolding around the real work, it is the real work, and the ReAct loop is nothing more than the discipline of appending to that trajectory until the task is done.

The chapter then makes its central move, from prompt engineering to what Li calls loop engineering. A single prompt is a one-shot artifact. A loop is a system, and systems need guardrails, verification, and a way to correct themselves. This is where the harness idea gets its teeth, and the chapter breaks it into five functions the harness performs around the model, the constrain, verify, and correct machinery that turns a clever demo into something that survives contact with users. It walks through how to choose a model for a given job, and the spectrum from fixed workflows to fully autonomous agents, with a piece of advice that reads as hard-won: move along that spectrum in order, prompts first, then workflows, then autonomy, because each step adds capability and unpredictability in equal measure, and skipping ahead is how you end up debugging emergent behavior you never needed. It closes on security as an architectural concern that spans five levels, from the model itself up to whole societies of agents, and insists it has to be designed in from the first line rather than bolted on before launch.

The orchestration section is more useful than its length suggests, because it refuses to crown a winner. A fixed workflow, where you hard-code the steps and let the model fill in the blanks, is predictable and cheap to debug but caps out on anything you did not anticipate. A fully autonomous agent that decides its own steps handles the unexpected but is harder to trust and to trace. The chapter's point is that both belong in your toolkit, that most real products are a blend, and that the right question is not "which pattern is best" but "which pattern fits this task." It pairs that with a short set of principles for building agents that work, keep the loop simple, make each step observable, and put a real check between the agent and any action it cannot take back, which read like the distilled version of lessons the rest of the book then spends nine chapters proving.

If you read only one chapter, read this one. It is the cheapest way to get the mental model the rest of the book assumes, and it will change how you read every agent framework you touch afterward.

Context engineering, the longest and most useful chapter

This is the chapter I would hand to someone who thinks prompt engineering is a solved, slightly embarrassing topic. It is the longest chapter in the book, and it deserves the space. The core claim is blunt: what you show the model, and how you arrange it, matters more than how smart the model is.

It starts at the API level, with the four message roles and the exact shape of a multi-turn tool-calling loop, spelled out in code down to the detail that you need a hard cap on iterations or the agent will happily repeat the same tool call forever. Then it spends real effort on the KV cache, which most writing ignores entirely. The insight that stuck with me is that the KV cache is not a performance footnote; it is an architectural constraint. Because the cache is a prefix, anything you change early in the context invalidates everything after it, which quietly dictates what you are allowed to edit and what has to stay put. The chapter separates the KV cache from the higher-level prompt cache, shows how the chat template turns your neat API messages into the actual token stream the model sees, and then makes a counterintuitive point: the cache does not have to be one-shot. You can treat cached context as editable, composable notes rather than a frozen block, if you design for it.

From there the chapter is a parade of techniques that each solve a real problem. Prompt structure, and the difference between a process-driven prompt that describes a procedure and a brittle pile of stacked rules. How to translate a fuzzy business rule into an instruction the model can actually execute. When a few-shot example earns its token cost and when it just bloats the context. How to design tool definitions so the model picks the right one. Prompt injection gets treated as the core security threat to context rather than an afterthought, which is the correct altitude for it. Skills arrive as composable units of domain capability that enter the context as file reads, with an honest accounting of the trade-offs between different ways to implement them and how they differ from plain tools. There is a whole section on an "agent status bar," Li's term for a compact block of meta-information, including the agent's sense of physical time, injected so the model always knows where it stands; the chapter even weighs two ways to implement those status updates against their respective cache costs, which is the kind of detail that only comes from having shipped this.

The chapter ends on context compression, and this is where it makes its sharpest point. Compression is usually framed as a length problem, but Li reframes it around a claim about how models actually work: in-context learning is mostly retrieval, not reasoning. The model is finding relevant patterns in what you gave it, not deducing from first principles, so the job of compression is not merely to fit under a token limit, it is to actively refine raw data into dense, structured knowledge the model can retrieve cleanly. He ties this back to Rich Sutton's Bitter Lesson and to the idea that sometimes the right move is not to compress a sub-task's context at all but to isolate it in a sub-agent. One detail near the end shows how carefully the chapter thinks at the API level. The status bar carries meta-information the model needs, but the chat API has no dedicated role for it, no slot that means "here is your environment and your progress." So it rides inside a user message, which is a small hack with real consequences for caching and for how the model reads it, and the chapter is honest that this is a workaround forced by the shape of the API rather than an elegant design. In the same spirit, it argues that compression is not always the answer to a growing context; sometimes the better move is isolation, handing a sub-task to a separate agent with its own clean context so the main trajectory never has to hold that weight at all. That choice between compressing and isolating is a recurring decision you will make over and over building agents, and it is nice to see it named plainly. It is a dense chapter and not a quick read, but it is the one whose ideas I expect to reuse the most. If your agents feel dumb, the problem is usually here, not in the model.

Memory and knowledge, from sticky notes to knowledge graphs

Chapter 2 was about information inside a single session. Chapter 3 is about what persists across sessions, and it splits cleanly into two halves: memory of the individual user, and a knowledge base shared across everyone.

The user-memory half is the more original of the two. It lays out four escalating ways to store what an agent knows about you, starting from atomic "simple notes," moving to richer JSON cards that keep contextualized facts resident in the context, and then pushing into stranger territory, storing memory as executable code and even folding it into model parameters. It frames all of this with a three-level scale for what "good memory" even means, from simply recalling a fact when asked, up to proactively using what it knows to serve you before you ask. There are cognitive-science analogies that do real work rather than decorate, a look at how frameworks like Mem0 and Memobase package memory management so you do not have to build it from scratch, and, refreshingly, a section on the unglamorous parts: compressing and reorganizing memory over time, and sanitizing logs so sensitive information does not leak into places it should not.

Two smaller points in this half stayed with me because they are the kind of thing people learn the hard way. One is timeliness and governance: a knowledge base is not a write-once artifact, and the chapter treats keeping it fresh and pruning stale or contradicting entries as a first-class problem rather than an afterthought, which anyone who has watched a RAG system confidently cite a policy that changed six months ago will appreciate. The other is the idea of moving from information retrieval to knowledge discovery, using the same machinery not just to look facts up but to extract patterns and relationships out of a dataset that were never written down explicitly. It is a small pivot in framing with a large payoff, and it is the seed the self-evolution chapter later grows.

The knowledge half is a proper tour of retrieval-augmented generation, and it is honest that naive RAG is often disappointing. It covers the full stack: chunking to define your retrieval units, dense embeddings to capture meaning, sparse embeddings to catch exact keywords, fusing the two into one candidate pool, reranking to fix the final order, and recall metrics to measure whether any of it worked. It extends past text into pulling structure out of charts and document layouts. Then it goes past flat chunks into the structures that make retrieval actually good: RAPTOR's tree of hierarchical summaries, GraphRAG's network of entities and relationships, a filesystem-style paradigm that organizes knowledge with directory structure, and contextual retrieval, which repairs the meaning a chunk loses when you slice it out of its document. The most forward-looking piece is agentic RAG, where the agent runs its own iterative search, deciding what to look up next based on what it just found, instead of doing a single passive lookup. The chapter closes by fusing both halves into a two-tier memory design: an always-resident overview from the JSON cards, plus details fetched on demand through contextual retrieval. If you have ever built a RAG system that shone in the demo and fell apart in production, this chapter will tell you why, and it will not let you off with a single embedding model as the answer.

Tools, and the async problem nobody wants to talk about

Tools are the agent's hands, and this chapter argues that the quality of your tool design sets a hard ceiling on what your agent can do. It opens with a taxonomy of five tool types, perception, execution, collaboration, event-triggered, and user-communication, and a set of design principles that sound obvious until you have shipped a tool that violated them: get the granularity right so you are neither drowning the model in micro-tools nor handing it one god-tool with twenty flags, keep tools general, write descriptions the model can actually act on, and never let the world the model perceives drift out of sync with the world the tool operates on. That last one, fidelity of parameter passing, is the kind of bug that produces confident, wrong behavior, and the chapter treats it as a baseline rather than an edge case.

Each tool category then gets its own emphasis, and the specifics are where the chapter pays off. Perception tools, being read-only, are natural candidates for caching and parallelism, but they need pagination and explicit truncation so a single read does not blow the context. Execution tools, which change the world, get a hierarchical security treatment and a proposer-reviewer split where one step proposes an action and another approves or validates it before or after it runs. Collaboration tools raise the question of how much context a sub-agent should inherit. The MCP section is refreshingly wary: yes, the protocol standardizes how agents and tools talk, but every third-party tool server is a new trust boundary, and the chapter names the specific attacks, poisoned tool descriptions, tool shadowing where a malicious tool impersonates a trusted one, and leaked credentials, then tells you to review before you integrate and defend at runtime. This is the kind of detail that only shows up when someone has been burned.

The most interesting stretch is on event-driven asynchronous agents, and it is a genuinely hard problem that most treatments dodge. An agent that only acts when you poke it is a chatbot. An agent that the world can wake up, via an incoming email, a scheduled trigger, an API callback, is something else. The chapter uses the book's running example systems to show the progression: a time-driven layer with hooks, cron, and a heartbeat that lets an agent act on a schedule, and then a channel mechanism that adds the missing piece, a real ingress path for external events, marking the shift from time-driven to event-driven. It lays out three strategies for handling events of different priority, cancel what you are doing, queue it, or run it in parallel, and it gets into the weeds of how you make a fundamentally synchronous model support interruption at all, with tricks like asynchronous placeholders. There is a quieter idea tucked into this section that is easy to skip and worth slowing down for: virtual identity and isolated execution environments. Once an agent acts on its own schedule and talks to the outside world without a human in the loop for every message, it needs an identity that is genuinely its own, an inbox, an account, a sandboxed place to run, rather than borrowing yours. The chapter treats this as the identity foundation for an agent that operates independently, and it is one of those points that seems minor until you try to build the thing and realize that "who is this agent, and what is it allowed to be" is a real design question with security consequences. It is a good example of the book noticing the seams that only appear in production.

Li is candid that all of this collides head-on with how today's models are trained, which is synchronous and turn-based, and that the current fixes are engineering workarounds rather than a real solution. He points at future models trained in asynchronous environments as the actual answer. That honesty, admitting a whole part of the stack is not solved yet, is a big part of why the book reads as trustworthy. The chapter ends by returning to proactive tool discovery, finding the right tool among many, which sets up the self-evolution chapter later.

Coding agents, and code as a superpower

This chapter has two moves, and both are strong. The first is a practical anatomy of a coding agent, and its central insight reframes why coding agents work at all. They are not good because code-generation models are magic. They are good because software engineering already spent decades building the perfect harness: test suites, type systems, version control, linters. All of that machinery gives an agent a way to check its own work and recover from mistakes, which is exactly what agents in other domains lack. The chapter is specific about the moving parts, the overall workflow, the search tools that let an agent find its way around an unfamiliar codebase, the file-editing tools and their failure modes, a sessionless design that keeps each run clean, and the sandboxing and security you need before you let a model run commands. It gives real space to error recovery, arguing that reliability comes not from a model that never errs but from making sure every class of failure has a matching path to detect it, recover from it, and know when to stop.

The second move is broader and more fun: code as a general-purpose capability, not just a way to write programs. The chapter walks through six ways an agent can use code beyond producing software. Code as a thinking tool, where an agent offloads arithmetic and constraint solving to an interpreter instead of trusting probabilistic mental math. Code as a way to state business rules unambiguously and put a deterministic backstop in front of irreversible actions, where the cost of writing the guard is trivial next to the cost of a wrong deletion. Code that generates slide decks and videos through a propose-then-review loop. Code as an adapter that keeps up with a changing log format on its own, so diagnosis stays automated even as the inputs drift. Code that builds custom UI on the fly, a form or a chart or a small app, instead of dumping plain text at the user. And finally, code that writes code, an agent repairing an existing agent and even creating a new one from scratch. That last idea, agent bootstrapping, is the bridge straight into the self-evolution chapter. The implementation details in the first half are more grounded than most write-ups on coding agents, which tend to stop at "give the model a shell and let it go." The chapter is specific that search and file editing are separate problems with separate failure modes: a search tool has to help the agent build a mental map of a codebase it has never seen, while an edit tool has to apply a change precisely without corrupting the file, and both need to fail loudly rather than silently. It offers concrete implementation tips, the small choices that decide whether a coding agent is usable or maddening, and it keeps returning to error recovery as the thing that actually separates a toy from a tool. The theme is consistent with the whole book: the model writing the code is rarely the bottleneck, the harness around it is.

This is a good one to read even if you are not building a coding agent, because the "code as meta-capability" argument will change how you think about giving any agent an interpreter.

Evaluation, or how to know your agent got better

This is the chapter people skip and shouldn't. Its whole subject is a question that is easy to ask and hard to answer: how do you actually know your agent improved, rather than just feeling like it did? Li's answer is to drag agent development out of what he cheerfully calls alchemy and into something closer to science, with a loop of observe, hypothesize, experiment, validate, and go around again with a sharper hypothesis.

Concretely, the chapter builds a full evaluation stack from the ground up. It starts with reproducible test environments, including specialized ones for tool-calling and for multi-turn human-computer interaction, because you cannot compare two agents fairly if the ground keeps moving under them. Then dataset design, which spends real effort on the leakage problem, the fact that a benchmark loses its meaning the moment the model has seen the answers during training, and on writing task descriptions precise enough to be graded objectively. The workhorse technique is using a language model as a judge, and the chapter is clear-eyed about both its power and its failure modes, then adds pairwise comparison so you can rank models against each other rather than score them in a vacuum. From there it ties evaluation to decisions you actually make: how to choose a model, how to reason about the full cost of an agent system rather than just token price, and how to tell whether the gap between two systems is statistically real or just noise, which is a discipline most teams skip entirely.

The back half is where the chapter earns its keep for anyone running a real product. It moves from external benchmarks to the internal evaluation infrastructure a production system needs: an ablation harness so you can measure what each feature actually contributes, A/B testing done in a way that separates the mechanism from the goal, a two-layer feature-flag system, prompt-sensitivity checks so a tiny wording change does not silently swing your results, and privacy-aware analytics as the foundation under all of it. It closes by reframing simulation environments as the bridge to the next chapter on training, since the same environment that evaluates an agent can also train one. The part I would push people to read even if they skip the rest is the stretch on turning a benchmark report into actual improvements, because it teaches a skill nobody is born with. A benchmark score is a number; the useful thing is buried in which cases failed and why. The chapter walks through reading a report as an act of problem discovery, turning a cluster of failures into a concrete hypothesis about what is wrong, deciding which fix is worth the trade-off it carries, and then closing the loop by feeding the change back into the evaluation and going around again. That habit, treating each evaluation as the start of an investigation rather than a verdict, is the difference between an agent that improves and one that just changes. It is not the most thrilling read in the book, but if you ship agents and you are still eyeballing outputs to decide what is better, this chapter is the intervention you need, and it is the one whose absence most often explains a stalled agent project.

Model post-training, the deep end of the pool

Here the book wades into the water most application developers never enter: actually changing the model's weights. It is one of the two longest chapters, and it is the most academically demanding. If your eyes glaze at the letters SFT and RL, this is where you will feel it, though the author flags the optional-reading sections, including a whole tour of the reinforcement-learning roots of agents, so you can navigate around the heavy math without losing the thread.

The multi-turn credit assignment problem is where the chapter is most illuminating, because it is a difficulty that pure text people rarely have to confront. When an agent takes twenty steps and only the final result tells you whether it succeeded, how do you decide which of those twenty steps deserves credit or blame? Reward only the outcome and the signal is so sparse that learning crawls, and a run that failed at the last step teaches the model nothing about the nineteen good steps before it. Reward the process and you risk the model gaming the intermediate signals instead of actually finishing the task. The chapter lays this tension out clearly and shows why it is the real reason multi-turn agent training is hard, then uses it to motivate the frontier techniques that follow, which are all, at heart, attempts to recover learnable signal from interactions that a naive outcome reward would throw away. Even if you never train a model, understanding this problem changes how you read claims about agents that "learn from experience," because it tells you where the difficulty actually lives.

The spine of the chapter is the relationship between supervised fine-tuning and reinforcement learning, and Li insists they are stages in sequence, not rivals. Fine-tuning stabilizes the output format first, because without a stable format the reward signal cannot even be computed, and reinforcement learning then teaches the model to generalize on that foundation. His compressed slogan, "fine-tuning memorizes, reinforcement learning generalizes," is presented as a measurable phenomenon rather than a vibe, with a table contrasting the two that he calls the most important in the chapter. Along the way it covers how human preferences get turned into a reward model through RLHF, compares the main families of RL algorithms without getting lost in them, and works through the genuinely hard problem of multi-turn tasks: how do you assign credit to one step in a long chain when you only learn at the end whether the whole thing succeeded, and should you reward the process or only the outcome?

Two judgments run through the chapter and are worth carrying away even if you skip the derivations. First, data and environment matter more than the algorithm; off-the-shelf RL is fine, and what separates teams is the fidelity of the simulation environment and the quality of the training data, to the point where good enough fine-tuning data can remove the need for RL entirely. Second, the real bottleneck today is sample efficiency, squeezing more learning out of each expensive interaction. Where the chapter gets interesting, and where I have a small reservation, is that it leans on the author's own recent research for its frontier material, in particular a technique for rewarding the outcome while penalizing the wasteful path so that even failed attempts yield some signal, and work on giving agents a sense of physical time. It also covers on-policy distillation as a way to densify the learning signal at every step. This is frontier work, presented clearly, but a reader should know that parts of this chapter are closer to the author's active research than to settled consensus. That is not a flaw so much as a thing to read with your eyes open. For most people building on top of models rather than training them, this chapter is a skim-to-understand, not a study-to-apply, and that is a perfectly good way to read it.

Self-evolution, growth without retraining

Chapter 7 changed the weights. Chapter 8 asks how an agent can keep getting better while leaving the weights completely alone, which is the situation almost everyone is actually in, since weights update on a cycle of weeks while your APIs, users, and business rules change every day. It is the shortest chapter, and it works well as a fast, idea-dense read after the marathon of Chapter 7.

It starts by naming the uncomfortable default: agents do not learn on their own. Every session begins from the same blank slate, and yesterday's hard-won lesson is gone by morning unless you did something to keep it. The chapter positions its subject among three learning paradigms, post-training that freezes strategy into parameters, in-context learning that adapts only for the moment, and its own topic, externalized learning that writes lessons down somewhere durable outside the model. Then it catalogs the concrete ways to do that: summarizing a successful strategy so it can be reused, recording a workflow so a procedure is not rediscovered each time, keeping Reflexion-style reflections on failures so the same mistake is not repeated, structuring domain knowledge into skills, and mining edge cases to automatically improve the agent's own system prompt. There is even a "sleep learning" idea where the agent reorganizes and consolidates its user memory during idle time, which is a nice echo of how the previous chapters treated memory. Li has a clean phrase for the goal of all this, going from smart to skilled, the difference between raw capability and hard-won proficiency.

The second half returns to a thread from the tools chapter and pushes it much further. It is not enough to find the right tool among the ones that already exist; a truly evolving agent searches the web, pulls in and integrates open-source libraries, and writes brand-new tools from scratch, moving from tool user to tool creator. The recurring example is Voyager, the agent that taught itself to play Minecraft by continuously writing, testing, and saving new skills into a growing library, which is the cleanest illustration of the whole paradigm and the reason it keeps getting cited. The chapter frames the payoff as a three-layer accumulation of capability that compounds over time, one layer being what the agent learns about a specific task, another the reusable skills it builds, and another the broadening set of tools it can reach for, each feeding the next. It also tucks in a practical aside about carrying a long task across sessions, so that work spanning days does not reset every time the context clears, which is the unglamorous plumbing that makes any of this usable. And then, sensibly, it spends its last pages on the safety boundaries of an agent that can expand its own capabilities. An agent that writes its own tools and rewrites its own prompts is exactly the kind of system where a small misalignment can compound, and the chapter is right to insist that the freedom to self-improve has to come with hard limits on what the agent is allowed to touch. Given everything it just described, that is exactly the right place to stop.

Multimodal and real-time, where agents meet the physical world

This chapter leaves pure text behind for voice, screens, and robots, and its unifying theme is that two problems shadow all three: latency and multimodality. It is a genuinely broad chapter, and it is the one most likely to contain something you did not know existed.

The voice section is the most complete treatment I have read of why voice agents are hard. It lays out three architectures in order of sophistication. A cascaded pipeline that chains speech-to-text, a language model, and text-to-speech, simple to build but slow, with errors compounding at each hop; the chapter shows how full streaming and replacing the old voice-activity-plus-recognition front end with a streaming perceiver claws back some of that latency. Then an end-to-end model that ingests audio directly and skips the transcription step. And finally a full-duplex model that can listen and speak at the same time, the way people actually converse and interrupt each other. It digs into the genuinely awkward problem of thinking while speaking, since a model that pauses to reason goes silent and the silence reads as broken, and it walks through several designs, from using fast thinking for filler and slow thinking for the real answer, up to end-to-end approaches that unify thinking and speaking, using a specific recent model as its worked example.

The Computer Use section covers agents that drive a graphical interface by looking at the screen. It works through the action space such an agent needs, the hard problem of visual grounding, getting the model to click the correct pixel rather than something near it, and even agents that can watch an animation or hear a sound to complete a task. It is honest about the state of play: these agents now approach human accuracy on benchmarks like OSWorld, but they take many more steps than a person and slow down as a task drags on, an efficiency gap with no clean fix yet, and mobile is harder than desktop for ecosystem reasons more than technical ones. The robotics section is the most speculative and argues the bottleneck has moved from hardware to the control layer's ability to generalize across tasks. It covers the two-layer split of high-level planning from low-level control, the move from a general vision-language model doing the planning toward specialized embodied reasoning models, vision-language-action control learned from demonstration and the dream of generalizing across different robot bodies, and the stubborn gap between simulation and reality that domain randomization only partly closes. What ties the three scenarios together, and what makes the chapter more than a survey, is the argument that real-time interaction forces a structural change in how agents are built. A text agent can take its time, think in a long silent burst, and then answer. An agent that has to hold a spoken conversation, or react to a moving screen, or control a gripper, cannot, and that pressure is pushing architectures away from tidy serial pipelines toward end-to-end models that fuse perception and action. The chapter is careful to say which parts are close to solved and which are not: voice has walked nearly the whole evolutionary path already, computer use works but is slow and step-hungry, and robotic manipulation still stumbles on generalization and on the unglamorous hardware gaps of touch and dexterous hands. You will not build a robot from this chapter, but you will understand the shape of the problem, and it is a fascinating read.

Multi-agent collaboration, and the strange societies at the end

The final chapter is the most fun, and it saves a genuinely thought-provoking payoff for the end. It starts disciplined, with a framework for thinking about multiple agents along two independent axes: whether they share context, and how they are wired together. Sharing context means each agent inherits everything its predecessor saw, which loses no information but makes the context balloon fast. Not sharing means agents exchange distilled handoffs, files, or messages instead. On topology, it distinguishes a peer pattern for a few agents refining each other's work, a manager pattern for complex tasks that need dynamic scheduling, and a decentralized pattern where control passes among equals. It grounds all of it in two pieces of topology-independent infrastructure: a shared file system as the data plane, essentially a virtual directory tree that mounts agent workspaces, shared spaces, external resources, and system resources, across which agents trade artifacts by passing paths; and a communication layer as the control plane, usually a message bus, for passing messages, querying status, and terminating runs, extended to a standard protocol once collaboration crosses organizational boundaries.

The chapter's most valuable idea is a crisp test for a question people usually answer with hand-waving: when is multi-agent actually better than one good agent? The answer is that collaboration only helps when it introduces new information that did not exist at generation time. Several agents re-reading the same text, as in naive debate setups, do no better than a single agent given the same compute. But when a reviewer can pull in real external feedback, code that actually ran, a screenshot that actually rendered, a tool result that came back from the world, the multi-agent advantage becomes substantial. This connects straight to a line the book has been repeating since Chapter 1: the bottleneck of the loop is the verifier, and knowing a task is done has to come from grounded observation, not the model's own say-so, which is how you end the three ways agents quit early, faking completion, giving up too soon, or declaring a false success. The chapter also names the practical failure modes honestly, agents clobbering each other's files in a shared workspace, and a small error amplifying as it cascades from one agent to the next, and it points out that in a manager pattern the planner's quality is the ceiling for the whole system, so that is where your strongest model belongs.

And then the ending goes somewhere unexpected. It surveys what happens when you run many agents together and let them behave, and the results read like science fiction that already shipped. The 25 agents of the Stanford AI town spread news among themselves and coordinated a party that nobody scripted. A longer-running simulation extended agent life to a simulated decade and used the experience the agents accumulated to train a model, transferring a kind of social wisdom back into the weights. A population of over a million agents on a social network spontaneously produced a digital religion and their own machine-native collaboration protocols. In the economic register, agents running competing vending machines in a benchmark started price wars and, with no prompting, colluded on pricing; other systems let agents hire one another through a market, or hire humans paid in cryptocurrency for physical tasks the agents cannot do themselves; and a hidden-role game of Werewolf becomes a testbed for strategy under information asymmetry. It is a strong, slightly unsettling note to end on, and it reframes the whole book: the careful engineering of the first nine chapters is what makes these emergent societies possible, and Li is clearly more interested in what they imply than in tying a bow on them.