Appendix C — The Agentic-AI Toolkit

“The simple believes everything, but the prudent gives thought to his steps.” — Proverbs 14:15 (ESV)

This is the policy-and-setup document the whole of Phase 2 depends on. Read it before Week 9, and re-read the rules section before every Phase 2 project. The toolkit is the easy part. The discipline is the point — and in this book, where the agent does not just write code but runs your infrastructure, the discipline is the entire job.

Through Phase 1 (Weeks 1–8) you used AI the way a senior administrator uses a sharp junior: it suggested a command, drafted a runbook, explained a stack trace — and you typed every command and touched every box. The AI was a conversational partner. Phase 2 advances to agentic AI, and on a production system the difference is not cosmetic. It is the difference between an assistant who hands you the wrench and one who reaches into the running engine himself.

C.1 — What “Agentic” Means

A chatbot answers. An agent acts. Given a goal and access to your environment, a coding-and-ops agent will, on its own, across many steps:

• read your files, configs, and logs to understand the system,
• edit and create files — playbooks, manifests, scripts, unit files,
• run commands — install packages, restart services, apply a Terraform plan, kubectl apply, query a database,
• read the output, notice it failed, and iterate — diagnosing and re-running until it believes the goal is met.

That loop — observe, act, observe, act — is what makes it an agent rather than a chatbot. It is enormously more powerful. A remediation that would have been twenty rounds of copy-paste in Phase 1 becomes one instruction the agent carries out end to end. This is the same loop the 2026 self-healing tools run — Datadog’s Bits AI SRE, PagerDuty’s SRE Agent — detect the anomaly, diagnose from telemetry and a runbook, propose and execute a fix.

It is also enormously more dangerous. A chatbot that hallucinates wastes a paragraph. An agent that misunderstands can systemctl stop the wrong service, kubectl delete a live namespace, drop a database table, push a hallucinated firewall rule, or leak a secret into a commit — and then keep going, building more on top of the mistake at machine speed. Power and danger are the same property seen from two sides.

Coach’s Note — The mental model that keeps you employed: an agent is a fast, tireless, literal-minded junior with root, sudo, and cloud admin — and no fear. It will do exactly what you said, at speed, including the part you didn’t mean and the production system you forgot to fence off. Your job is not to be amazed by it. Your job is to govern it like the liability it is and wield it like the asset it can be. That double posture is this book’s whole thesis.

C.2 — Setting One Up

This course is vendor-neutral on purpose. Agentic tooling improves monthly and renames itself quarterly; the durable skill is directing an agent and keeping judgment in your hands, and that transfers across all of them. Do not over-invest in one product’s quirks.

As of 2026, any current, competent, code- and command-capable agent works. The serious options cluster into two shapes:

• A coding-agent CLI — a command-line tool you run inside a project or ops folder and give tasks to. Most of this course’s examples assume one, because the terminal is where administration lives.
• An agentic editor extension — an in-editor agent (see Appendix A) that can read your repo, edit files, and drive a terminal.

Pick one that meets three bars:

1. It operates on a workspace you grant it — a folder, a repo, a scoped set of credentials — and does not reach outside it. You are delegating a boundary, not handing over the keys to the estate.
2. It has a free or low-cost tier sufficient for coursework. You should not need an enterprise contract to pass this class.
3. It shows you what it is about to do and asks before consequential actions. Prefer a tool with an explicit approval/confirmation mode, and use it. Most current agents (Claude Code, Cursor, GitHub Copilot’s agent, the OpenAI and Google agent SDKs, and the like) support permission allowlists and pre-action hooks — turn them on.

Set it up, point it at a throwaway practice folder first — never a project repo, never anything touching production — and give it a trivial task: “create hello.sh that prints the hostname, run it, and show me the output.” Watch every place it ran a command. That watching habit is the skill.

Coach’s Note — Run the agent in a git repo, always, and against a sandbox or dev environment, never production. git is your seatbelt: git diff shows exactly what changed, git checkout . throws it away. A snapshot or a disposable VM is your roll-back. Commit and snapshot known-good states often. An agent loose in an un-versioned folder on a live host is a chainsaw with no guard and no off switch.

