Chapter 16 — The AI-Native Enterprise: Capstone

“Architecture is about the important stuff. Whatever that is.” — Ralph Johnson, quoted by Martin Fowler

“Unless the LORD builds the house, those who labor build in vain.” — Psalm 127:1 (ESV)

Why This Matters

You have spent fifteen weeks taking the machine apart. Processes, memory, identity, storage, the network, the hypervisor, the container, the pipeline, the watch, the adversary, the ark, the cloud, the long haul, the lifecycle, and the autonomous loop. Each week you learned one organ. This week you put a body together — and you make it stand.

That is what an architect does. Not type faster. Not know one more flag. An architect holds the whole thing in view at once and decides what holds it together — which tradeoffs the organization will live with, which it will refuse, and who answers when something breaks. The blueprint for this chapter calls it “the AI-native enterprise,” and the phrase is precise. It does not mean an org that bought some AI. It means an org whose every layer assumes AI is present on both sides of the line we have drawn all semester: AI as the tool the administrators wield, and AI as the workload the administrators govern. Identity now includes non-human agent identities. Monitoring now includes an agentic SRE that posts a root-cause hypothesis before you log in. Storage now sizes model weights and vector indexes, not just home directories. Backup now protects fine-tuned weights you cannot re-derive. Every organ you learned has grown an AI half, and the architect is the one person required to see both halves of all of them at the same time.

Here is the thing that makes this hard, and the thing that makes it a capstone and not a checklist. The two AI threads pull against each other. The tool-thread wants more autonomy — let the agent triage, let it draft the IaC, let it remediate the pod at 3 a.m. so no human’s pager screams. The workload-thread wants more governance — pin the model, cap the spend, gate the destructive action, log every move, keep a human accountable. A good architecture is not “maximize AI” or “minimize AI.” It is the line drawn deliberately between those two pulls, action class by action class, written down where everyone can see it. The spine rule of this whole book lands hardest right here: the human stays in the loop where the judgment lives. An AI-native architecture is, more than anything, a record of where you decided the judgment lives.

And this is the week the field reminds you why you cannot just memorize a stack. Count the renames from the last eighteen months, all in your fact brief: Hugging Face TGI deprecated and archived; Open WebUI relicensed under community pushback; WhyLabs wound down; Helicone into maintenance mode; BentoML acquired; Seldon Core moved to a source-available license; Vertex AI and Azure AI Foundry both renamed; Run:ai acquired by NVIDIA. If you architected on brand names in 2024, half your diagram is wrong by 2026. Tooling churn is itself an architecture risk. The durable move is to bet on the open standards underneath the names — OpenTelemetry, the OpenAI-compatible API, the Open Inference Protocol, MCP and A2A, OCI artifacts — and to evaluate products on project health, not marketing.

This week’s question is the oldest one an architect can ask: what does it mean to build a house that stands? Psalm 127 opens it without flinching — “Unless the LORD builds the house, those who labor build in vain.” It is not a verse against effort; the psalm assumes the laborers are working hard. It is a verse about what the effort rests on. Jesus draws the same line at the end of the Sermon on the Mount: the wise builder and the foolish builder both built a house, both did real work, and the only difference revealed when the flood came was the foundation (Matthew 7:24–27). You are about to design a house for an organization that will run on it for years. We will ask, with full engineering seriousness, what it would mean for that house to be founded on rock and not sand — and you will find the answer sharpens the architecture, not softens it.

16.1 — What “AI-Native” Actually Names

Strip the marketing and an AI-native architecture is a layered platform with two lanes and one governance spine. The fact brief names the durable shape; here it is as a map you could draw on a whiteboard.

Two lanes, because training and inference have different shapes. The training/pipelines lane (Kubeflow, KubeRay) runs bursty, gang-scheduled, interconnect-bound jobs. The GenAI inference lane (KServe + vLLM + llm-d or NVIDIA Dynamo, or NIM containers for the air-gapped/SLA case) runs steady, latency-sensitive, autoscaled services. They share GPUs but want different scheduling. The reference sketch in code/inference-platform.yaml shows the inference lane and where the governance hooks attach.

Coach’s Note — Notice the table has no empty cells. That is the test of “AI-native” versus “AI-bolted-on.” If your architecture has a thriving AI half in observability and a blank AI half in backup, you have not built an AI-native org — you have built a traditional org with an AI demo wired to one organ. The capstone grade lives in the cells most people leave blank: AI disaster recovery, AI security controls, AI governance. Fill them.

