Chapter 15 — AIOps and Autonomous Operations: How Much May We Entrust?

“A computer can never be held accountable, therefore a computer must never make a management decision.” — IBM internal training material, 1979

“Everyone to whom much was given, of him much will be required, and from him to whom they entrusted much, they will demand the more.” — Luke 12:48 (ESV)

Why This Matters

For fourteen weeks you have administered systems. This week the systems start administering themselves — and you decide how far you let them.

That is not hyperbole. As of mid-2026, nearly every major observability vendor ships an agentic teammate: software that reads your telemetry and your runbooks, forms a root-cause hypothesis, and posts it in chat before a human has even logged in. Datadog’s Bits AI SRE went generally available around December 2, 2025. Microsoft’s Azure SRE Agent reached GA on March 10, 2026. New Relic’s SRE Agent, PagerDuty’s Advance SRE Agent, the AWS DevOps Agent — the list is long and growing. The on-call workflow you learned in Chapter 9 — pager fires, human opens six dashboards, human greps logs — is being inverted. The machine does the triage. You arrive to a hypothesis.

This is the chapter where the two threads of this entire book finally converge. All term we have separated them: AI as the tool you wield and AI as the workload you run and govern. In AIOps they are the same act. The agent that wields your tools (your kubectl, your runbooks, your dashboards) is a governed workload — a thing with an identity, a budget, a blast radius, and a propensity to be confidently wrong. To wield it safely you must govern it. To govern it you must understand exactly what it is wielding. The tool and the workload close into a loop, and you are standing at the one point in that loop where judgment lives.

So this week’s engineering question is sharp and practical: how do you build a detect → diagnose → remediate → verify loop that is fast enough to be worth having and safe enough to trust on production? The answer is not “full autonomy” and it is not “human approves everything.” It is a ladder of autonomy with approval gates placed exactly where a wrong action would be expensive or irreversible. You will learn to place those gates. That skill is the whole week.

And underneath the engineering sits the apologetic question, which is older than computing and which the IBM trainers above named in 1979: how much may we entrust to a servant, and who answers for the outcome? When the agent over-provisions a volume at 2 a.m. and the bill arrives — who gives the account? The agent cannot. “Of him much will be required” is addressed to a him, a person, a steward with a name. We will take that seriously, because the regulators are taking it seriously (EU AI Act Article 14 names “human oversight” as a legal requirement, though its enforcement date is in flux), and because it is simply true. Let’s build.

Coach’s Note — This is the dedicated AI week, and it carries no project file. The reps in the exercises are the graded lab — they’re richer than a normal week’s drills, and they build the real thing: a gated self-healing loop you run a simulated incident through. Treat them as the assignment, not the warm-up.

15.1 — What AIOps Automates (and What It Doesn’t)

Strip the 2026 marketing away and AIOps still rests on four classic pillars, all of which predate the LLM:

What 2026 added is a fifth layer wrapped around all four: a natural-language, agentic interface. Splunk’s Event iQ Diagnose (shipping June 2026 with ITSI 5.0) writes an LLM summary of an incident episode. Elastic’s AI Assistant (Elastic 9.4, around May 2026) turns “which service caused the 2 a.m. latency spike?” into an ES|QL query you can read and correct. Dynatrace’s Davis CoPilot answers in English over its causal engine. The query language and the causal math underneath are real and old; the English on top is new and seductive. Your job is to remember which is which.

A quick map of the 2026 landscape, so the names aren’t a fog when a vendor pitches you:

• Datadog Bits AI SRE — GA around December 2, 2025; tested against 2,000+ environments. Investigates, correlates, hypothesizes.
• Microsoft Azure SRE Agent — GA March 10, 2026; runs in a Reader mode versus a privileged mode, and uniquely lets you pick the foundation model (with published per-model rates). It even bills its own work in Azure Agent Units (AAU) — roughly 4 AAU per agent-hour when always-on — a reminder that the agent is a metered workload, not free.
• New Relic SRE Agent — in preview as of early 2026, deliberately recommend-only.
• PagerDuty Advance SRE Agent, AWS DevOps Agent (GA ~April 2026), Cisco/Splunk AI Troubleshooting Agents — same shape, different ecosystems.
• Splunk Event iQ Diagnose (June 2026, ITSI 5.0), Dynatrace Davis CoPilot, Elastic AI Assistant — the NL/summarization layer over a real engine.