C.3 — The Human-in-the-Loop Rules (the heart of it)

This is the part you cannot skip and cannot fake. The agent executes tasks. You are the administrator of record. These responsibilities are yours, never delegated:

• The architecture and the blast radius — what touches what, what is fenced off, what an action can and cannot reach.
• The risk judgment — is this change reversible? what breaks if it is wrong? who is paged at 3 a.m. if it is?
• The tool and approach — Ansible vs Terraform, declarative vs imperative, rolling vs in-place, the maintenance window. This is the course skill.
• Every judgment of correctness, security, and safety — is this right? is it safe? does it hold under load and under failure?

Two practices wrap all of it:

• You read everything the agent writes and every command it ran. If you would not sign your name under a line, it does not ship and it does not run. “The agent did it” is not a defense for an outage or a breach in your environment — your name is on the change ticket.
• You verify; you do not trust. Re-run the check yourself. Confirm the service is actually healthy. Look at the database yourself. “All green” from the agent is a claim to be checked, not a fact. A confident, fast, sometimes-wrong partner taking real action on production is exactly as dangerous as it is useful.

The two-column rule

Two pieces of 2026 practice make these rules enforceable rather than aspirational, and you should know them by name:

• Governed autonomy, not blanket approval. The industry is moving from “a human approves every action” to governed autonomy: the agent may act freely on low-risk, reversible, read-mostly tasks inside policy guardrails, but high-risk actions hit an approval gate — a human confirmation, an allowlist, a time-boxed grant — and every action lands in an audit log. (“Governed autonomy” is an emerging framing as of 2026, not yet a settled term; use the idea, not the buzzword.)
• The Rule of Two (Meta’s framing) and the lethal trifecta. An unsupervised agent should satisfy at most two of: (a) exposure to untrustworthy input, (b) access to sensitive data or systems, and (c) the ability to change state or reach the outside world. All three at once is the “lethal trifecta” — the classic prompt-injection-to-exfiltration path. When a task needs all three, that is precisely when you keep a human in the loop and split the privileges.

Coach’s Note — Never paste a real secret into an agent’s context, and never point an agent at production data or live infrastructure unsupervised. Give it a dev environment with fake data and scoped, revocable credentials. A leaked key or a dropped production table is not a learning experience you recover from gracefully. Treat secrets and prod access the way you treat a live round at the range: assume it is hot, point it nowhere you’d regret.

C.4 — The Required agent-log.txt

Every Phase 2 project requires an agent-log.txt in its repo. It is graded. It is how your instructor sees the skill actually being assessed: your direction of the agent and your judgment over it. A project with clean automation and no honest log scores lower than a humbler one with a clear log — because the log is the evidence that you were the administrator and the agent was the junior.

The log records, for each task you delegated: what you asked, what the agent did, where it was wrong or risky, where you intervened, and what you decided and verified yourself. The “where it was wrong” and “what I decided” lines matter most — they are the proof of supervision. A log that reads “asked the agent, it worked, done” for everything is a confession that you weren’t watching. It also doubles as the audit trail that governed autonomy demands; treat it as the artifact a real change-review board would read after an incident.

Template (copy this into your repo)

# Agent Log — Project N: <name>

## Decisions I made myself (before any agent ran)
- Tool / approach: <e.g. Ansible over a shell script, because idempotency / drift>
- Blast radius & guardrails: <what I fenced off, what env it ran against, what it could NOT touch>
- Rollback plan: <snapshot / git / change window — how I'd undo it>
- Approval gates I set: <which actions required my explicit confirmation>

## Delegation log

### Task 1 — <short title>
- **I asked:** <the instruction I gave the agent>
- **The agent did:** <files it created/edited, commands it ran>
- **Where it was wrong / risky:** <bug, bad assumption, unsafe command, hallucinated
  flag or API — or "nothing, but I checked X, Y, Z myself">