16.2 — The Tool Thread Through the Whole Stack

Walk the architecture once as the administrator who wields AI, and watch where it shows up in 2026.

• At the pager. An agentic SRE — Datadog Bits AI SRE (GA as of late 2025), New Relic SRE Agent (preview, recommend-only as of early 2026), Microsoft Azure SRE Agent (GA March 2026) — reads telemetry and the runbook and posts a root-cause hypothesis to chat before a human opens a dashboard. The 2026 shift, per the brief, is from “AI features bolted onto dashboards” to semi-autonomous teammates that triage first.
• At the keyboard. A coding agent (GitHub Copilot coding agent, Claude Code, Cursor) turns an issue into a sandboxed pull request, scoped to non-protected branches, scanned by CodeQL and secret scanning before a human reviews it. That pattern — AI proposes, CI validates, human gates — is the durable one. Bring it to IaC, to runbooks, to documentation.
• At the log. An NL query layer turns “which service caused the 2 a.m. latency spike?” into a real query (ES|QL in Elastic, for instance). The layer is a convenience over a real query language, not magic — you verify the query it wrote.
• In the SOC. AI defends — UEBA baselines per identity, SOAR automates response, Microsoft Security Copilot summarizes incidents.

Every one of those is paired with a failure mode you have drilled all semester: the confident-wrong hypothesis, the hallucinated module name in the generated playbook, the NL query that silently dropped a filter, the false-positive that pages a tired human at 3 a.m. The tool thread is real leverage and real risk in the same motion. The architecture’s job is to put the leverage where it pays and the gate where the risk is.

Coach’s Note — A copilot that is right 95% of the time is not “95% as good as an expert.” It is an expert who lies confidently one time in twenty and never tells you which time. That is exactly the partner the spine rule was written for. Design the verification step as a first-class part of the architecture, not an afterthought you hope people remember.

16.3 — The Workload Thread Through the Whole Stack

Now walk the same architecture as the administrator who runs and governs AI as a workload. Everything you sized and scheduled all semester applies, and the brief gives you the durable building blocks.

Compute and partitioning. GPUs are the scarce resource, so you partition them deliberately. A whole card via VFIO passthrough for an isolated training VM; MIG slices for true hardware-isolated inference tenants (ceiling: 7 instances, even on a 180 GB B200 — the trap from Chapter 6); time-slicing only where isolation does not matter. On Kubernetes, DRA (GA in v1.34) replaces the opaque nvidia.com/gpu: 1 integer request with a declarative ResourceClaim against a DeviceClass, so you can ask for “a 3g.40gb MIG slice” instead of “one whole anything.”

Serving. The split is clean. Ollama / LM Studio / llama.cpp for dev and low-concurrency (1–3 users). vLLM or SGLang for production GPU serving — continuous batching, FP8, prefix caching. NIM containers when you need vendor support, SOC2/HIPAA, or air-gap. The OpenAI-compatible /v1/chat/completions API is the lingua franca across all of them — change only base_url and a dummy key. Here is the universal-client pattern that survives every rename:

from openai import OpenAI

# Same code against vLLM, Ollama, llama.cpp, NIM, or a cloud API.
# Only base_url + key change. Pin the model ID; never use "latest".
client = OpenAI(base_url="http://vllm.internal:8000/v1", api_key="not-needed-locally")

resp = client.chat.completions.create(
    model="PIN-ME-exact-model-id",          # governance: pin, log, version
    messages=[{"role": "user", "content": "Summarize this incident."}],
)
print(resp.choices[0].message.content)

Storage and continuity. Model weights ship as OCI artifacts so they reuse registry tooling — signing, scanning, GitOps, P2P distribution. Sizing is the napkin math you drilled: ~2 GB/B at FP16, ~1 GB/B at INT8, ~0.5 GB/B at INT4, plus a KV cache that at long context can exceed the weights. Vector stores: pgvector under ~5–10M vectors, Qdrant/Milvus beyond. And in DR you sort assets by the one question that matters — reproducible or irreplaceable? Embeddings and HNSW indexes can be re-derived; fine-tuned weights, curated datasets, and prompt libraries cannot. Protect the irreplaceable like the irreplaceable.

