The 36-Chapter Map: What Production AI Taught the Living Book

Most books about artificial intelligence are out of date before the reader reaches the final chapter. They describe a model, a prompt trick, or a framework, and by the time the book is printed the model has been replaced, the trick no longer works, and the framework has changed its interface twice. This is not a failure of the authors. It is the nature of the subject. The model layer moves faster than any publishing cycle in history.

The Context Advantage was designed around a different bet. It does not try to keep up with models. It is written about the four things that do not change when the model changes: what your organisation means (Context), what your agents are allowed to do (Control), what the work actually costs (Cost), and whether you can leave (Choice). Those four questions were true with the first generation of chat assistants, they are true with today's agent platforms, and they will be true with whatever ships next quarter.

That bet is why the book is a living book rather than a fixed edition. When production teams discovered something the book did not yet cover, a chapter was added. When a chapter turned out to be too abstract for a working engineer, it was deepened. The result, as of today, is 36 chapters in seven parts. This essay is a tour of that whole map, with a focus on the newest additions and on how to use the book when you have a real problem on your desk rather than an afternoon to read.

If you have never opened the book, start with the free opening chapters: Chapter 1 on the day data started talking back, Chapter 2 on what agents really are, and Chapter 3 on why smart models still need smart systems.

Every chapter in the book hangs off one frame, introduced in Chapter 4. It is deliberately simple, because a frame that needs a slide deck to explain is a frame nobody uses in a meeting.

**Context** asks whether the system knows what your business means. Not what your data contains, but what it means: which customers count as active, which revenue is recognised, which exception the finance team granted last year and why.

**Control** asks whether the system can only do what it should. Access control decides what an agent can see. Action control decides what an agent can change, approve, send, or delete, and that is a far harder problem.

**Cost** asks whether the economics still work at scale. A pilot that costs forty dollars a day becomes a production system that costs forty thousand a month, and the difference is almost never the price per token.

**Choice** asks whether you can change your mind. Models, vendors, clouds, and frameworks will all change. The question is whether your accumulated meaning, your permissions, and your evaluations can move with you.

The reason this frame survives model churn is that none of the four questions is about intelligence. A smarter model does not tell you what active customer means at your company. A cheaper model does not decide which agent may issue refunds. A newer model does not make your prompts portable. The frame is stable because the problems are organisational, and organisations change slower than models.

The first major expansion came from a simple observation in the field. Frontier models were converging. Teams that switched between top models saw smaller and smaller differences in output quality. If the model was no longer the differentiator, what was? The answer the book already gave — context — was right, but it was not specific enough. Three chapters were added to Part 2 to make it specific.

Chapter 10: Institutional Memory Is the Moat names the durable asset precisely. It is not your documents. Every company has documents. It is the accumulated why: why a definition changed, why an exception exists, why a decision was reversed, who owns a rule. That history cannot be bought or downloaded, and it is what turns a generic model into one that answers like a senior colleague.

Chapter 11: Context Is a Living Layer, Not a Document addresses the reason most context projects decay. Teams write a beautiful glossary, load it into a retrieval index, and declare victory. Six months later definitions have drifted, a product line has been renamed, and the agent is confidently citing a policy that no longer exists. The chapter argues for treating context like code: owners, versions, review cycles, deprecation, and tests.

Chapter 12: Portable Context closes the loop with Choice. If context is your most valuable AI asset, it cannot live only inside one vendor's runtime. The chapter describes an open contract for context — definitions, permissions, provenance, and evaluations expressed in a form any model and any agent framework can read.

Read together, these three chapters change the job description. The context layer is not a project with an end date. It is a product with a roadmap, and somebody has to own it.

The second expansion came from engineers rather than executives. Readers who had absorbed the strategy asked a fair question: how do I actually build this? Strategy without mechanics sounds wise and ships nothing. Two deep, practical chapters were added to Part 7.

Chapter 35: Retrieval Mechanics goes underneath every context strategy. It covers how chunk size and chunk boundaries change what a model can find, why pure vector search misses exact identifiers such as product codes and policy numbers, how hybrid search combines keyword and semantic retrieval, how fusion merges the two ranked lists, and how a reranker reorders the candidates before anything reaches the model. Above all it insists on measurement: recall at k, precision of the final context, and an evaluation set that tells you whether a change helped or hurt.

Chapter 36: Compaction and the Token Budget treats the context window as a budget rather than a bucket. Long-running agents accumulate history, tool outputs, and retrieved documents until the window fills and quality silently degrades. The chapter shows how to allocate tokens across instructions, retrieved evidence, and conversation history; how to compact old turns without dropping commitments the agent made; and how to detect degradation before a user does.

These two chapters pair directly with earlier ideas. Chapter 6 argued that business meaning beats raw retrieval; Chapter 35 shows how to make retrieval carry business meaning. Chapter 20 argued for budget-aware design; Chapter 36 applies that discipline inside a single conversation.

Part 3 is the section readers most often skip and most often regret skipping. Enterprise governance was built for humans who click buttons. Agents do not click buttons; they call tools, many times a minute, and they do it with whatever authority they were given.

Chapter 13 explains why existing governance is necessary but insufficient. Chapter 14 makes the central shift from access control to action control: the question is not only which tables an agent can read, but which actions it can take, at what size, and with whose approval. Chapter 15 turns that into practice with guardrails, approval gates, and audit trails, and Chapter 17 is explicit about when a human must stay in the loop.

