Agentic Devops with Claude Code

In operations the action IS the outcome — there's no git revert for a bad production restart. This opening lecture of Agentic DevOps with Claude Code hands a real bug to Claude Code, watches it get "fixed" in fifteen minutes, then watches the same AI agent ship a change that looks right and is wrong. You'll see why Agentic DevOps — AI agents driving real infrastructure, Kubernetes clusters, and production systems — needs a different discipline than AI-assisted coding, and why DevOps engineers, SREs, and platform teams adopting Claude Code and other AI coding agents for operations need a verification-first method, not vibes-based automation.

Three terms, three different jobs — and confusing them is why so many "AI DevOps" projects stall. AIOps watches your systems, a sensor and alerting layer built on anomaly detection. AgentOps watches your agents, the observability layer for LLM and AI agent behavior. Agentic DevOps with Claude Code is different again: the AI agent itself diagnosing, changing, and verifying production systems inside permission boundaries you set. Get this distinction right before anything else in this Claude Code course — it's the difference between an AI coding assistant that suggests fixes and an autonomous DevOps agent that operates Kubernetes, Terraform, and CI/CD pipelines directly.

Meet Northstar Commerce, the fictional e-commerce platform you'll operate on for the entire Agentic DevOps course: an orders-api and inventory-api microservice pair, Terraform-managed cloud infrastructure, Kubernetes and Helm deployment assets, a CI/CD pipeline, and live incident tickets. This is the same repository across every module — a realistic, fault-injectable environment for practicing AI agent-driven diagnosis, remediation, and verification with Claude Code, the way a DevOps engineer or SRE would work a real production incident rather than a toy demo.

A step-by-step, real-time walkthrough of handing a broken readiness check straight to Claude Code: branch first, a four-line prompt with symptom, evidence, scope, and the deterministic check that proves it — and the fix lands before the explanation even catches up. This is Agentic DevOps in miniature: an AI coding agent reading logs, forming a hypothesis, editing code, and re-running verification in a tight loop, the same diagnose-change-verify workflow you'll use on Kubernetes manifests, Terraform configs, and CI/CD pipelines throughout this Claude Code for DevOps course.

Almost everything written about AI coding agents assumes a cheap, reversible mistake — tests catch it, code review catches it, git revert undoes it. Operations work has no revert: a bad kubectl rollout, a destructive terraform apply, or a mis-scoped database migration is real and immediate. This lecture unpacks why that one difference changes every control you need to put around an AI agent operating infrastructure, and why treating Claude Code as "just another coding assistant" in a DevOps, SRE, or platform engineering context is a dangerous category error.

An AI agent that can already write the fix still needs a method around it, or speed just becomes a faster way to break production. This lecture builds the diagnose-change-verify loop that keeps a capable Claude Code agent from being a dangerous one: diagnose with bounded evidence instead of guessing, change only on a branch, and verify with a deterministic check that actually ran — never "it looks fine." This loop is the operating model for every module that follows, whether the agent is touching Kubernetes, Terraform, a CI/CD pipeline, or a production database.

Before you ask anyone — human or AI agent — to diagnose a problem, you decide what they're allowed to look at. This lecture explains why handing Claude Code the whole repository is worse than handing it the two files that actually matter, and how to scope evidence on purpose instead of letting an AI agent wander a production codebase. Bounded evidence is a core context engineering discipline for Agentic DevOps: it keeps the context window focused, keeps diagnosis fast, and keeps an autonomous agent from touching infrastructure it has no business reasoning about.

A repair is a proposal, not an edit to main. One command — git checkout -b — turns every AI agent change into something you can read, diff, and reject before it ever touches a shared branch. This lecture makes branch-only changes a non-negotiable safety boundary for agentic DevOps workflows: whether Claude Code is patching a Kubernetes manifest, a Terraform module, or application code, the review discipline of pull requests and code review stays exactly where it belongs — in front of the human, every single time, never bypassed for speed.

