Michael Albada's Building Applications with AI Agents: which chapters an FDE should read first

The book has 13 chapters, but Michael Albada’s most memorable piece of advice fits in one sentence: don’t register three hundred tools with your agent. He said it at the AI Engineer World’s Fair 2025, in a talk he himself described as a condensed version of his roughly 300-page book, then about to come out with O’Reilly.

That book is Building Applications with AI Agents, subtitled Designing and Implementing Multiagent Systems. According to Ebookpoint, the ebook came out on 2025-09-16 and runs to 354 pages. The introduction states plainly something every FDE already knows: deploying agents is still a challenge for many organisations.

So the most useful question is not whether the book is good. It is this: if you have to put an agent into a customer’s real systems in the next few weeks, which chapters will help you make the fewest mistakes?

Where does the author build agents?

Albada is now a platform architect at NVIDIA, building agent systems for chip design. Before that he was a principal applied scientist on Microsoft Security Copilot. Both settings have one thing in common: when an agent gets it wrong, the consequences are real.

That experience shows in the book’s structure. It moves from foundational chapters such as Introduction to Agents, Designing Agent Systems and User Experience Design for Agentic Systems, through Tool Use, Orchestration, Knowledge and Memory, Learning in Agentic Systems, and From One Agent to Many.

The second half covers the work few people want to do but every FDE has to: Validation and Measurement, Monitoring in Production, Improvement Loops, Protecting Agentic Systems and Human-Agent Collaboration.

In what order should you read it?

Don’t read it cover to cover. Skim chapters 1 and 2 for the vocabulary, then read chapters 4 (Tool Use) and 5 (Orchestration) closely, because those are the two decisions you must settle in your first week at the customer. Next comes chapter 9 (Validation and Measurement), before you write another line of code.

When the agent is about to go into production, move on to chapters 10 (Monitoring in Production), 12 (Protecting Agentic Systems) and 13 (Human-Agent Collaboration). Chapters 9, 10, 12 and 13 are the closest to the work of running an agent for a customer. Leave chapter 8, on multiple agents, until you have shown that one agent is not enough.

The remaining four chapters should not be skipped, just read at the right time. Chapter 3 (UX) helps once the customer’s end users start trying the agent, chapter 6 (Knowledge and Memory) when the agent needs to look up documents or remember context, and chapters 7 and 11 (Learning, Improvement Loops) are worth reading once the agent is running and you have real data to improve it with.

Point one: fewer tools make a more accurate agent

The three points below come from Albada’s talk, the condensed version of the book, and each maps to a chapter in the table of contents. The first belongs to Tool Use: he advises against registering too many tools with a single agent, because accuracy drops.

Imagine the customer is an insurer that wants an agent to handle claims, and its IT team already has dozens of internal APIs.

The natural reflex is to wrap them all as tools. Do the opposite. List the steps a member of staff actually takes with a case, say looking up the policy, checking the terms and creating a ticket, and grant only those tools. The agent has fewer options to choose between, and when it goes wrong, it is easier to find out why.

Point two: if one chain will do, use one chain

The book’s subtitle is about multi-agent systems, yet in the talk, when discussing orchestration, the author himself recommends the simplest possible architecture. If the problem fits into a single chain, he wants you to build exactly that.

For an FDE, this is advice about people more than technology. The people who maintain the system after you leave are the customer’s team. A clear sequence of steps is something they can read, debug and fix. A web of agents calling one another usually is not.

Point three: invest in evaluation before you invest in prompts

The central message of the talk is to invest more in evaluation, built on a high-quality evaluation dataset. In the table of contents this corresponds to chapter 9, and it is the chapter to read most carefully.

Go back to the insurance example. Before tuning any prompts, ask the customer for a few dozen real, completed cases, each with its correct outcome. Every time you change the model or edit a prompt, rerun the whole set and report the number to the customer, rather than saying vaguely that the agent seems better.

The talk also touches on two topics from chapters 12 and 13. On security, Albada mentions Microsoft’s PyRIT, a tool for attempting jailbreaks and red-teaming agents before release.

On working with people, he points to a common failure: agents that don’t know when to hand work to a human. In his view, important cases should be pulled out of the automated flow so that a reviewer can check them.

Who should read it, and how to turn it into a career advantage

The book suits engineers who have called an LLM API a few times and are now responsible for an agent running on real data. If you are preparing to move into an FDE role, read chapters 4, 5 and 9 in the same week, then build a small agent that applies all three points.

On your CV, don’t write “experience with AI agents”. Write how many tools you cut, how many cases your evaluation set contains, and which types of request are routed to a human reviewer. When reading job descriptions, look for words such as evals, monitoring or human-in-the-loop. They signal that the company is hiring someone to do the second half of the book.

The first half of the book teaches you how to build an agent; the second half teaches you how to keep it alive at a customer site. That is most likely the part of the job customers need FDEs for most.