17. Autonomous Networks#

The traffic optimizer was supposed to save money. The network’s ISPs did not all cost the same; at many points of presence one provider was roughly 30% cheaper per bit than the others, and most nights the network ran well under capacity. So the team added an optimizer that re-planned, during the low-traffic window, how each point of presence spread its users across its ISPs, shifting more of them onto the cheaper providers wherever the paths were good enough. It worked. The monthly transit bill dropped, and for some weeks nothing went wrong.

Then, one night, the optimizer shifted the cdn-eu prefix set almost entirely onto the cheap ISP at Frankfurt. At 3 a.m. that ISP looked fine: low load, latency within a few milliseconds of the others. By the optimizer’s objective, minimize cost subject to the paths being good enough, the plan was optimal. At 9 a.m., when European traffic ramped up, the cheap ISP turned jittery under load. Latency was acceptable on average but terrible at the 95th percentile, which is exactly the metric a content-delivery service lives and dies by. The p95 page load for European users went from 40 milliseconds to 90, and stayed there, because the optimizer had no reason to move the users back. It had done precisely what it was told. What it was told was incomplete: nobody had given it the jitter budget for cdn-eu, and nobody had made it simulate the plan under peak load before applying it.

That is the failure mode of an autonomous network, and it is not a bug. The optimizer did not malfunction. It honored its objective and violated one nobody had encoded. The scariest autonomous failures are the optimal ones, because the system did exactly what you asked and the gap was in the asking. This chapter is about the discipline that closes that gap, and it spends most of its length on limits rather than capabilities, because at this rung of the Confidence Ladder (Chapter 13) the limits are the engineering.

It is the third loop of Part 5, and it does not replace the first two. It extends them. Chapter 15 and Chapter 16 are deterministic loops that follow rules a human wrote: match the config to intent, drain an ISP when a quorum says it is bad. Where a rule exists, the rule runs, and it should, because a rule is cheaper, faster, and auditable. Autonomy is for the residual: the cases the rules do not cover, where there are several imperfect options and none is obviously right, and a plan has to be chosen rather than looked up. This chapter builds that decision layer, shows the two kinds of model inside it, wires it into the platform through the same governed interfaces everything else uses, and then spends its back half on the bounds that keep it safe. It is the payoff of the agentic orchestration named in Chapter 7 section 7.2.7.

17.1 From Fixed Loop to Decision#

At every rung below this one, a human authored the loop’s actions. The engineer decided that a drifted config should be reconciled, that an ISP degraded past a threshold should be drained. The machine executed those decisions faithfully (that’s what automation is about). At this rung the human stops authoring the actions and starts authoring the bounds: the constraints the system must never violate and the objectives it should pursue within them. The system chooses the action.

That is a genuine shift, and it changes what can go wrong. A deterministic loop fails in ways you can enumerate: it reverts a change it should not have, it flaps a marginal ISP. A decision layer fails in ways you did not think of, because its whole purpose is to handle cases you did not pre-script. Non-determinism is the price of generality, and it is why the guardrails in 17.5 are not an appendix to this chapter but its center.

The layering matters. Autonomy sits on top of the fixed loops, not in place of them. When the situation matches a rule, the rule wins, because determinism is a feature: it is testable, explainable, and cheap. The agent is invoked for the cases with no rule, and even then it does not act directly. It proposes, the proposal is simulated and gated, and only then does it become a change, through the same pipeline a human’s change goes through.

Two consequences of that layering are easy to miss, and both matter operationally:

• The agent has to be invoked by something, and that trigger is itself governed. The healing loop of Chapter 16 hands off to the agent exactly when its binary rule runs out: when it wants to drain an ISP but the Minimum-Service Floor or the capacity check forbids it, so there is a genuine tradeoff to decide rather than a threshold to trip, or when a scheduled optimization window opens. The agent does not wander the network looking for things to improve; it is called for a bounded question.
• Because autonomy sits on top, its failure is not an outage. If the agent or the optimizer is unavailable, the deterministic loops keep running on the last approved plan: the network still conforms and still heals, it just stops optimizing until the layer returns. Building autonomy as an extension rather than a replacement is what makes that graceful degradation free.

