14 chapters across 7 parts (Part 0 through Part VI). Parts are warranted: the book covers distinct architectural layers (contracts → durability → tools → composition → distribution), each with its own design vocabulary and failure modes. The parts mirror the order in which a runtime designer encounters these concerns — you can't think about distribution until you've settled the turn model.
Why throw away 132 working files? This part establishes the conditions under which incremental improvement fails. Chapter 1 shows the concrete symptoms — topology baggage, mid-migration shapes, a turn that can't survive interruption. Chapter 2 shows the diagnostic method — shape audits of other runtimes that reveal what's settled independently of any one implementation.
What the reader learns: How to evaluate whether a system needs a rewrite or a refactor. The shape audit as a decision-making tool.
Connects forward to: Part I, which builds the primitive the shape audits validated.
What shape should an agent runtime be? This part reads the contracts, the construction seam, and the turn — the three things that define a runtime's identity. The comparison is always v1 vs v2: what survived, what was cut, what was reshaped. Survival through a rewrite is stronger evidence than any design document.
What the reader learns: How to design a minimal set of contracts that makes the wrong assembly unrepresentable. Why the construction seam is the architecture. What makes a turn durable vs fragile.
Connects forward to: Part II, which adds durability to the turn model established here. Part III, which shows how tools and sandbox are wired through the construction seam.
How do agent turns survive crashes? This is the part that separates toy agent systems from production ones. The journal makes turns checkpointed; the resume classifier makes recovery automatic. Together they turn the turn from an await into a state machine.
What the reader learns: How to design a turn journal with phases that correspond to points of no return. How to build a pure-function recovery classifier. Why repair without re-execution is the hardest problem.
Connects forward to: Part IV, which extends the same durability model to multi-step workflows via deterministic replay.
How does an agent touch the world safely? Tools are the agent's capabilities; the sandbox is the boundary between the agent and the filesystem. This part shows how both evolved from values to contracts — tools from direct functions to trust-scoped factories, sandboxes from topology-coupled implementations to backend-agnostic APIs.
What the reader learns: Why tools should be factories bound at construction time. How to design a sandbox contract that's independent of deployment topology. The control server pattern as an alternative to filesystem access.
Connects forward to: Part V, which shows how the sandbox contract enables distribution without the runtime knowing.
How does an agent orchestrate work? v1 had single-threaded delegation. v2 adds a workflow system with parallel/pipeline primitives, coordinator-driven nodes, and deterministic-replay resume. The isolate chapter examines the trust boundary for agent-authored workflow scripts.
What the reader learns: How to make workflows durable using the same journal model from Part II. Why deterministic replay requires banning non-deterministic operations. How to run untrusted code in a sandboxed subprocess with specific constraints for specific fears.
Connects back to: Part II's durability model (workflows use the same journal). Part III's sandbox contract (the subprocess sandbox is a different kind of sandbox).
How does a runtime become a fleet? This is the part that justifies all the abstraction work in Parts III and IV. Because the runtime talks to contracts (SandboxApi, ModelProvider), distribution is a separate layer with its own transport (JSON-RPC), its own security model (firewall), and its own lifecycle (flycast autowake). v1's mistake — baking Fly topology into the runtime — is the negative example.
What the reader learns: Why distribution is an architectural layer, not a deployment concern. The JSON-RPC + control server + SDK broker stack. How to validate a network model end-to-end.
Connects back to: Part III's sandbox contract (distribution implements it). Part 0's rewrite motivation (topology baggage was a primary driver).
What does the shape tell us about the future? The cross-harness synthesis identified seven gaps. Four are additive (G0, G1, G3, G6) — implementation catching up to contracts that already name the shape. G2 requires a new context-assembly seam (the recall/contextProviders call site) that does not yet exist — structural work, not a wire-up. G4 is a new edge the product thesis requires; G5 would reshape the subagent primitive and is deliberately deferred. This part reads each gap for what it reveals about the runtime's current shape — declared intentions without wiring, a telemetry bus without lifecycle hooks, a sandbox without a callback channel. The conclusion names three design moves that recur across every part.
What the reader learns: How to read a gap analysis as a shape validation (additive gaps = correct primitive; structural gaps = think harder). The three reusable design moves. Why presenting a system mid-construction is honest, not incomplete.
Connects back to: Part 0's shape audits (the gaps come from the same analysis). Every prior part (the conclusion replays the full arc).