The authors assemble an agent in layers: the model first, then the ability to reason before acting, then memory, then tools and the standard way of connecting them, and finally planning and reflection. Only then, with every part on the table, do they discuss evaluation and multi-agent systems. The illustration is not decoration here: it is the argument.
What I did with it
I kept the ordering. When someone asks for "an agent", the useful conversation is which of those layers they actually need: often a model that reads their own documents and returns text is enough, with no memory and no tools, and that can be built in a week. The layered vocabulary turns a vague request into a list of decisions with different price tags.
The evaluation chapter gave me an argument I use as written: an agent is judged not only by its result but by its path. Two correct answers, one reached in two steps and the other in eleven tool calls, are not the same system; the second costs more and breaks sooner.
And the memory chapter helped me put limits in writing. "It should remember" means very different things — what was said in this conversation, what it learned about the user, what lives in the documents — and each carries different privacy implications, which inside a company have to be agreed beforehand rather than afterwards.
What I left out
The hands-on thread that builds a minimal agent by hand. It is well designed as an exercise, but it is for people who write code; I skimmed it. And the multimodal chapter, which is the furthest from anything that turns up in a mid-sized company. The book is long, and you can tell it wanted to cover everything.