The production lesson that kept recurring was blast radius. An agent with a small, reversible scope can be allowed to move quickly. An agent that can send payments, change prices, or email customers needs limits on size, rate, and reversibility, plus a named human who owns each piece of context it relies on. Chapter 16 frames all of this as designed trust: confidence that is earned with evidence, not assumed because the demo went well.

Every quarter, the price per token falls, and every quarter, many AI bills rise. Part 4 explains the paradox. Chapter 18 traces where the money actually goes: retries, oversized context, agents that loop, evaluation runs, and the human time spent reviewing wrong answers. The cheapest token in the world is expensive if the answer is wrong.

Chapter 19 argues that not every task needs the best model. Routing simple requests to smaller models and escalating only the hard ones can cut costs dramatically without hurting quality, provided you measure quality per route. Chapter 20 asks teams to design for a budget from the first day, and Chapter 21 gives a practical way to trade accuracy, latency, and spend against each other.

The newest framing, which Chapter 36 reinforces, is the cost per correct outcome. Tokens are an input. A resolved ticket, an accurate forecast, or a correct reconciliation is the output. Teams that report cost per correct outcome make better decisions than teams that report cost per million tokens.

Part 5 is about the decisions that are easy today and expensive tomorrow. Chapter 22 shows how lock-in accumulates, often through convenience rather than contracts. Chapter 23 makes openness a strategy: open formats, open interfaces, and open protocols for tools and agents.

Chapter 24 asks you to build for change you cannot predict: keep business rules out of model-specific prompts, keep evaluations independent of any one vendor, and keep a second model tested and ready. Chapter 25 keeps the book honest about platforms. You will build on a real platform — Databricks, Snowflake, AWS, Azure, Google Cloud, or open source — and the chapter maps the concepts to each without pretending the choice does not matter.

Chapter 12 now acts as the bridge between Part 2 and Part 5. Portable context is how Choice becomes real. Open data with closed meaning is still lock-in.

Part 6 is written for the people doing the work. Chapter 26 describes how the data professional's role is changing, from building pipelines that move data to building systems that make data understandable to machines. Chapter 27 lists the skills that outlast tools, Chapter 28 teaches how to explain AI to leaders without jargon, and Chapter 29 lays out a roadmap for beginners, intermediates, and senior professionals.

The role at the centre of this shift, first named in Chapter 9, is the Context Engineer: the person who owns definitions, retrieval quality, permissions, and evaluations for the agents an organisation runs. The arrival of a formal Databricks Context Engineer Associate certification confirmed that this is now a recognised job, not a thought experiment.

To support that path, the book now has a companion practice exam suite: a large question bank mapped to the exam domains, a standard mode, an endurance mode for full-length rehearsal, attempt history, and a drill mode that replays the questions you missed. Chapters 35 and 36 were written partly so that every exam domain has a chapter that teaches it properly rather than a summary that only names it.

Part 7 is where the book stops arguing and starts instructing. Chapter 30 gives a nine-step reference architecture for a trusted production agent, from intake and identity to retrieval, action gates, evaluation, and audit. Chapter 31 is a week-by-week guide to building your first context layer in eight weeks.

Chapter 32 is a scoring rubric you can run on any AI project in an hour, and it is the fastest way to find which of the four C's is your weakest. Chapter 33 is a 90-day learning plan: thirty days to understand, thirty to build, thirty to design. Chapter 34 handles the moment one agent is not enough and several have to cooperate without losing context at the handoffs.

Chapters 35 and 36 complete Part 7 with the runtime mechanics. A team that reads Part 7 alone can ship. A team that reads Part 7 after Parts 2 through 5 ships something it can still defend a year later.

Nobody needs to read the book front to back before starting. Use the problem you have today as the entry point.

**Our agent gives confident wrong answers.** Start with Chapters 5, 6, and 35, then Chapter 11 to keep the fix from decaying.

**Leadership is nervous about letting agents act.** Start with Chapters 14, 15, and 17, then Chapter 30 for the architecture.

**The AI bill is growing faster than usage.** Start with Chapters 18, 19, and 36, then Chapter 20 for the design habits.

**We are worried about being locked in.** Start with Chapters 12, 22, and 24, then Chapter 25 to map it to your platform.

**I want to become a Context Engineer.** Start with Chapters 9, 26, and 29, then work through the practice exams with Chapters 35 and 36 open beside you.

**We do not know where we stand.** Run the Chapter 32 assessment first. It will tell you which of the paths above to take.

The book will keep growing in the same way it has so far: where production pushes on it. The rule for a new chapter is strict. It must answer a question working teams are asking, it must survive the next model release, and it must connect to at least one of the four C's in a way the existing chapters do not.

That rule is also why this book will not become a catalogue of tools. Tools are the weather. The four C's are the climate. Readers who own the book receive every update without buying a new edition, and every new chapter is marked in the table of contents so you can see what changed.

If you take one idea from this tour, take this: the organisations that win with AI will not be the ones with the best model. Everyone will have access to the best model. They will be the ones whose meaning is clear, whose agents are governed, whose costs are understood, and whose options stay open. That is what all 36 chapters are about.