graph LR
    TRIG[Trigger<br/>no rule covers this]
    AGENT[Agent: frame problem<br/>gather context]
    OPT[Optimizer<br/>plan under constraints]
    SIM{Simulation<br/>+ risk tier}
    APPLY[Propose gated write<br/>through pipeline]
    HUMAN[Escalate to<br/>named human]

    TRIG --> AGENT --> OPT --> SIM
    SIM -->|within bounds, low risk| APPLY
    SIM -->|near a bound or high risk| HUMAN

17.2 The Two-Component Model#

“The AI decides” is not an architecture. Pull it apart and there are two very different components, with different properties and different risks:

• The first is numeric. It forecasts per-ISP performance from the synthetic-monitoring history built in Chapter 16, and it solves an optimization: spread each prefix set’s users across the available ISPs so as to minimize cost, subject to the Minimum-Service Floor, the consumer SLO tolerances, and the capacity of each ISP. This is where the actual decision math lives, and it is the more trustworthy half precisely because it is constrained and testable. You can run it against held-out history and check its plans. It is closer to an optimizer with a forecast than to anything mysterious.

• The second is agentic. It is the Large Language Model (LLM)-based reasoning layer from Chapter 7 section 7.2.7, and its job is not to compute the numbers but to run the decision: frame the problem, gather the intended state from the Source of Truth (SoT) and the operational data from Observability, decide what constraints apply right now, invoke the optimizer as a tool, interpret the result, explain it, and hand it to the guardrails. It handles the messy, underspecified parts that a solver cannot: is this even a situation that should be optimized, or one that should be escalated?

Concretely, the optimization the numeric component solves has one quantity to minimize and everything else as a constraint:

minimize   total_cost = sum over isp of ( bytes_on[isp] x price_per_byte[isp] )

subject to:
  reachability:  users of a prefix ride only ISPs that carry that prefix
  floor:         active_isps(prefix) >= min_service_isps(prefix)
  capacity:      load(isp) <= capacity_gbps[isp] x safe_utilization
  performance:   forecast_p95(prefix, isp) <= tolerance(prefix)
  stability:     apply a plan only when its cost gain clears a set margin

Cost is the only quantity minimized. Reachability, the floor, capacity, and performance are hard constraints, satisfied or the plan does not exist, which is the distinction section 17.5 turns into the chapter’s central guardrail. The forecast_p95 term is the numeric model’s other half, learned from the synthetic-monitoring history; the optimizer is only as trustworthy as that forecast, which is why 17.3 trains it on measured outcomes and 17.5 never ships its plan without a canary.

Keeping the two separate is a safety property, not a diagram convenience. The numbers come from the optimizer, which is deterministic and auditable. The agent decides when to run it, with which constraints, and whether to trust what comes back, and its judgment is bounded by the gates in 17.5. You get the generality of an agent without staking a routing decision on an unexplained inference, because the routing math is not the agent’s to invent.

The opening story reads differently in this light. The failure was not “the AI went rogue”. It was an optimizer given an incomplete objective, cost with no jitter constraint, and a decision layer with no simulation gate. The fix lives in both components: encode the jitter budget as a constraint the optimizer must satisfy, and make the agent simulate before it proposes.

17.3 Influencing and Training the Models#

The two components learn in different ways, and conflating them is a common mistake.

The numeric models are trained. The forecaster learns from the synthetic-monitoring history; the optimizer’s cost and performance models are fit from measured outcomes and from the Automation Track Record of Chapter 11 and Chapter 13, which record how past plans actually turned out. They are retrained on a cadence and, crucially, they can be evaluated: hold out a period of history, ask the model to plan it, and compare against what happened.

The agentic layer is mostly not trained; it is influenced. You shape its behavior through the context you retrieve for it (the current intent, the active tolerances, the floor, the runbooks), through the tools you give it, through guardrails, and through examples, including the corrections a human makes when the agent escalates. Fine-tuning a specialized forecaster is often worth it; fine-tuning the general reasoning layer rarely is, when the same effect comes from better context and tighter tools.

Here is the connection that makes autonomy possible at all, and it runs straight back through the book. A model is only as trustworthy as the data it learns from, and the data that trains and evaluates these models is the audit trail built for governance: the Automation Track Record and the Provenance Chain from Chapter 12. Those were introduced to answer an auditor. They turn out to be the labeled, tamper-evident record of what the automation did and what resulted, which is exactly the corpus you need to train and validate a decision model safely. The governance you built to be compliant is the same governance that lets you be autonomous. Skip it, and you are training on unlabeled guesses.