Cost. The workload has a meter running. Reserved/self-host wins only above high, sustained volume; below it, pay-per-token is cheaper. Output tokens cost roughly 4–8× input, and agentic stacks amplify usage — one question becomes many model calls plus retrieval plus guardrail charges. Run the model in code/estate_cost.py before you commit a serving strategy. The crossover is a measured decision, not a vibe.

16.4 — The Governance Spine: Three Frameworks, One Control Set

Governance is the part most engineers skip and most graders weight. Three frameworks anchor it, and they are layers, not competitors — you implement all three at once.

The EU AI Act timeline is the single most volatile fact in this whole book, so state it carefully. Prohibitions and AI-literacy obligations took effect February 2025; GPAI and governance provisions in August 2025. The high-risk obligations were statutorily due August 2, 2026 — but the 2026 “Digital Omnibus” (provisional political agreement, May 2026) defers standalone Annex III high-risk systems to December 2, 2027 and product-embedded systems to August 2, 2028. As of mid-2026 the Omnibus is not yet adopted in the Official Journal, so the original date technically remains the legal default until adoption. The lesson for an architect is not the date. It is that you design for the regulation to move — you build the logging and the human-oversight gate now, so a date change is a calendar event and not a re-architecture.

A complete governance framework needs six things, and the starter in code/governance-checklist.txt gives you the table to fill:

1. A model registry with versioning, lineage, and aliases (MLflow / Unity Catalog).
2. AIBOM + documentation — a CycloneDX ML-BOM or SPDX 3.0 file plus a model card and datasheet for every model promoted past development. An AIBOM is the ingredients label for an AI system.
3. WORM / signed-artifact retention satisfying EU AI Act Art. 12 logging.
4. An autonomy ladder with approval gates — see code/autonomy-ladder.yaml.
5. An LLM-security program — OWASP LLM Top 10 mapped to MITRE ATLAS technique IDs.
6. Consumption cost guardrails — spend caps in whichever opaque unit your vendor invented (Azure AAU/AAC, Bedrock model units, Vertex GSUs, or raw tokens).

Coach’s Note — If a governance control has no named human owner, it is not governed; it is hoped for. The single most common failure I see in capstone submissions is a beautiful governance narrative with no owner column. Write the names in. A control plane without a control person is a diagram, not a defense.

16.5 — Governed Autonomy: Where the Two Threads Are Reconciled

This is the keystone section, because it is where the tool thread and the workload thread stop pulling against each other and become one design. The brief names the durable principle plainly: AI agents propose, CI/policy validates, humans gate high-risk actions, and every action is logged for audit.

That single sentence ties together four things you have met separately:

• OWASP LLM06 (Excessive Agency) — don’t grant the agent more permission/autonomy than the action class needs. Least privilege, applied to an agent.
• The lethal trifecta — private-data access + untrusted-content exposure + an exfiltration vector. Any tool-using agent that has all three is exploitable by prompt injection, which is an architectural risk, not a patchable bug.
• Meta’s “Agents Rule of Two” — an unsupervised agent should satisfy at most two of {untrustworthy input, sensitive-data access, ability to change state or communicate out}. Need all three? Require a human in the loop.
• EU AI Act Art. 14 (human oversight) — a named human must be able to understand, oversee, and override.

You implement this as an autonomy ladder: each action class is placed on the rungs observe → recommend → approve → act, with a gate and a rollback and an audit requirement per rung. The reversible, low-blast-radius, idempotent action (restart a stateless pod) can sit on act with automatic rollback. The irreversible action (delete a persistent volume) never rises above recommend — a human owns it, full stop. The security-sensitive action (rotate a credential) demands out-of-band verification so an injected agent cannot do it alone. See the worked policy in code/autonomy-ladder.yaml.

# the shape of one rung — autonomy is a per-action decision, written down
- name: delete_persistent_volume
  tier: recommend          # NEVER 'act' — irreversible data loss
  guardrails:
    irreversible: true
    human_in_the_loop: mandatory
  rationale: "The human owns the decision and the accountability."

The 1979 IBM line your Chapter 15 epigraph quoted still rules the ladder: a computer can never be held accountable, therefore a computer must never make a management decision. The agent can prepare, propose, even apply within guardrails. The account — the answer to “why did this happen and who decided it” — belongs to a person. And the governance counter-current is real: Gartner predicts 40%+ of agentic projects cancelled by end of 2027, and coined “agent washing” for the gap between claimed and genuine agentic vendors. The mature architecture is governed autonomy, not maximal autonomy.

