How context accumulates across a session. The static foundation is established before the first message; dynamic content (like tool calls, tool results, and follow-up messages) fills in as the session progresses.
figure 3-2
Each iteration of the agent loop adds tool results to the context window. The context grows with every action, and managing that growth is part of what context engineering addresses.
The MCP three-party model: The host manages isolated clients, one per server, and each server provides tools, resources, or prompts. The host enforces what each client can access.
figure 4-2
A task-matched configuration can return more than 15% of context budget to actual task content by removing tool descriptions the agent doesn't need.
The SDD framework ceremony spectrum, from lightweight conventions on the left to multi-agent enterprise frameworks on the right.
figure 7-2
OpenSpec's two-folder model separates the system's current behavior in `specs/` from proposed modifications in `changes/`, with archived changes merging back into the source-of-truth specs.
Compaction lets the system summarize your context in the dark; a scratchpad puts the same memory in a file you can read, edit, and carry into a fresh window.
figure 9-2
SDD treats the spec as a shared coordination artifact that every phase reads from and writes to, which makes it safe to run different phases on different models.
figure 9-3
One agent generates, a separate agent critiques, you filter the findings, and the work loops back until it passes a clear bar.
figure 9-4
Three levels of isolation for running agents in parallel: separate context windows, separate worktrees on one machine, and separate cloud machines.
figure 9-5
The same subagent building block arranged four ways: orchestrator-worker, sequential pipeline, fan-out/fan-in, and router.
figure 9-6
The dark factory assembles every pattern in this chapter into one self-running line: a spec goes in, agents plan, write, and test in a loop, and a reviewable change comes out.
The AI-native Team Canvas: eight areas, turning "how do we adopt AI?" into a set of decisions a team can answer together.
figure 10-2
AI rules as a tree: a spine from a shared base down through language, framework, and team/project rules, with cross-cutting concerns--testing, observability, infrastructure--branching off to the side rather than stacking on top. Everything is versioned in Git, and different projects share the base while composing their own branches.
figure 10-3
The experiment loop as a flow chart: run an experiment, and if it doesn't find something useful, discard it; if it does, the team discusses and validates it, and only if the team accepts it does it become a standard--then loop back and keep testing new things and assumptions.
figure 10-4
Before: Work moved in a straight relay from Product through Design to Engineering to QA. After: A tight loop of three roles working from a shared spec, with an agent fleet handling the mechanical work.
A low-fidelity mockup of Pulse: a catalog of team-health signals, one card per signal, aggregates only.
Figures are the author's own, drawn for the book and reproduced here for readers. They are the pre-production versions; the published edition carries O'Reilly's redraws.