Just as running an automation in read-only mode builds confidence in what it will do before you let it act, you can apply the same principle to an agentic system: watch its reasoning and its proposed actions first, and grant it the authority to act only once that reasoning has earned trust.

17.4 Acting Through the Platform: MCP Interfaces#

An autonomous agent that reaches into devices directly is a security incident waiting to happen. The agent acts the way everything else in this book acts: through governed interfaces, with a scoped identity, fully audited. The mechanism is a set of Model Context Protocol (MCP) tool surfaces, one per building block, each least-privilege. An MCP tool surface is not a REST endpoint the agent calls in a sequence fixed in code; it is a set of typed tools the agent chooses among at runtime, deciding which to invoke and in what order based on the result of each call (Chapter 8 section 8.2.1.5 draws the REST-versus-MCP distinction in full). Each surface is exposed the way Chapter 8 describes and access-controlled the way Chapter 12 requires:

• The Source of Truth (SoT): read declared and effective intent, and propose a gated write, either a dynamic-intent overlay like the one Chapter 16 writes or a change to declared policy. Never a direct write.
• Synthetic monitoring and observability: read current and historical per-ISP health.
• Simulation (Chapter 9): a mandatory what-if before any proposal, run against a realistic model of the network.
• The pipeline: submit a proposed change through the same governed path a human uses, with the same validation and Rollback safety, never around it.
• The risk-tier and policy service (Chapter 12 section 12.6.2): ask what tier a proposed change is, so the gate can decide auto versus escalate.
• Audit and provenance: record every proposal, every simulation result, and every action.

The point is that the agent gets no special powers. It becomes a third author of intent, alongside the human and the healing machine from the Part 5 intent spine, and it is the most constrained of the three. It has a workload identity, a least-privilege scope, and a full audit trail, which is the “identity is the perimeter” principle from Chapter 12 applied to a non-human actor. Nothing here is new machinery. It is the Part 2 building blocks, exposed as tools, behind the Part 3 governance.

17.5 Decision Boundaries and Guardrails#

This is the center of the chapter. The question is not what the agent can decide but what it is allowed to decide alone, and the answer is a set of bounds that do not move.

The first and most important is the distinction between a hard constraint and a soft objective, because the opening story was a failure to draw it. Cost is a soft objective: minimize it. The Minimum-Service Floor and the consumer SLO tolerances are hard constraints: satisfy them, always, and never trade them away for a better objective. The design rule follows directly: encode the floor and the SLOs as hard constraints in the optimizer, not as weighted terms in the objective function. A weighted term can be outweighed, which is precisely how a jitter budget disappears under a large enough cost saving. A hard constraint cannot. Had cdn-eu’s jitter budget been a constraint rather than an omission, the cheap-ISP plan would have been infeasible, and the optimizer would never have proposed it.

The rest of the guardrails are the ones the book has already built, now pointed at the agent. Risk tiers (Chapter 12 section 12.6.2) decide what the agent may apply on its own and what it must escalate: a small shift of a low-value prefix set, auto; a change that moves a large prefix set or approaches the floor, escalate. Simulation must pass before any proposal becomes a change. Blast-radius limits from Chapter 11 bound how much one decision can touch. And the agent is never an approver: Chapter 12 section 12.3.3 already settled that a change requiring human authorization gets a human, because a model has no accountability standing.

One guardrail is specific to a system that decides rather than reacts: it must not thrash. An optimizer that re-plans on every small measurement change will move prefixes around constantly, which is route-flap by another name and destabilizing in its own right. So the agent changes the network only when the expected gain clears a meaningful margin over the current plan, and it is rate-limited in how often it may act at all. A plan that is 2% cheaper is not worth a routing change; a plan that is 30% cheaper and inside every constraint is. Stability is a constraint too.

Replay the opening story with these in place. The optimizer, now carrying cdn-eu’s jitter budget as a hard constraint, cannot produce the cheap-ISP plan at all: it is infeasible. Infeasible means exactly what it says, that no plan exists which both cuts the cost and satisfies the jitter budget, so the optimizer has nothing valid to return. That is the strongest guarantee there is, and it does not depend on predicting the future. Simulation adds a second layer, though it is worth being honest about its reach: a simulator reliably catches structural violations, a plan that breaks the floor or strands a prefix, but it cannot promise how a real ISP will jitter under next week’s peak, which is a forecasting problem, not a simulation one. So the third layer is a staged rollout: apply a new plan to a fraction of the affected traffic first and watch the real health signal from Chapter 16 before committing the rest, the same canary discipline that Chapter 10 and Chapter 11 apply to any risky change. Constraint, forecast, and canary together are what turn “optimal by an incomplete objective” into a plan that is either rejected before it ships or caught the moment it starts to hurt.