"Looks fixed" is the agent's opinion about its own work, and opinions are not evidence. A deterministic grader that curls the live endpoint, reads the source, and checks the Helm chart is not an opinion — it's a repeatable, scriptable check that either passes or fails. This lecture explains why verification has to run, not just sound plausible, and why every Agentic DevOps workflow with Claude Code needs an automated, deterministic grader as the final gate before a change is trusted — the same discipline that separates reliable CI/CD pipelines from AI agents that hallucinate success.

Explain, Suggest, Draft, Execute-with-approval, Execute-autonomously — five positions on an autonomy dial you set for every task, and how to decide, task by task, how much of the diagnose-change-verify loop you actually hand to an AI agent. This lecture closes out Module 1 by connecting the autonomy ladder to real Agentic DevOps risk management: low-blast-radius tasks like reading logs can run autonomously, while a production database migration or a Terraform apply stays firmly at explain-and-approve, no matter how capable Claude Code becomes.

Hands-on lab: fix a real bug in the Northstar Commerce platform using the diagnose → change → verify loop. Gather bounded evidence, work on a branch, and let a deterministic grader decide whether the repair actually landed. Agentic DevOps lab, Claude Code, AI agent debugging, SRE incident repair, deterministic verification.

Full written lesson and deep dive for Module 1 — what Agentic DevOps asks of you, AIOps vs AgentOps vs Agentic DevOps, the Northstar Commerce platform, why AI for operations differs from AI for code, the diagnose-change-verify loop, bounded evidence, branch-first repair, deterministic grading, and the five operational modes with the autonomy ladder. Reference reading for AI agents in DevOps and SRE.

Claude Code has three separate boundaries — availability, permission, and sandbox — and most people merge them into one mental model, which is exactly where the risk hides. This opening lecture of Module 2 names all three before the module builds each one out in detail: what Claude Code is technically able to run, what you've explicitly allowed it to do, and what the sandbox physically blocks regardless of permissions. Understanding this three-layer boundary model is the foundation for safely running Claude Code and other AI coding agents against real infrastructure, cloud accounts, and production systems in any Agentic DevOps or platform engineering setup.

A quick, practical walkthrough of installing Claude Code and authenticating it against your account. By the end of this lecture you'll have a working Claude Code CLI on your own machine, ready to run against the Northstar Commerce codebase used throughout this Agentic DevOps course. This is the on-ramp for every DevOps engineer, SRE, or platform team member who wants to start using Claude Code as an AI coding agent for real infrastructure and operations work, not just toy examples — installation, authentication, and your first verified session.