(All GA-vs-preview statuses move month to month; treat this list as a mid-2026 snapshot and re-check before you buy.)

Here is the load-bearing distinction, and it is the spine of the whole chapter. The four classic pillars are mostly observe and recommend. They tell you things. The fifth, agentic layer is the one that can act — and most vendors, as of 2026, deliberately gate it to recommend, not act on production. New Relic’s SRE Agent explicitly does not make production changes or bypass approvals. PagerDuty’s Fully Autonomous Responder is slated as early-access only in the second half of 2026. That gate is not a limitation they’re embarrassed about. It is the product working correctly. Internalize that and you are already ahead of the hype.

Coach’s Note — When a vendor says “resolves incidents 25% faster,” that is a marketing figure, not an independent benchmark — New Relic’s own 2026 report cites roughly 26.75 minutes per issue with AI versus 50.23 without, but it’s their number, measured their way. Cite these as claims. The graduate move is to ask “measured against what baseline, on whose incidents?” and to run your own before/after on your own MTTR.

15.2 — The Autonomy Ladder: detect → suggest → approve → act

Every conversation about “self-healing” collapses into confusion until you put the systems on a ladder. There is no single switch labeled autonomous. There are tiers, and a mature platform runs different actions at different tiers simultaneously.

Read the code/runbook_disk_pressure.yaml starter: every remediation step carries an explicit autonomy: field and a blast_radius:. The read-only diagnostic (du -x -d1 /var) is act — let it run unattended; it changes nothing. The log rotation (journalctl --vacuum-size) is approve — it’s irreversible (deleted logs are gone), so a human clicks. The volume resize is approve because it costs money. Same incident, three different tiers, because the blast radius differs per action, not per incident.

The discipline is to set each action’s tier by two questions, asked honestly:

1. Is it reversible? A kubectl rollout restart is reversible. kubectl delete pvc is not. apt-get clean is effectively reversible (the cache refills). Irreversible actions earn a gate.
2. What is the blast radius? One pod, one node, one region, the whole fleet? Cost, data, or availability? The bigger the radius, the higher the tier — regardless of how confident the agent sounds.

Notice what this ladder does to the old phrase “human in the loop.” It refuses to apply it uniformly. Tier-4 read-only diagnostics with a human in the loop would be absurd — you’d page someone at 2 a.m. to approve a du. Tier-3 production deletes without a human in the loop would be reckless. The skill is selective placement, which the industry is starting to call governed autonomy — an emerging framing, not yet a settled term, but the right instinct: not “approve everything,” not “approve nothing,” but “approve exactly the actions whose cost of being wrong exceeds the cost of waiting for a human.”

15.3 — Self-Healing as a Closed Loop

A self-healing system is a control loop you’ve seen before in disguise — the same detect-act-verify shape as a thermostat, a systemd restart policy, a Kubernetes liveness probe. What’s new is that an LLM agent sits in the diagnose and propose boxes, reading a runbook and telemetry the way a junior engineer would.

        ┌─────────┐     ┌──────────┐     ┌───────────┐     ┌────────┐
ALERT ─▶│ DETECT  │ ──▶ │ DIAGNOSE │ ──▶ │ REMEDIATE │ ──▶ │ VERIFY │ ──▶ resolved
        │(metric/ │     │(agent +  │     │  ▲ GATE   │     │(re-    │
        │ log)    │     │ runbook) │     │  │ human   │     │ check) │
        └─────────┘     └──────────┘     └──┴────────┘     └────┬───┘
                                                                │ fail
                                                                ▼
                                                          page a human

Two boxes carry the safety of the whole loop:

• The GATE before REMEDIATE. Read code/sample_incident.log. On node-7, the agent diagnosed correctly (journald ate 41 GB of /var), proposed journalctl --vacuum-size=500M, and then stopped — GATE waiting for human approval. The human took eight and a half minutes to approve. That think-time is not a bug; it’s the feature. Contrast node-4 at the bottom of the same log: an agent misconfigured to tier-4 act resized a volume to 2000 Gi unattended, and FinOps woke up to an unplanned +$1,840/month. Same alert. The only difference was the gate.
• The VERIFY box. A remediation that runs is not a remediation that worked. The runbook’s verify: block re-reads node_filesystem_avail_bytes and only declares success if free space clears 25%. If it doesn’t, rollback_if_unmet: page-human. An action with no verification is a hope, not a fix — and hope, as the Google SRE adage goes, is not a strategy.

