How to Read This Book
Two books in one. A narrative build across twenty parts, and a catalog you consult forever. Plus the short route if you are in a hurry.
This is two books sharing a table of contents, and they want to be read differently.
Parts I–XX: read in order
A narrative. Each part assumes the ones before it, and the running project, Atlas, accumulates across all of them.
| Parts | Arc | What you come out with |
|---|---|---|
| I–II | The model, and the loop | You can build an agent with no framework and explain every line |
| III–V | Context, retrieval, knowledge | You know where an answer lives before you go looking for it |
| VI–IX | Workflows, graphs, tools, MCP, A2A | You can decide what should be an agent, design what it may do, and choose the right remote boundary |
| X–XII | Durable execution, humans | It survives crashes, deploys, and a three-day wait for approval |
| XIII | Interface | People can use it across ability, language, browser, and voice, and trust what they see |
| XIV–XVII | Evals, tracing, reliability, security | You can prove it works and defend it when it is attacked |
| XVIII–XX | Production, governance, rollout, multi-agent, capstone | You can run it, introduce it into real work, and know when to stop adding agents |
If you skip anything, do not skip Part I. Everything after it is a consequence.
Part XXI: consult, don't read
A reference catalog. Sixty-six entries across nine categories, each self-contained and written to the same shape:
Problem · what breaks · Forces · the constraints in tension · Solution · the shape of the fix · Code · both tracks · Trade-offs · what it costs you · When not to use it · the honest limits · Related · what to read next.
Read one when you have the problem it names. Reading the catalog end to end is possible and not especially useful.
In a hurry?
The book is large on purpose. It is meant to still be useful in year two. If you need to ship now, the core path is the third of it that gets you there, with a table of what you are deferring and when to come back for it.
The two code tracks
Nearly every sample appears in TypeScript and Python. Pick a tab and the whole book follows. The choice persists across pages and sessions.
// TypeScript 4.9+: samples use the Vercel AI SDK, LangGraph.js,
// the Temporal TypeScript SDK, and pgvector over node-postgres.
const result = await atlas.run(request);Both floors are load-bearing rather than decorative. The Python track annotates optionals as str | None throughout, which is 3.10. The plan schema builds its closed vocabulary with Literal[*TOOL_NAMES], which is 3.11. On anything older, that line is a syntax error rather than a subtle incompatibility. The floor is not only a syntax matter. The Temporal LangGraph plugin needs 3.11 at runtime for interrupts and its functional API, and it degrades to a warning rather than an error below that. TypeScript is the lighter ask. Only the satisfies in Resumable Activity needs anything past the language you are probably already on.
The tracks are equivalent in behavior, not transliterated line by line. Sometimes an ecosystem genuinely does something differently, as with the timeout semantics in Agent as Entity Workflow. There the sample follows local idiom, and the text calls the difference out rather than papering over it. Appendix A maps the concepts across.
Which track should you pick?
If you are building the user-facing side, pick TypeScript. The AI SDK has no Python equivalent. If you are building retrieval, ingestion, and evaluation tooling, pick Python. That ecosystem is deeper. Most production systems end up with both, split along exactly that line, which is why this book carries both rather than choosing for you.
Recurring devices
The framework check. Where more than one approach is defensible, a box lays them side by side: plain code, LangGraph, Temporal, the AI SDK, MCP, or A2A. It says which one this book picks and why. The point is to leave you able to evaluate the next framework, because there will be one.
Decision tables. Every "which one should I use" question resolves to a table, and Appendix C collects all of them for when you remember the question but not the chapter.
Illustrative numbers say so. Prices, context sizes, and latencies change. Where a concrete figure makes an example legible, the text marks it illustrative.
Time-sensitive claims carry a date and a primary source. Product names, preview status, model behavior, and protocol revisions are snapshots. The surrounding mechanism and decision criteria are the lesson. When the snapshot changes, follow the primary source and re-run the chapter's acceptance case before changing architecture.
Opinions say they are opinions. When the book says a common approach is wrong, that is a position, and it carries its reasoning so you can disagree on the merits.
Diagrams show mechanism. Every figure earns its place by making something clearer than the paragraph beside it could. If one is only decoration, it should not be there.