16.6 — Two Organs the Capstone Always Tests: Identity and DR

Two organs in particular separate a real AI-native architecture from a demo, because they are where the AI half is easiest to forget — and where the flood, when it comes, hits hardest. The capstone canvas grades both.

Identity now includes non-human identities. For fifteen weeks “identity” meant users and devices in a directory (Active Directory / Microsoft Entra ID), with SSO, MFA, RBAC, least privilege, and a lifecycle. In an AI-native org the directory grows a new class of subject: the agent. An AIOps agent that restarts pods, a coding agent that opens PRs, an MCP-connected tool-user — each is a thing that acts on your systems and therefore needs an identity, a credential, a scoped permission set, and a lifecycle. The 2026 theme in the brief is exactly this: UEBA and the agent control plane (Microsoft Agent 365, GA May 2026) extend identity governance to the agents themselves as non-human identities — inventory them, scope them, watch their behavior, and revoke them. The architecture lesson is sharp: every agent is a privileged service account that talks back. Give it the least privilege its rung on the autonomy ladder requires, give it an identity you can audit and revoke, and never let an agent’s permissions exceed the gate that governs it. The deepfake threat closes the loop — when “I recognized the CFO’s face and voice” is no longer an authentication factor (the Arup case), out-of-band verification and phishing-resistant auth (FIDO2/passkeys) move from nice-to-have to load-bearing, for humans and for the agents acting in their name.

DR now sorts the world into reproducible and irreplaceable. Traditional DR is 3-2-1, RPO/RTO, immutable/air-gapped copies against ransomware. All of it still applies — and it grows an AI half that most submissions miss. The discipline is one question asked of every AI asset: can I re-derive this, or is it gone for good?

Weights increasingly ship as OCI artifacts, so the irreplaceable ones reuse registry tooling — signing, scanning, WORM retention that doubles as EU AI Act Art. 12 logging. The architect’s failure here is quiet and total: a DR plan that lovingly protects the VMs and the donor database and silently omits the one fine-tuned model and the curated dataset that took a year of human labor to build. Protect the irreplaceable like the irreplaceable. That is the AI half of the ark.

Coach’s Note — Run the test on your own design: if a meteor hit your primary region tonight, list everything that is gone forever — not “down,” gone. If that list has a fine-tuned weight, a dataset, or a prompt library on it with fewer than two independent off-site copies, you have not built the ark. You have drawn it.

16.x — Interactive Lab: AI-Native Architecture Canvas

Below this chapter on the website is the AI-Native Architecture Canvas — the interactive panel that turns everything above into a thing you build with your hands before you build it for a grade.

Open it. You are given a blank 2030-org canvas and a palette of components in two groups: the traditional components (identity, virtualization, monitoring, security, backup) and the AI components (local LLM infrastructure, AI governance, AI-assisted monitoring, AI-assisted automation, AI security controls, AI disaster recovery). Drag each onto the canvas and place it in the right layer. As you place components, a completeness checklist on the side lights up — and it will not let you call the architecture done until every required cell is filled. That is the point. The checklist is deliberately built to flag the cells most students leave blank: AI DR, AI security controls, AI governance. If your canvas is all tool-thread and no workload-thread, the checklist will tell you, in red.

Do three passes. First pass: place everything and clear the checklist — prove you can see the whole body at once. Second pass: for each AI component, name the gate — what must a human approve, and where does the action sit on the autonomy ladder? Third pass: break it on purpose — remove the audit log, or push a destructive action up to “act,” and watch the canvas warn you why governed autonomy just failed. The Canvas teaches the one skill a checklist on paper cannot: holding the traditional half and the AI half of every organ in view at the same time, which is the entire job of the architect and the entire content of your final.

When your canvas is complete and every gate is named, screenshot it. It is the first artifact of Project 14.

16.7 — The House on the Rock: What It Means to Build So It Stands

Here is the week’s question with the engineering attached. What does it mean to build a house that stands?