Coach’s Note — The most dangerous self-healing failure isn’t the action that breaks something. It’s the action that appears to succeed and silences the alert without fixing the cause — the loop “heals” the symptom, the alert goes quiet, and the real fault festers until it surfaces somewhere worse. This is why VERIFY checks the underlying signal, not “did the command exit 0.” Restarting the pod cleared the alert; did it clear the memory leak? Different question.

15.4 — AI-Generated Fixes and Automated Incident Response

Detecting and diagnosing is one thing. The 2026 leap is that the agent now writes the fix. When the SRE agent diagnoses a bad config and proposes a patch, it can open a pull request — the same pattern you met in Chapter 8 and Chapter 13: AI proposes, CI validates, human gates. GitHub’s Copilot coding agent is scoped to copilot/* branches (it cannot push to main or protected branches), and every PR it opens is scanned by CodeQL and secret scanning before a human ever reviews it. Carry that exact shape into incident response.

The danger when an agent generates a fix — a shell command, a Terraform diff, a YAML patch — has a name from the OWASP LLM Top 10: LLM05, Improper Output Handling. If you take the agent’s generated string and feed it straight into a shell, an apply, or a database without validation, you’ve opened the door to injection. The agent’s confident journalctl --vacuum-size=500M is fine; the agent’s confident rm -rf $UNVALIDATED_PATH is a production outage. Treat generated remediation as untrusted output, exactly the way you treat user input — validate it, constrain it to a known-safe allowlist, and run it through the gate.

Automated incident response, then, is a pipeline with the same checkpoints as a CI/CD pipeline:

Coach’s Note — “Excessive Agency” (OWASP LLM06) is the other half of this. It’s not that the agent generated a bad command — it’s that you gave it the permission to run one. An agent with cluster-admin and an outbound network tool can turn one good diagnosis and one bad generated string into a very bad afternoon. Least privilege isn’t a nice-to-have for agents; it’s the difference between a typo and an incident.

15.5 — Agentic AI in Ops, and MCP

How does an agent actually touch your systems? Through tools. And the way agents and tools talk, in 2026, has largely converged on the Model Context Protocol (MCP) — the spec dated 2025-11-25, donated to the Linux Foundation’s Agentic AI Foundation on December 9, 2025. (A 2026-07-28 release candidate exists, so “latest version” is a moving target — pin the spec date in any runbook.)

Two protocols, one common confusion. Keep them straight:

• MCP is agent-to-tool. It lets a model call get_disk_usage, read a log Resource, fetch a runbook Prompt. By MCP’s one-year mark it reported ~10,000 active servers and ~97M monthly SDK downloads, with first-class support across Claude, ChatGPT, Cursor, Gemini, Copilot, and VS Code.
• A2A (Agent2Agent, ~v1.2) is agent-to-agent. It lets one agent delegate to another. Complementary to MCP, not a competitor.

MCP’s building blocks split by who offers them. A server offers Tools (callable functions), Resources (readable data), and Prompts (templated workflows). A client offers Sampling, Roots, and Elicitation. And two security rules are baked into the spec itself, which you must not treat as optional:

1. The host must obtain user consent before invoking any tool. Not a courtesy — a spec requirement.
2. Tool descriptions from an untrusted server are themselves untrusted input. A malicious MCP server can hide an instruction in a tool’s description. This is prompt injection wearing a tool’s clothes.

Read code/disk_mcp_server.py: a complete read-only MCP server in ~40 lines using the official Python SDK’s FastMCP. One Tool (get_disk_usage), one Resource (the incident log). There is no write path at all — least privilege by construction. Connect it from Claude Code and you’ll see the consent prompt fire before the tool runs. That prompt is the spec doing its job.

# Launch the read-only ops server (stdio transport):
pip install "mcp[cli]"
python code/disk_mcp_server.py
# Then register it with your agent host and watch the consent prompt
# appear before get_disk_usage is allowed to run.

This is the agentic-AI-in-ops pattern at its smallest and safest: a narrow tool, a consent gate, no way to change state. Scale that instinct up and you have a governed AIOps agent. Skip it and you have the node-4 story. The full ruleset lives in Appendix C; local-versus-cloud serving for the model behind the agent is in Appendix B.

15.6 — Guardrails: the Lethal Trifecta and the Rule of Two

An agent with tools is a new attack surface, and the failure mode has a name. The lethal trifecta is the combination of three capabilities in one agent:

1. Access to private data (your logs, your secrets, your customer records),
2. Exposure to untrusted content (a web page, an email, a log line an attacker wrote),
3. An exfiltration vector (an outbound HTTP call, an email tool, a write to a public place).

Hold all three at once and a single indirect prompt injection — a hostile instruction hidden in content the agent reads — can make your agent read your secrets and ship them to the attacker. This is architectural, not a bug you patch. You cannot filter your way out of it; you design your way out.

The cleanest design rule in circulation is Meta’s “Agents Rule of Two”: an unsupervised agent should satisfy at most two of (a) processes untrustworthy input, (b) has access to sensitive data or systems, (c) can change state or communicate externally. Need all three for a task? Then it is not an unsupervised task — put a human in the loop. The Rule of Two is just the lethal trifecta written as a constraint you can check.

Coach’s Note — Your ops logs are untrusted content. An attacker who can write a log line your agent reads — a crafted User-Agent string, a malicious filename in an error message — is feeding your agent instructions. The day your SRE agent can both read logs and run curl to an arbitrary host, you have hand-built the lethal trifecta. The Rule of Two says: pick two, gate the third.

15.7 — The Governance Counter-Current

It would be easy to read the first half of this chapter as a victory lap for autonomy. It is not. The governance counter-current in 2026 is strong, and a graduate administrator must hold both truths at once.

Gartner — from a January 2025 poll of 3,412 webinar attendees, so a framing figure, not a measured one — predicts that more than 40% of agentic-AI projects will be cancelled by the end of 2027, citing cost, unclear value, and inadequate risk controls. Gartner also coined “agent washing”: of thousands of vendors claiming “agentic AI,” they estimate only ~130 are genuinely so. The forecast that 70% of enterprises will deploy agentic AI to operate infrastructure by 2029 (versus under 5% in 2025) and the forecast that 40% of those projects fail are not contradictions. They are the same wave and its undertow.

Two more anchors for your governance vocabulary:

• The NIST AI Agent Standards Initiative kicked off in February 2026 — standards work is underway, which means today’s practices are pre-standard. Build to principles, not to a vendor’s current button layout.
• Regulation names human oversight explicitly. EU AI Act Article 14 requires that high-risk AI systems be designed so humans can oversee them. As covered in Chapter 14, the high-risk enforcement date is genuinely in flux — the 2026 “Digital Omnibus” (provisional agreement May 7, 2026) would defer Annex III obligations to December 2, 2027, but as of mid-2026 that deferral is not yet adopted, so the original August 2, 2026 date technically remains the legal default. Date this claim and re-confirm before you rely on it. The principle — designed-in human oversight — is stable even while the deadline moves.

The lesson: autonomy is not a destination you arrive at. It is a dial you turn deliberately, action by action, with the brakes (gate, verify, audit, budget cap) installed first.

15.8 — The Mechanics of Human Oversight

“Human in the loop” is a slogan until you build the loop. Here are the four mechanisms that turn it into engineering — the brakes from the last section, made concrete. A governance framework that names all four is the difference between governed autonomy and hope.

1. Identity-aware orchestration. The agent is a non-human identity — give it its own service principal, not a borrowed human’s credentials, and scope it with least privilege. As you saw in Chapter 3, UEBA in 2026 increasingly baselines agents as identities you watch. If the agent suddenly tries kubectl delete across three namespaces, that’s an anomalous action sequence — and you can only see it because the agent has its own identity to attribute the action to.
2. Approval gates, scoped by tier. From §15.2: the gate fires only on approve-tier actions. code/approval_gate.sh is the smallest real version — a PreToolUse hook that blocks destructive patterns and demands an explicit approval token. It is a deny-by-default wall, not a courtesy popup.
3. Time-boxed approvals. An approval should not be a blank check forever. “You may resize this volume — within the next 15 minutes, once.” A stale approval reused an hour later, on a changed system, is how a good decision becomes a bad action. Bound approvals in time and scope.
4. The immutable audit log. Every action — proposed, gated, approved, executed, verified — appends to a log that the agent cannot rewrite. Read code/sample_incident.log: the APPROVE … by=m.litman token=I-APPROVE line is what lets a human give an account afterward. No log, no account. This is also EU AI Act Article 12 territory (automatic logging over the system’s lifetime).

Coach’s Note — Notice these four are just classic sysadmin controls — identity, least privilege, change approval, audit — pointed at a new kind of actor. You already know how to do this. The agent didn’t invent the discipline; it raised the stakes. The reason you separate the agent’s identity from yours is the same reason you never share a root password: when something goes wrong, you need to know who — even when the who is a service principal acting on your behalf.

15.x — Interactive Lab: Self-Healing Workflow Builder

Below this chapter on the website is the Self-Healing Workflow Builder — the week’s interactive panel. Use it before you start the reps; it makes everything in §15.2 and §15.3 concrete in about ten minutes.

You assemble a loop from blocks — event → diagnose → remediate → verify — and, crucially, you decide where to drop the human-approval gate. Then you run a simulated incident through it (the disk-pressure scenario from code/runbook_disk_pressure.yaml is the default). The builder shows you the agent’s diagnosis, its proposed remediation, and what happens at the gate — or what happens when there is no gate. Build the node-7 loop and the node-4 loop side by side. Watch the gate stop the 2000 Gi resize. Then remove the gate and watch the same loop quietly burn $1,840 a month.

What it teaches is the one judgment this whole chapter is about: a remediation’s autonomy tier is a property of the action, not the incident. Place a gate before an irreversible or costly step and the loop is fast and safe. Place it before a read-only du and you’ve built a pager that wakes humans for nothing. Place it nowhere and you’ve built the node-4 story. Run the builder until you can predict, before you hit “simulate,” exactly where your gate will fire and why.

15.9 — The Steward and the Servant

Now the question the IBM trainers asked in 1979, and that Luke asked two thousand years before that: how much may we entrust to a servant, and who answers for the outcome?

The engineering and the theology meet on one word: accountability. The autonomy ladder in §15.2 is, underneath, a doctrine of delegation. You delegate the read-only du because nothing is at stake. You refuse to delegate the irreversible delete because something is. And the reason a human must click before the costly action is not sentiment — it is that only a human can be held to account. The IBM line is exactly right: a computer cannot give an account, therefore it must not make the management decision. The 2000 Gi resize on node-4 had no human on record, and so when the bill came, there was no one to ask. That is not merely a process failure. It is a category error — entrusting a management decision to a thing that cannot answer for it.

Scripture frames delegation as a relationship of account. In Luke 16, the manager is told, “Give an account of your management” (Luke 16:2, ESV) — the steward administers what is not his, and is answerable for it. And our epigraph: “Everyone to whom much was given, of him much will be required” (Luke 12:48, ESV). The more authority you hand the agent, the more is required of you — not the agent. Autonomy does not transfer accountability; it concentrates it. The administrator who deploys a powerful agent has not been relieved of responsibility. He has multiplied it, because now he answers for everything the agent does at speed and scale.

This is the LCMS doctrine of vocation in operational dress. The administrator stands in a station — a steward of systems that belong to others (the ministry, the patients, the donors whose data sits on those disks). The agent is a tool of that vocation, like a wrench or a script, and a tool does not bear vocation. You do. So you place the gates not because the regulation says to (though it does, in Article 14) and not because the agent is untrustworthy in some moral sense (it has no morals to trust), but because the account is yours to give, and a faithful steward does not sign his name to an outcome he did not oversee. Entrust much to the servant — the servant is genuinely useful, and refusing good tools is its own failure of stewardship. But keep your hand on the gate where the cost of being wrong is real. Of you much will be required.

15.10 — Common Pitfalls

Pitfall: Treating “autonomy” as one switch instead of a per-action tier. Example: A team flips their SRE agent to “auto-remediate” globally; it restarts a healthy pod during a deploy and masks a real fault. Fix: Assign each remediation a tier (§15.2) by reversibility and blast radius. Tier-4 only for read-only or low-blast, reversible fixes.

Pitfall: A remediation with no verify step. Example: The agent restarts the service, the alert clears, everyone moves on — but the memory leak is still there and OOMs the node an hour later. Fix: Every loop ends in VERIFY against the underlying signal, with rollback_if_unmet: page-human. Exit-0 is not success.

Pitfall: Forgetting that logs and telemetry are untrusted input. Example: An attacker plants an instruction in a User-Agent string; the SRE agent reads the log and follows it. Fix: Apply the Rule of Two. If the agent reads untrusted content AND touches sensitive data AND can exfiltrate, it’s not unsupervised — gate it.

Pitfall: Believing the natural-language layer is doing the reasoning. Example: A student trusts “the AI found the root cause” without reading the ES|QL query it generated — which was subtly wrong. Fix: NL is a layer over a real query language and a real causal engine. Read and correct the generated query every time (§15.1).

Pitfall: No budget guardrail on an agent that can provision. Example: The node-4 2000 Gi resize — +$1,840/month with no approval on record. Fix: Cap consumption (spend limits, quota) and gate any action that costs money, regardless of the agent’s confidence. Costly = tier-3, always.

Pitfall: Confusing MCP with A2A, or trusting an MCP server’s tool descriptions. Example: A team adds a third-party MCP server whose tool description hides an injection; the agent obeys it. Fix: MCP = agent-to-tool, A2A = agent-to-agent. Treat untrusted-server tool descriptions as untrusted input; vet servers before connecting (§15.5).

15.11 — Reps

The reps are in the exercises, and this week they are the graded lab. There is no project file — the lab is the assignment, and it’s richer than a normal week’s drills. You will stand up the read-only MCP server, wire the approval-gate hook, drive a simulated incident through a full detect → diagnose → remediate → verify loop, and demonstrate — with a log to prove it — that your gate stops an unsafe auto-remediation.

A preview:

• Rep 1 — Run code/disk_mcp_server.py, connect it to your agent, and observe the MCP consent prompt fire before the tool runs.
• Rep 3 — Wire code/approval_gate.sh as a PreToolUse hook and prove it blocks a destructive command without the approval token.
• Rep 5 — Classify every remediation in code/runbook_disk_pressure.yaml onto the autonomy ladder and justify each tier in writing.
• Rep 8 — Build the lethal trifecta on purpose in a sandbox, fire an indirect injection, then fix it by applying the Rule of Two.
• Rep 11 — Reproduce the node-4 failure and write the post-incident account as the human who would answer for it.

AI policy for the reps (Phase 2): AI is part of the work and the work is agentic. You may use an agent throughout — that’s the point — but keep an honest agent-log.txt: what you delegated, what it did, where it was confidently wrong, and where you intervened. The reps are shaped so an agent cannot finish them for you; the judgment calls (tier placement, the post-incident account) are yours. A short “Check Your Reps” quiz is embedded on this page — take it after the reps.

15.12 — Final Prep, Not a Project

There is no Project 15. Next week is the capstone — the FINAL — and this week’s lab is your last rehearsal for it. In Chapter 16 you will architect an entire AI-native organization and, more than any code, you will be graded on the governance framework you write first: an autonomy ladder, approval gates, an audit and logging plan, an LLM-security program, and consumption-cost guardrails.

Everything you built this week is a component of that framework. The gate from §15.3, the Rule of Two from §15.6, the accountability doctrine from §15.9 — carry them straight into the capstone. Reread Appendix C (the agentic-AI rules) and skim your own agent-log.txt from this lab; the final asks you to defend exactly these decisions at the scale of a whole enterprise. Use this week to make those reflexes automatic.

15.13 — Coach’s Final Word

This week the systems learned to heal themselves, and you learned exactly how far to let them.

Hold the two truths together, because the whole profession now lives in the tension between them. The agentic teammate is real, it is useful, and refusing it is its own failure of stewardship — a steward who buries the talent in the ground is not praised for caution. Use the servant. Let it run the read-only diagnostics, draft the hypothesis, do the typing and the triage at 2 a.m. so a human doesn’t have to. That is good work and you should embrace it.

But keep your hand on the gate where the cost of being wrong is real, because the account is yours to give. The agent cannot be paged into the room when the bill arrives or the data leaks or the cluster goes dark. A computer cannot be held accountable — the IBM trainers knew it in 1979 and it is no less true now that the computer is fluent. So the management decision stays with the steward. You wield the tool; you govern the workload; you own the verdict. That is the entire book in one sentence, and this is the week it stopped being a slogan and became a code/approval_gate.sh you can read.

Do the lab. Place the gates. Keep the log. Then come ready to architect the whole thing.

See you next week.

Up next: Work every rep in the exercises — this week the reps are the graded lab. Lean on Appendix B for serving the model behind your agent and Appendix C for the agentic-AI rules; Appendix A covers the lab environment. Then Chapter 16 — The AI-Native Enterprise: Capstone, where you architect the 2030 organization and defend the governance framework you’ve been building all term.