A reader’s edition
Building AI systems that deserve to be trusted
Most AI systems look simple from the chat box. A question goes in; an answer comes back. The difficult work is hidden between those two moments.
This book opens that hidden space. It follows information as it becomes context, context as it becomes an answer, and an answer as it becomes an action. Read straight through for the full argument, or begin with the part closest to the system you are building.
Part One
The model and its world
Before we build a system around a model, we need an honest picture of what the model receives—and what it never sees unless we provide it.
- Read chapter ↗
LLM foundations
The machine sees a window, not a world
A language model can sound as though it remembers everything. It does not. It receives a finite packet of tokens, predicts what should follow, and loses the packet when the call ends. We begin by looking at that small, temporary world.
- Read chapter ↗
Context engineering
The work that happens before the prompt
A polished instruction cannot repair missing facts, the wrong file, or an unsafe tool. The useful work happens earlier: choosing which evidence, history, rules, and capabilities should reach the model for this particular request.
Part Two
Giving an answer somewhere to stand
Retrieval turns a fluent model into a reader with sources. The difficulty is not storing documents; it is preserving meaning and finding the right evidence under pressure.
- Read chapter ↗
RAG
An answer with somewhere to stand
A customer asks a question the model was never trained to answer. Instead of asking it to guess, we search our own material, place the best evidence beside the question, and require the answer to stay close to what was found.
- Read chapter ↗
Production retrieval
Search becomes an engineering system
The demo worked because the answer was easy to find. Production is less kind: PDFs lose their tables, chunks split the needed sentence, filters hide the right record, and a plausible result outranks the correct one. This chapter follows each failure to its source.
- Read chapter ↗
Vector search
Meaning becomes a coordinate
An embedding gives a piece of text a location in a mathematical space. Nearby points may express similar ideas, but “near” is not the same as “true” or even “useful.” We learn what the distance can tell us—and what it cannot.
Part Three
When the model can act
A model becomes an agent when its output can choose the next operation. That freedom is useful only when the surrounding application keeps a firm hand on permissions, state, and stopping rules.
- Read chapter ↗
Agent systems
The next step is no longer fixed
A workflow follows the route we drew. An agent chooses a route while it is moving. We examine when that choice earns its cost, how a tool result changes the next decision, and why the predictable parts should remain ordinary code.
- Read chapter ↗
MCP and tools
A tool is a permission, not merely a function
A clear name and schema help a model choose the right tool. They do not decide whether the tool should be available, whether the caller may read the data, or whether a human must approve the action. Those decisions belong to the host application.
Part Four
When systems need a shared language
A tool call, a delegated task, and a user interface cross different boundaries. Protocols give each boundary a contract without pretending that discovery is the same as trust.
- Read chapter ↗
A2A
An agent introduces itself, then accepts the work
An Agent Card says what a remote agent claims to do and how to reach it. A task gives the delegated work an identity, a lifecycle, and concrete artifacts. Between those two objects lies the difficult work of trust, authorization, and recovery.
- Read chapter ↗
A2UI
The answer becomes an interface
Instead of sending executable frontend code, an agent describes a surface using components the client already knows. The renderer validates that small vocabulary, supplies native behavior, and returns user actions to an application that still controls permission.
Part Five
Two frameworks, two kinds of help
LangChain gives common names to the pieces of an AI application. LangGraph makes the movement between those pieces explicit. Neither framework replaces the architecture you still have to choose.
- Read chapter ↗
LangChain
A shared vocabulary for the application
Messages, models, tools, retrievers, and runnables appear in nearly every AI application. LangChain gives them compatible interfaces. We learn those interfaces one at a time, then decide where the abstraction saves work and where plain Python says more.
- Read chapter ↗
LangGraph
Give the loop a map
Once a workflow branches, waits, retries, or asks a person for help, the hidden loop becomes hard to trust. LangGraph draws that loop as state, nodes, and edges, then saves enough of the journey to continue after the process stops.
- Read chapter ↗
AI ecosystem
Choose the shelf before the library
Agent frameworks, evaluation harnesses, prompt platforms, and observability tools often advertise the same language. We separate the jobs, compare the control models, and ask what evidence a new dependency must provide before it enters the system.
Part Six
Evidence after the answer
A convincing response is not proof. We need tests that isolate where quality changed and traces that show what the system actually did for a real request.
- Read chapter ↗
Evaluation
Trust begins with a test case
A RAG system has two chances to fail: it may retrieve the wrong evidence, or it may misuse the right evidence. We measure those jobs separately, compare changes on the same cases, and stop calling a result “better” merely because it reads well.
- Read chapter ↗
Classification metrics
One score can hide the class that fails
Five correct labels out of eight sounds clear until the rare fraud class disappears inside the average. A small confusion matrix shows what accuracy, precision, recall, micro-F1, macro-F1, and weighted-F1 remember—and what each one forgets.
- Read chapter ↗
LLMOps
What the system did, and why
When a production answer fails, the final text is only the last page of the story. The trace must reveal the query, retrieved evidence, tool calls, latency, tokens, model version, and policy decisions that produced it.
Part Seven
The boundary around the system
The final chapters ask a practical question: what must remain true when the model misunderstands the request, the evidence contains instructions, or an external service fails?
- Read chapter ↗
Prompt injection
The instruction hidden inside the evidence
An email, webpage, or retrieved document may contain words that sound like commands. The model cannot reliably decide which words deserve authority. We therefore separate instructions from data and enforce access and tool policy outside the prompt.
- Read chapter ↗
Production delivery
The morning after the demo
The useful question is not whether the demo answered once. It is whether the team can release a change, detect a regression, explain a failure, control cost, protect customer data, and recover without turning every incident into an investigation.