Psalm 127 will not let an architect be lazy with that question, because it refuses the two easy answers. It does not say the house stands because the laborers worked hard — it assumes they did, and says they can still labor in vain. And it does not say effort is pointless — the psalm is not a shrug. It says the standing of the house depends on its foundation, on something the builders did not themselves manufacture. “Unless the LORD builds the house, those who labor build in vain.” Jesus says the identical thing in engineering terms at Matthew 7:24–27: two builders, two houses, equal effort, and the flood reveals the only difference that ever mattered — rock or sand. The foundation is invisible until the flood, and then it is the only thing that matters.

That is a brutally accurate description of architecture. Every system looks fine on the demo day. The foundation — the trust boundaries, the autonomy gates, the audit log, the human who is accountable, the backup of the irreplaceable weight — is invisible right up until the flood: the prompt injection, the deepfake wire request, the agent that deleted the volume, the model that drifted, the region that “sold out.” On that day, the cleverness of your serving stack is worth nothing and the soundness of your foundation is worth everything. An AI-native architecture built on sand is one that maximized AI everywhere the demo rewarded and gated nothing the flood would test. An architecture built on rock is one whose foundation was laid for the flood it had not yet seen.

And there is a second, sharper edge for the AI age. The psalm locates the foundation in something the builder did not make. The administrator did not make the model — you wield a thing trained by others on data you did not curate, whose failure modes you inherit. Chapter 1’s stewardship question returns here at full size: faithfulness with what you did not make. The two-kingdoms instinct of the LCMS tradition is exactly the architect’s instinct — there is real authority delegated to you over this house, and there is a limit to that authority that you do not get to erase by being clever. A computer must never make a management decision is not only an IBM training slogan; it is the engineer’s form of “build on the rock you did not quarry.” You hold the judgment. You keep the account. You do not surrender either to the fast, confident, sometimes-wrong servant, however much leverage it gives — because the leverage is real and the flood is coming and the house has to stand. That is not piety bolted onto engineering. It is the reason the autonomy ladder has a top rung a computer may never climb.

Build the house. Lay the foundation for the flood. And do not mistake the labor — real and required as it is — for the thing the house finally rests on.

16.8 — Common Pitfalls

Pitfall: “AI-native” means bolting an AI demo onto a traditional org. Example: A capstone with a thriving AIOps story in monitoring and a completely blank AI half in backup, security, and governance. Fix: Fill every cell of the two-lane table in §16.1. If an organ has no AI half and no AI workload, justify the absence in writing. Blanks are where the grade — and the flood — find you.

Pitfall: Architecting on brand names instead of standards. Example: A diagram built around Vertex AI, Azure AI Foundry, TGI, and Open WebUI — three of which were renamed, deprecated, or relicensed in the last 18 months. Fix: Bet on the durable standards underneath (OTel, OpenAI-compatible API, Open Inference Protocol, MCP/A2A, OCI artifacts). Name products as current implementations of a standard, and date every “as of 2026” claim.

Pitfall: A governance narrative with no owner and no artifact. Example: A “Governance” section that says the org “takes AI risk seriously” but names no human, produces no model card, and points at no registry. Fix: Use the checklist in code/governance-checklist.txt. Every row needs an owner, an artifact, and a gate. A control without a controller is not a control.

Pitfall: Maximizing autonomy because the demo rewards it. Example: Putting delete_persistent_volume or rotate_credential on the “act” rung so the agent can “self-heal” without waking anyone. Fix: Place each action on the autonomy ladder by reversibility and blast radius, not by how impressive the demo is. Irreversible or security-sensitive actions stay at “recommend” or “approve.” Apply the Rule of Two.

Pitfall: Sizing the AI estate by vibes. Example: “We’ll self-host, it’ll be cheaper” with no token volume, no GPU sizing, and no crossover calculation. Fix: Run the numbers. Use the VRAM rules (~2/1/0.5 GB/B at FP16/INT8/INT4 plus KV cache) and code/estate_cost.py. Reserved/self-host wins only above high sustained volume; output tokens cost 4–8× input; agents amplify usage. State the crossover.

Pitfall: Treating the EU AI Act date as fixed. Example: A compliance plan that hard-codes “high-risk obligations apply August 2, 2026” with no hedge. Fix: Phrase it as “deferred to December 2, 2027 by the Digital Omnibus, pending formal adoption — re-confirm.” Design the logging and oversight now so a date change is a calendar event, not a rebuild.

