Part 5: Patterns and Use Cases#

Parts 1 through 4 built a toolkit. Part 1 argued for designing the network as a system rather than configuring it device by device. Part 2 defined the building blocks: the Source of Truth, the Execution layer, Observability, Orchestration, Presentation, and the network itself. Part 3 turned those blocks into a platform that scales and survives failure. Part 4 addressed the people who operate it. Everything so far was preparation.

Part 5 puts the toolkit to work. It introduces no new building blocks. It shows how the existing ones compose into systems that watch the network and act on it with progressively less human involvement. The rule for this part is simple: we reference the mechanisms from earlier parts, we do not re-explain them. How drift detection, circuit breakers, or wave deployments work is Parts 2 and 3. Here, we assemble them.

One scenario, three chapters#

A single scenario runs through all three chapters, the way the firewall change ran through Part 3. Picture a content-delivery network with thirty points of presence spread across the globe. Each one reaches its users over the public internet through several ISPs, usually three, sometimes four, some of them Tier 1 transit and some, where a region offers nothing better, smaller local providers. None of them is a backup: under load a point of presence spreads its users across all of its ISPs at once, because it needs all of them. Every path inherits the internet’s variability, latency, packet loss, the occasional ISP brownout, and a bad path is something users feel as a slow page. To watch it, every point of presence probes every other one’s ISP uplinks, so each uplink is judged from thirty independent vantage points rather than by the router behind it, and BGP is adjusted to shift users off an ISP that enough remote sites report as degraded, while always keeping enough ISPs in service to carry the load. That is the whole scenario, and it escalates cleanly from one chapter to the next.

Two axes: a widening loop and a shared intent#

The three chapters move along two axes at once.

The first axis is one control loop that widens as the human moves further out, which maps onto the Confidence Ladder from Chapter 13. Chapter 15 closes the loop on configuration intent: is the network still equal to what we declared? Chapter 16 closes it on operational health: the configuration is correct, but is the service still healthy? Chapter 17 closes it on the decision itself: what should the network do next? Execute a fixed loop, then recover from faults inside it, then decide its actions.

The second axis is one intent model that gains a new author at each level. The effective intent the network is held to is the sum of two layers: effective intent equals declared intent plus dynamic overrides. Chapter 15 owns the declared layer, the policy a human wrote. Chapter 16 adds the Dynamic Intent Layer, a machine-authored overlay computed from the actual state of the network rather than from a person: when an ISP degrades, the overlay temporarily shifts users off it onto the point of presence’s other ISPs, then expires when it recovers. Chapter 17 lets an agent propose changes to that same intent, always through the governed pipeline, never out of band. One model, three authors: a human, a condition-driven machine, and a supervised agent.

These two axes are what keep Part 5 from being three disconnected essays. Every chapter reads the same intent, reconciles against the same effective state, and earns its place on the Confidence Ladder with the same evidence: the Automation Track Record from Chapter 11 and Chapter 13.

The three chapters#

Chapter 15 builds the closed loop. It models the network’s per-ISP routing intent in the Source of Truth, renders it to device configuration, deploys it, then retrieves both the real running configuration and the actual route state and compares them against intent. The Configuration Lifecycle Pattern (design, validate, deploy, verify, detect, reconcile) is the loop, and a divergence between intent and reality is what drives it. No probes yet: at this level, drift is a comparison.

Chapter 16 handles the failures a configuration check cannot see. An ISP at a point of presence can degrade while its BGP session stays up: loss climbs, latency doubles, and the configuration is still perfectly correct. This chapter introduces the full mesh of synthetic probes that lets the other points of presence see the bad ISP by consensus, and the Dynamic Intent Layer that shifts users off it, without a human, without fighting the Chapter 15 loop, and without ever dropping the point of presence below the ISPs it needs to carry its load. And the thresholds that decide what counts as degraded are not the network team’s to set alone: the team that runs the HTTPS service tunes its own tolerance through an API, which is where automation as a product (Chapter 14) enters Part 5.

Chapter 17 removes the predefined loop. Instead of executing a fixed policy, the system decides how best to spread users across each point of presence’s ISPs, using a numeric optimizer paired with an agentic reasoning layer, the payoff for the agentic orchestration introduced in Chapter 7. The chapter is mostly about limits: what a model may decide alone, what it must escalate, and why an autonomous action that moves real user traffic always resolves to a named human.

What Part 5 leaves you with#

By the end, the network runs a loop a human designed, defends its own health when a path degrades, and, at the top rung, proposes its own decisions within bounds it cannot exceed. That is the arc the whole book has been building toward: not a network that runs itself unsupervised, but one that earns each increment of autonomy with evidence and stays accountable at every level.

Chapter 15 begins with the loop.

💬 Found something to improve? Send feedback for this chapter