17.6 Ethics, Safety, Accountability, and the Confidence Ladder#

An autonomous routing decision moves real people’s traffic. That raises the stakes past the engineering, and three commitments keep it responsible:

• Accountability resolves to a named human, always. The agent proposes and, within its bounds, acts, but when an audit or an incident review asks who is responsible for a change, the answer is a person, never a model. Chapter 12 made this rule for approvals; it holds for autonomy in general. A model cannot be called into a review, cannot be held to account, and cannot carry the responsibility for degrading a service.

• A decision the agent makes must be as undoable/reversible as a healing drain: time-boxed, confirmed-commit where the platform supports it, auto-reverting if it is not confirmed or if it makes things worse. Autonomy without a fast, automatic undo is a way to make a mistake at machine speed.

• Every autonomous action is explainable. The agent must be able to say why it proposed a plan: the objective, the constraints, the data it used, the optimizer’s result. This is not a nicety. An unexplainable action cannot be audited, and an escalation without its reasoning gives the human nothing to decide with. Explainability is a safety requirement, and a proposal that cannot be explained should not ship.

On the Confidence Ladder from Chapter 13, this is the top, and the top still has a ceiling. The Automation Track Record earns the agent more latitude over time, more tiers it may handle alone, but the escalation path to a human is never removed, and the highest-blast-radius and most novel decisions always take it. Autonomy is not the removal of human judgment. It is the automation of the judgments a track record has earned, inside bounds a human still owns.

Where to start is the most conservative rung there is: shadow mode. Run the whole decision layer, the optimizer and the agent, with one change from production autonomy: it proposes, and a human always decides. Every optimization window it produces the plan it would have applied, and every plan is logged next to what the engineers actually did. You change nothing in the network, and you learn the two things no design review can tell you: whether the agent’s plans agree with your engineers’ judgment, and where they diverge and why. Those comparisons are the first entries in the Automation Track Record, and they are what earns the agent its first real authority. After weeks of shadow plans a human would have approved, you let it apply the lowest-risk tier on its own, inside the floor and behind the canary, and no higher. An autonomous network that has never been run in shadow is one you are trusting on faith, which is the one thing this book has argued against at every layer.

Summary#

The optimizer that degraded the content network was not broken. It was optimal, and optimal against an incomplete objective is the characteristic failure of an autonomous system. Chapter 17 is the discipline that makes autonomy safe rather than clever: separate the trustworthy numeric optimizer from the general agentic reasoner, train the models on the audit trail that governance already produced, let the agent act only through the same scoped, governed interfaces as everything else, and encode the things that must not break, the Minimum-Service Floor and the consumer SLOs, as hard constraints that no objective can outweigh. What is left for the agent is real, the choice of a plan among imperfect options, but it is fenced on every side.

That closes Part 5, and with it the technical arc of the book. The network now does three things it could not do when we started: it holds itself equal to what was declared, it defends its own health when a path goes bad, and, at the top rung, it proposes its own decisions within limits it cannot exceed. None of it runs unsupervised, and that is the point. The whole book has argued for the same thing at every layer, from a source of truth to a governed pipeline to an autonomous agent: build the network as a system, earn each increment of trust with evidence, and keep a human accountable at the end of every chain. Autonomy, done this way, is not the absence of control. It is control expressed as bounds.

References#

• Designing Machine Learning Systems, Chip Huyen (O’Reilly, 2022). Training data, feedback loops, and evaluating models in production, the basis for the numeric component and the corpus that trains it.
• Human Compatible: Artificial Intelligence and the Problem of Control, Stuart Russell (Viking, 2019). Objective misspecification and the “optimal but wrong” failure at the heart of this chapter, and the case for bounded, human-accountable autonomy.
• Site Reliability Engineering, Beyer, Jones, Petoff, and Murphy (O’Reilly, 2016). Error budgets and the discipline of graduated, evidence-gated trust that the Confidence Ladder applies to autonomy. (Full text free online.)

💬 Found something to improve? Send feedback for this chapter