A closer look at the three boundaries introduced in Module 2's opener: availability (what Claude Code can technically execute), permissions (what you've explicitly allowed), and the sandbox (what's physically blocked no matter what). This lecture separates each layer so DevOps engineers and SREs can reason precisely about AI agent safety instead of treating "permissions" as one fuzzy concept — a critical distinction when Claude Code is operating against Kubernetes clusters, cloud infrastructure, and production systems where the wrong assumption about a boundary can be costly.

Claude Code permission rules boil down to three outcomes for every tool call: allow, ask, and deny. This lecture explains how allow/ask/deny rules are written and evaluated, and how they let you give an AI coding agent broad autonomy for safe, reversible actions like reading files and running tests, while gating anything destructive — a database write, a terraform apply, a kubectl delete — behind an explicit human approval. Getting these permission rules right is the single most practical skill for running Claude Code safely across DevOps, SRE, and platform engineering workflows.

Claude Code ships five permission modes — plan, manual, acceptEdits, auto, and bypass — and this lecture maps each one to the level of trust and risk it implies. You'll see how plan mode forces the agent to propose before acting, how acceptEdits and auto trade oversight for speed, and why bypass mode should almost never touch a production system. Choosing the right permission mode, task by task, is how experienced DevOps engineers and platform teams get real leverage from Claude Code and other AI coding agents without handing over more control than a given task deserves.

A common misconception: adding a command to --allowedTools does not make Claude Code able to run it — availability and permission are two separate questions, and this lecture explains exactly why. You'll see the difference between a tool the agent can technically invoke and a tool it's been granted approval to use without asking, and why conflating "allowed" with "auto-approved" leads to either an agent that's unexpectedly blocked or one that has more autonomy than you intended. Essential nuance for anyone configuring Claude Code permissions for real DevOps and SRE workflows.

Permissions are policy; the sandbox is physics. This lecture explains exactly what Claude Code's sandbox actually blocks at the OS level — filesystem writes outside the project, network calls to unapproved hosts — regardless of what your allow/ask/deny rules say. Understanding this hard, non-negotiable enforcement layer matters for Agentic DevOps in particular: it's the backstop that holds even if a permission rule is misconfigured or a prompt injection tries to trick the AI agent into acting outside its intended scope, which is exactly the failure mode a defense-in-depth security posture is built to catch.

Availability, permission, and sandbox don't operate independently — they compose, and this closing lecture of Module 2 shows exactly how the three gates stack to produce Claude Code's actual runtime behavior for any given action. Understanding the composition, not just each gate in isolation, is what lets you design a permission posture with confidence: predicting precisely what an AI agent can and cannot do before it ever touches your Kubernetes cluster, cloud infrastructure, or production database, rather than discovering the answer the hard way during an incident.

Hands-on lab: prove the three boundaries around a Claude Code agent. Exercise allow/ask/deny permission rules, every permission mode from plan through bypass, the limits of --allowedTools, and what the sandbox actually blocks — then show how the three gates compose. Claude Code permissions lab, AI agent sandboxing, least privilege, DevOps security.

Full written lesson and deep dive for Module 2 — what Claude Code is allowed to do on your machine, installation and authentication, the three boundaries around an AI agent, permission rules and modes, why --allowedTools does not remove a tool, what the sandbox blocks, and how the three permission gates compose. Reference reading for Claude Code setup, agent permissions and sandboxing.

Context is a budget, not a bucket — everything an AI agent knows shares one finite context window. Pack it with a 500-line CLAUDE.md and you haven't made Claude Code smarter, you've buried the three rules that matter under three hundred that don't. This opening lecture of Module 3 introduces context engineering as a first-class discipline for Agentic DevOps: the practice of deliberately curating what an AI coding agent loads, so diagnosis stays fast and accurate on real infrastructure instead of drowning in irrelevant repository noise.

The permission boundary from Module 2 keeps an AI agent safe; context is what makes it correct. This lecture breaks down exactly what competes for space inside Claude Code's context window — system prompt, CLAUDE.md, tool outputs, conversation history — and distills the one rule the rest of Module 3 builds on: every token you spend on low-value content is a token you don't have for the evidence that actually matters. Essential context engineering fundamentals for anyone running Claude Code against large, real-world DevOps and infrastructure codebases.

CLAUDE.md is your operating contract with Claude Code — think of it as what you'd hand a contractor on day one, not the full building code. This lecture works through what belongs in it (the non-obvious, stable rules an AI agent would otherwise get wrong) and what actively hurts by being there (anything the agent can just read on demand). You'll also see the /init workflow for generating a starter CLAUDE.md from an existing repository. Getting this operating contract right is one of the highest-leverage context engineering skills in Agentic DevOps with Claude Code.

One root CLAUDE.md listing every rule for every directory doesn't scale — Claude Code reads all of it, every session, whether or not it's relevant to the task at hand. This lecture explains why directory-scoped CLAUDE.md files matter for a real multi-stack repository like Northstar Commerce: a Python service, a Go service, a Terraform estate, and a Kubernetes platform each get their own scoped rules, layered on top of the global root contract, so the AI agent's context budget only pays for what's actually relevant to the stack it's working in.

"Inventory-api is down" — says who, checked when, with what command? A bare claim like that is a rumor, not evidence. This lecture introduces the evidence contract: a structured format that labels every fact an AI agent collects with its source, collected_at timestamp, collector, and uncertainty, so stale or unsourced claims can never pass as verified truth. This is the foundation of trustworthy incident diagnosis in Agentic DevOps — the discipline that keeps Claude Code's investigation of a production issue auditable, reproducible, and honest about what it actually knows versus what it's assuming.

kubectl get pods -o yaml with no limit works once, then quietly poisons the context budget every time after. This lecture teaches bounded queries — field selection (-o jsonpath instead of -o yaml), sampling (--tail=50 instead of the full log), and hard output caps (| head -100) — the query habits that keep evidence collection from drowning Claude Code's context window. The rule of thumb: ask for the field you need, not the haystack it lives in. A practical, immediately applicable skill for anyone running AI agents against Kubernetes, Docker, and cloud infrastructure command-line tools.

What happens when the work outlives the context window — both within a session, when Claude Code compacts, and across sessions, through operational memory? This closing lecture of Module 3 covers checkpointing load-bearing facts to a file before a lossy compaction event erases them, and the discipline of tagging every persisted memory entry with provenance so a stale or injected claim never gets silently promoted to trusted procedure. A critical safety pattern for any long-running Agentic DevOps workflow with Claude Code, where an incident investigation or migration can easily outlast a single context window.

Hands-on lab: build the Context Pack. Write a CLAUDE.md that earns its tokens, add directory-scoped files, define an evidence contract, and replace haystack queries with bounded ones — then measure the difference. Context engineering lab, CLAUDE.md, prompt engineering for agents, token budget, agent memory and compaction.

Full written lesson and deep dive for Module 3 — why context is a budget and not a bucket, the shared context window, what belongs in CLAUDE.md and what does not, directory-scoped files, evidence contracts, bounded queries, and compaction, checkpoints and agent memory. Reference reading for context engineering, token economics and AI agent memory design.

This lecture opens Module 4 of Agentic DevOps with Claude Code by exposing a blind spot every platform engineering team eventually hits: your Claude Code AI agent runs are completely unmetered. You already track CPU, memory, and request rates for your infrastructure — but how much does each agentic DevOps run actually cost, which model ran it, and how many tool calls did it make? DevOps engineers, SREs, and platform teams running Claude Code dozens of times a day need this answer before agent spend becomes a surprise line item. This session sets up the two-part fix: deliberate model and effort staffing decisions, and a measured, auditable Agent Run Ledger for every AI agent run.

Choosing a Claude Code model — Opus, Sonnet, or Haiku — is a staffing decision, not a default setting. This lecture teaches DevOps engineers and platform teams to match model capability to task failure cost, the same way you'd staff a human team: a principal engineer for a production migration, a junior for a variable rename. Learn why sending your most capable, most expensive AI agent to summarize a changelog is like flying in a staff engineer to reset a password — and why the wrong default compounds into a real FinOps and cost engineering problem across every branch, every engineer, all day.

Effort is the second staffing dial in Claude Code cost engineering: not who does the work, but how hard they think before acting. This lecture separates the effort dial from model choice for agentic DevOps practitioners — a cheap model at high effort and a capable model at low effort are both valid configurations depending on the task. Learn when to ask your AI agent for a fast gut-read versus a deliberate, show-your-working investigation, and why conflating model and effort leads DevOps engineers and SREs to overpay for reasoning nobody needed.

Investigator, implementer, reviewer, summarizer — this lecture maps Claude Code's four common agent roles to concrete model-and-effort staffing choices for platform engineering teams. Learn why the reviewer role almost always deserves your top-tier model at high effort (underpaying here is a false economy against the cost of a missed defect), while the summarizer role should run on the cheapest model at the lowest effort. This is the staffing playbook DevOps engineers and SREs need before splitting Claude Code work across specialized AI subagents in later modules.

Every Claude Code session generates cost, token, and behavior data — and right now it evaporates the moment the session ends. This lecture reframes the AI agent run itself as evidence, extending the provenance discipline from Module 3's context engineering to the agent's own execution. DevOps engineers and platform teams learn why an unmetered Claude Code run is like a contractor who does good work but hands you no invoice: you can't budget for it, compare configurations, or catch the run that quietly cost triple. This sets up the Agent Run Ledger built later in this module.

This lecture shows DevOps engineers and SREs how to make Claude Code's AI agent runs observable using OpenTelemetry (OTLP) — the same instrumentation standard already running across your infrastructure stack. Learn how Claude Code emits metrics and log-record events over OTLP to a local collector, and how to roll that raw telemetry into an Agent Run Ledger: one auditable row per run capturing model, effort, token counts, cost, tool calls, and permission decisions. This is the core mechanism behind cost engineering and FinOps for agentic DevOps, turning every Claude Code run into a measured, comparable record.

Turn your Agent Run Ledger into a live control, not just a post-mortem. This lecture teaches platform engineering teams to set per-role token and cost budgets, spend alerts, and model regression checks on Claude Code AI agent runs — the same operational discipline as a latency or error-rate SLO, now applied to agent cost. Learn why a task that quietly jumps from $0.10 to $1.00 is a signal to investigate, not noise, and how DevOps engineers and SREs turn cost engineering into an automated gate rather than a monthly surprise.

Hands-on lab: build the Agent Run Ledger. Instrument agent runs with OpenTelemetry, record model, effort, tokens and cost per run, then add budgets, alerts and a cost regression check. Agent observability lab, OpenTelemetry, LLM cost engineering, FinOps for AI agents, token metering.

Full written lesson and deep dive for Module 4 — why agent runs are unmetered by default, model choice as a staffing decision, effort levels, mapping models and effort to agent roles, the run as evidence you cannot yet see, OpenTelemetry and the Agent Run Ledger, and budgets, alerts and regression checks. Reference reading for AI cost engineering, model selection and agent observability.

A capable AI agent with a vague instruction is the most expensive way to get the wrong thing built. This opening lecture of Module 5 shows why agent tasks fall apart when nobody is watching — scope drift, a change that looks finished and is not, and a "done" nobody can defend in review. You'll meet the four controls that hold an agentic DevOps task together with Claude Code: a written task contract, plan mode, an isolated git worktree, and verification the repository owns. Essential structure for DevOps engineers, SREs and platform engineering teams running AI agents on real infrastructure.

Write the task down before the agent runs, and most agent failures stop being possible. This lecture teaches the task contract for AI agents in Claude Code: intent, target, allowed and denied actions, acceptance criteria, stop conditions and rollback. Learn why acceptance criteria written in advance are the only defence against an agent that grades its own homework, and how DevOps and SRE teams turn a Slack-sized request into a bounded, reviewable unit of agentic work on Kubernetes, Terraform and production services.

Plan mode separates thinking from acting — the cheapest safety control in Claude Code. This lecture shows how plan mode lets an AI agent read your repository, reason about an infrastructure change and produce a step-by-step plan while touching nothing, so you review intent before a single file is edited. Learn when platform engineers should default to plan mode on unfamiliar systems, how to check a plan against your task contract, and why reviewing a plan is far cheaper than reviewing a diff in agentic DevOps work.

Give the AI agent its own room to work in. This lecture covers isolating Claude Code agent work with git worktrees, checkpoints and rewind: a separate working tree off main so an agent's changes are contained, reviewable and disposable. Learn how DevOps engineers and SREs use worktrees to run agentic experiments without touching the branch everyone else depends on, how checkpoints make a long agent session recoverable, and why isolation is what makes "let the agent try it" a safe sentence in platform engineering.

Never let the agent that wrote the change be the one that grades it. This lecture contrasts agent self-assessment with repository-owned verification in Claude Code: tests, linters and a grading script that live in the repo and have no blind spot aligned with the agent's. Learn why repo-owned checks are reproducible, don't hallucinate, and catch the regressions self-assessment misses — and how DevOps engineers and SREs turn acceptance criteria into automated checks so green becomes the definition of done for agentic work.

"The tests pass" is not the same as done. This closing Module 5 lecture defines what finishing an AI agent task actually means in agentic DevOps: tests green, evidence of what changed, a rollback command, honest residual risk, and a cost receipt from the Agent Run Ledger. Learn the logbook discipline platform engineering teams use to make agent work accountable rather than merely successful — so an SRE can defend a Claude Code change in review, in a postmortem, and to whoever has to trust it reached production safely.

Hands-on lab: run the plan → execute → verify loop end to end. Write the task contract before the agent runs, use plan mode to separate thinking from acting, isolate work in a git worktree with checkpoints and rewind, and let the repository own verification. Claude Code plan mode lab, git worktrees, task contracts, agent verification, DevOps automation.

Full written lesson and deep dive for Module 5 — why plans fail without a contract, writing the task contract first, plan mode, worktrees, checkpoints and rewind, verification the repository owns rather than the agent infers, and what “done” actually means for an agent task. Reference reading for the plan-execute-verify loop and agentic software delivery.

Runbooks rot. The steps were right when someone wrote them and the platform has moved since. Why packaging a procedure as an Agent Skill beats maintaining a wiki page nobody reads, and what changes when the runbook becomes something the agent can actually execute. Keywords: Claude Code Agent Skills, runbook automation, SKILL.md, DevOps procedures, agentic SRE, operational knowledge.

Four primitives, four different jobs, and the cost of putting a task in the wrong one. A rule is always-on context, a skill is a procedure loaded on demand, a prompt is a one-off ask, a subagent is a provisioned role. How to decide which one a task belongs in. CLAUDE.md rules, Agent Skills, slash commands, subagents, context engineering.

Anatomy of a SKILL.md file: YAML frontmatter that decides when it fires, the body that says what to do, and the scripts sitting beside it that do the deterministic work. How Claude Code discovers skills, what the description field really controls, and why the file is a contract rather than a suggestion. SKILL.md, frontmatter, skill discovery, Claude Code plugins.

Every skill's description sits in context at all times, so a library of them has a standing token cost. Progressive disclosure is the fix: the skill is a table of contents, and the detail loads only when the skill actually fires. Includes the measured three-tier load — roughly a twelfth of the library in context at rest. Token budget, context engineering, skill libraries, on-demand loading.

Every SKILL.md body has two halves that should never blur: a deterministic zone where a script gathers evidence, and a reasoning zone where the model interprets it. Why pushing collection into a script makes the skill cheaper and more reliable — plus the same question answered three ways, and the cheapest run being the only one measuring over a real window. Also covers disable-model-invocation and context: fork: who may trigger a skill, and where it runs.

Three test cases, not one. A positive case proves the skill fires and works; a negative case proves it catches a known-bad input; an ambiguous case proves it stays quiet on a neighbouring task. The two failures a positive test can never see — always-says-fine, and fires-on-everything. Skill testing, CI validation, agent regression tests, DevOps automation quality.

Hands-on lab: turn a rotting runbook into a working Agent Skill. Write the SKILL.md frontmatter that decides when it fires, split the body into a deterministic collection script and a reasoning zone, measure the three progressive-disclosure load tiers, then prove it with positive, negative and ambiguous test cases. Compares the same error-budget question across models and shows which run actually measured over a real window. Claude Code skills lab, runbook automation, skill testing, token budget, FinOps.

Full written lesson and deep dive for Module 6 — why runbooks rot, choosing between a rule, a skill, a prompt and a subagent, the anatomy of SKILL.md, progressive disclosure and the standing token cost of a skill library, the deterministic and reasoning zones, disable-model-invocation and context: fork, and the three-case testing discipline. Reference reading for Claude Code Agent Skills, runbook engineering and agentic DevOps.

Every tool you hand an AI agent is a design decision, not a convenience. This opening lecture of Module 7 shows why the tool surface — raw CLI, wrapper script, Claude Code skill, or MCP server — decides how much authority the agent holds, how readable its output is, and who keeps the credentials. Essential framing for DevOps engineers, SREs and platform engineering teams wiring Claude Code into Kubernetes, Terraform and production APIs: you are not picking a format, you are drawing a capability boundary.

Four ways to give a Claude Code agent a capability, and they are not interchangeable. This lecture walks the tool surfaces in order: the raw CLI the agent shells out to, a wrapper script that narrows it, a skill that packages the procedure, and an MCP server that exposes typed tools over a real protocol. Learn what each surface costs in setup, what it buys in control and structured output, and how platform engineers reason about them when handing an AI agent access to infrastructure tooling.

Choose the interface with a framework, not a preference. This lecture runs an agent task through five criteria — authority, ambiguity, output structure, authentication and frequency — and shows how the answers point at a CLI, a script or an MCP server. Learn why high-stakes actions and typed downstream consumers pull toward MCP while cheap read-only exploration stays on the CLI, and how DevOps engineers and SREs apply the same routing logic they already use for privileged operations to AI agent tooling.

A capability that does not exist cannot be misused. This lecture builds the read-only MCP observer: a server exposing only get_health, get_readiness and get_logs, with no restart, scale or apply tool anywhere in it. Learn why that structural absence beats a deny rule — a deny rule is a sign plus a guard who must catch every attempt, while a missing tool is a machine with no slot for the dangerous item — and how platform engineering teams use it to give Claude Code safe production visibility.

An MCP server connected to every session is a capability granted to every session. This lecture covers configuring MCP in Claude Code and scoping servers to individual subagents, so an investigator agent gets read-only observability while a separate role holds anything that writes. Learn the configuration mechanics, how scoping composes with the permission boundary and sandbox from earlier modules, and why least-privilege per agent role is how DevOps teams keep an AI agent fleet safe at scale.

A concrete, measured three-way comparison for a real DevOps task. This lecture puts HashiCorp Agent Skills against the Terraform MCP server against the raw Terraform CLI, and scores each on authority control, output structure, credential handling and setup cost. Learn why skills give you readable, transparent procedures on tooling you already run while an MCP server gives you a typed contract and a genuine capability boundary — and how SREs and platform engineers pick between them per task rather than once for the whole team.

Hands-on lab: engineer the tool surface. Compare raw CLI, a wrapper script, an Agent Skill and an MCP server on the same task, build a read-only MCP observer, scope MCP servers to subagents, and measure the three-way trade-off. Claude Code MCP lab, Model Context Protocol, agent tool design, least privilege, Terraform and Kubernetes automation.

Full written lesson and deep dive for Module 7 — the four tool surfaces on a flexibility-to-least-privilege spectrum, the five-criteria framework for choosing between CLI and MCP, the read-only MCP observer, scoping MCP servers to subagents, and a measured CLI vs Skill vs MCP comparison. Reference reading for MCP, agent tool interfaces and DevOps tooling design.

Intent controls versus enforcement controls in Agentic DevOps. Why CLAUDE.md rules, skill instructions and permission preferences all fail the same way — the model misinterprets — and why destructive operations like terraform apply on production need a control that holds regardless of what the agent decided. Keywords: Claude Code hooks, AI agent guardrails, enforcement controls, DevOps automation safety, deterministic policy, agent blast radius.

The two kinds of control and why their failure modes are opposites. An intent control — a CLAUDE.md rule, a skill instruction, a permission preference — fails silently when the model misinterprets. An enforcement control — a hook, an IAM policy, an RBAC role, an admission webhook — fails only when misconfigured, loudly and testably. The sign on the door versus the badge reader. Keywords: AI agent guardrails, DevOps safety controls, defense in depth, Claude Code hooks, policy enforcement.

The four threat patterns every agent guardrail maps to: wrong target, excess blast radius, irreversible destruction and data leakage. None require a malicious model — each is a plausible misreading of an ambiguous ticket. Threat modeling for AI agents, DevOps risk analysis, Kubernetes safety, secret leakage prevention, agentic SRE.

How a Claude Code PreToolUse hook works: a deterministic shell script that receives the proposed tool call as JSON on stdin and blocks by exiting non-zero or returning permissionDecision: deny. Fail-closed design, PostToolUse lifecycle events, Bash tool gating, hooks vs prompts, shell-based policy enforcement for AI agents.

A hook is code, so you test it like code. Build a table-driven suite of deny and allow cases, prove the gate fails closed on bad input, then measure how far a text matcher actually reaches — subshells, eval, quoted flags and variables that reach the same destructive effect without matching the pattern. Hook testing, CI policy gates, regression tests for safety controls, agent security limits.

Enforcement the target system applies, not your script. Read-only kubeconfigs, Kubernetes RBAC verbs, cloud IAM policies, admission controllers and OPA/Conftest policy-as-code. Why an identity with no write verb cannot write, however the command is spelled — least privilege, defense in depth, RBAC for AI agents, Kubernetes admission webhooks.

GitOps as the strongest enforcement layer: the agent proposes on a branch, a human reviews the PR, and Argo CD is the only identity with cluster write access. Covers desired state in Git, drift detection, selfHeal, reconciler-only writes and removing the agent from the write path entirely. GitOps, Argo CD, continuous reconciliation, agentic change management.

Hands-on lab: build the Change Gate PreToolUse hook and the Environment Contract, then prove every control holds. Write deterministic deny rules for terraform apply on production, protected-namespace deletes, all-namespaces mutations, secret decoding and docker push; test them like code with positive, negative and boundary cases; wire a fail-closed env-check and a read-only kubeconfig. Claude Code hooks lab, GitOps guardrails, Kubernetes RBAC, Argo CD, DevOps automation.

Full written lesson and deep dive for Module 8 — intent versus enforcement controls, the four-pattern threat surface, deterministic Claude Code hooks, least-privilege identities and RBAC, admission controllers, the reconciler-only GitOps write path, and the Environment Contract. Includes the incident walkthrough of an ambiguous ticket leading to a destructive command. Reference reading for AI agent security, DevOps guardrails and agentic SRE practice.

The generalist agent problem in Agentic DevOps: one agent with every tool can do the wrong job at the wrong moment. Why an incident investigator holding Edit and Write is a capability you should remove, not a rule you should write. Keywords: Claude Code subagents, role-based AI agents, separation of duties, least privilege, DevOps automation, agentic SRE teams.

One agent with every tool can do every job — which means it can do the wrong job at the wrong moment. Why an incident investigator holding Edit and Write is a capability you should remove rather than a rule you should write, and what separation of duties buys you on a real platform team. Keywords: Claude Code subagents, role-based AI agents, separation of duties, least privilege, agentic SRE.

Agent files in .claude/agents/ — Markdown with YAML frontmatter declaring a subagent's identity and provisioning, with the body as its system prompt. A Role Bundle is the whole package: tools, permissions, model, turn budget and handoff line — plus the caveat that an agent file is provisioning, not a security boundary. Claude Code agent files, subagent configuration, tool scoping, AI agent provisioning.

Model choice as a staffing decision applied to roles: Haiku for a FinOps analyst pricing plans, Sonnet for an SRE investigator and IaC engineer, Opus for security review and independent change review. Plus turn budgets and worktree isolation to bound a runaway. Claude model selection, cost engineering, effort levels, agent turn limits, git worktree isolation.

Two ways to bound a runaway agent. A turn budget bounds depth — the triage time-box that forces a role to converge and hand off rather than spin. A git worktree bounds space — each authoring role gets its own checkout on its own branch, so concurrent changes stay isolated until review. Agent turn limits, git worktrees, parallel agent isolation, runaway control.

Why a role's output must be a JSON packet, not free text: sources forces provenance for every claim, out_of_scope declares the gaps honestly, and the next role acts instead of re-investigating. Includes the deterministic validator that rejects a confident hypothesis with no sources as contamination. Multi-agent handoff, agent orchestration, provenance, contamination control.

How you know the boundaries hold: role-authority-check.sh reads a role's declared tools and answers "is this role structurally capable of a write?" with a fixed rule and no model in the loop. Assert what each role can do and what it cannot — then run it in CI so a bad grant fails the build. Authority regression tests, CI policy checks, agent testing, deterministic safety verification.

Hands-on lab: assemble six Role Bundles as Claude Code agent files, right-size each role’s model and turn budget, wire the structured handoff packets, and prove every boundary with an authority regression matrix. You will watch a read-only SRE investigator hit a missing write capability rather than a rule, and run role-authority-check.sh over the whole team. Claude Code subagents lab, agent files, least privilege, CI policy testing, DevOps automation.

Full written lesson and deep dive for Module 9 — why a team beats a generalist, what a Role Bundle is, why an agent file is not a security boundary, model and effort right-sizing per role, turn budgets and worktree isolation, structured handoffs, memory and provenance, the six-role team, and the Authority Regression Matrix. Reference reading for multi-agent DevOps, Claude Code subagents and agent security design.