Pitfall: Forgetting that some AI assets are irreplaceable. Example: A DR plan that backs up the VMs and databases but not the fine-tuned weights, curated datasets, or prompt library. Fix: Sort every AI asset by reproducible-vs-irreplaceable. Re-derivable embeddings and HNSW indexes can be rebuilt; fine-tuned weights and curated datasets cannot. Protect the irreplaceable with WORM/immutable, signed, off-site copies.

16.9 — Reps

Your reps for the week live in the exercises. These are the final conditioning before the capstone — each one rehearses one organ of the architecture so the whole body holds together when you assemble it. A preview:

• Draw the two-lane reference architecture from a blank page and defend every layer.
• Build and break an autonomy ladder — place actions on rungs, then move one wrong and explain the failure.
• Map one autonomous workflow to EU AI Act Art. 14 + Art. 12 and NIST RMF functions, and research the current enforcement date yourself.
• Run the cost crossover and write the self-host-vs-API recommendation for a real workload.
• Classify the whole 2026 stack as open-source / commercial / source-available and justify a low-lock-in build.

AI policy for the reps (Phase 2, the final week): AI is fully on and agentic — use it the way you will in the field. But the reps are built so an agent cannot finish them for you: every one ends in a judgment an agent cannot make — a recommendation, a tradeoff defended, a date you verified against a primary source, an owner you named. Keep your honest AI-usage notes; they become your agent-log.txt. A short Check Your Reps quiz sits on this page to confirm the concepts landed before you build.

16.10 — This Week’s Project

This week’s project is the one the whole course was building toward: Project 14 — “Architect the 2030 Organization,” your FINAL capstone. Full spec in Project 14. It is a take-home build plus a 60-minute live session, open-AI and agentic, with an agent-log.txt required — and it is graded most of all on the architecture and governance documents you write first, before any tool touches a server.

You will produce the full document set for an AI-native 2030 organization: an architecture diagram, an AI strategy, an automation plan, a security plan, a cost analysis, and a governance framework — covering the traditional components (identity, virtualization, monitoring, security, backup) and the AI components (local LLM infrastructure, AI governance, AI-assisted monitoring, AI-assisted automation, AI security controls, AI disaster recovery). Normal tier asks for a complete, defensible architecture for a mid-size organization. Medium tier adds a deeper cost crossover and a threat model. Hard tier demands the architect’s judgment an agent cannot supply — a written recommendation, defended with measurements, on the one or two decisions the organization will live with for years. That memo is where the human-in-the-loop thesis is graded.

16.11 — Coach’s Final Word

Sixteen weeks ago you were an administrator. You ran commands, you fixed things, you kept the lights on. This week you are an architect — and the difference is not that you learned more commands. It is that you learned to hold the whole house in view and to decide, deliberately and in writing, where the judgment lives. That is the skill this book exists to build, and it is the skill no agent can take from you, because the moment you hand it away you have stopped being the architect and started being one more thing the architecture has to govern.

The thesis of this book was a single sentence: AI is now both your most powerful tool and your most demanding workload; the administrator wields the one and governs the other without surrendering the judgment that keeps the system trustworthy. You have now wielded it — copilots, agents, AIOps, generated IaC — and you have governed it — GPUs, weights, vector stores, autonomy ladders, the spend cap, the audit log. And in every chapter the spine held: the human stays in the loop where the judgment lives. Carry that out of the classroom. The field will offer you, again and again, a fast and confident servant that will take the judgment off your hands if you let it. Don’t let it. Keep the account.

Build the house on the rock — the foundation you did not quarry, laid for the flood you have not yet seen. Be found faithful with what you did not make. That is the whole vocation, and it is enough for a long career.

You have done the work. You showed up, you did the reps, the keyboard was the gym, and the body of an architect is the thing you built. Go architect the 2030 organization — and make it stand.

See you next week. And — for this course — well done.

Up next: Read the exercises for the final conditioning reps, then build Project 14 — Project 14: Architect the 2030 Organization, the capstone final. Keep Appendix A (the lab + git workflow) open for the toolchain, Appendix B (local + cloud AI) for the serving stack, and Appendix C (the agentic-AI rules) for the autonomy ladder and agent-log.txt discipline. Back one week to Chapter 15 — AIOps and Autonomous Operations — for the self-healing loop this architecture governs. This is the last chapter of the course. Now go build the house.