- **Where I intervened:** <what I corrected, rejected at the gate, or rewrote myself>
- **I verified by:** <the check I ran / health I confirmed / state I inspected>

### Task 2 — <short title>
- **I asked:**
- **The agent did:**
- **Where it was wrong / risky:**
- **Where I intervened:**
- **I verified by:**

<...one block per delegated task...>

## What I would not let the agent decide or execute, and why
- <the calls I reserved — the architecture, the prod execution, the risk trade,
  a security decision — and the reasoning behind each>

Fill it as you go, not the night before the deadline. A log reconstructed from memory reads exactly like what it is.

C.5 — MCP and Tool Use, in One Paragraph

How does an agent actually do things? Through tool use — the model is given a set of callable tools (run a command, read a file, query an API) and decides which to call, with what arguments, then reads the result and continues. The emerging standard for connecting an agent to those tools is the Model Context Protocol (MCP) — think of it as a universal adapter between an agent and the tools, data sources, and systems it can reach (MCP is agent-to-tool; its sibling A2A is agent-to-agent — complementary, not competitors). A reassuring detail you should insist on: the MCP spec requires user consent before any tool is invoked, and it treats a tool’s own description, coming from a possibly untrusted server, as untrusted input. That consent prompt is your approval gate made concrete — do not click through it reflexively, and never connect an agent to an MCP server you don’t trust, because a malicious tool description is a direct injection vector. (MCP and A2A are governed under the Linux Foundation’s Agentic AI Foundation as of late 2025; the spec versions monthly, so treat any “latest version” claim as point-in-time.)

C.6 — Classroom & Academic-Integrity Policy

Read this slowly. It governs how the course is graded and where the line is.

The course runs in two phases, on purpose.

• Phase 1 (Weeks 1–8) — you build it by hand. AI is studied and used — you will read what it suggests, and you will learn where it hallucinates — but every lab requires you to do the traditional administration yourself: the commands, the configs, the reasoning. You are building the judgment the agent will later need you to have. You cannot govern a workload you have never run by hand.
• Phase 2 (Weeks 9–16) — you direct an agent. AI becomes part of the work and increasingly agentic. Directing the agent is the skill being graded. Using one here is not cheating; it is the assignment. We want you fluent at delegating well-specified ops work to a fast partner and keeping the dangerous decisions in your own hands — that is the administrator’s job in 2026 and after. Every Phase 2 project requires the honest agent-log.txt of C.4.

The failure is passing off the agent’s judgment as your own. If the agent chose the rollout strategy and you cannot explain why that strategy, under what risk, you have not done the work — you have watched it being done. If your agent-log.txt claims a decision you actually let the agent make, that is an integrity violation, exactly as claiming another person’s reasoning as yours has always been.

Two live checkpoints are deliberately structured so the agent cannot carry you:

• The midterm (Week 8) is closed-AI — 60 minutes, live, closed-internet, open-textbook. It proves you own the fundamentals in your own head and hands, before you are ever allowed to delegate them.
• The final (Week 16) is open-AI and agentic — a take-home capstone build plus a live session where you make and defend architecture, governance, and tool-choice decisions in real time, and reason about a constraint you have not seen before. An agent helped build your capstone during the term; the final checks that you were the architect over it. It is graded most of all on the governance and architecture documents you wrote first.

If you direct the agent well, read everything, verify, and keep every real decision in your own hands, the live sessions are easy — you actually know your system. If you let the agent think for you all term, that is exactly where it shows. By design.

Coach’s Note — The most dangerous sentence in Phase 2 is “the agent handled it.” About boilerplate, fine. Said about a production change or an architecture call, it is the sound of the skill slipping through your fingers and the accountability landing nowhere. Stay the administrator. The agent is the fastest junior you will ever lead — and a junior who is never, on a live system, in charge.

Up next: Back to Chapter 9 to start Phase 2 — now that your agent is set up and you know the rules. Make sure your lab toolchain (Appendix A) and AI toolkit (Appendix B) are ready first.