Agentic AI Foundations
From zero to understanding your first AI agent — the mental model, the vocabulary, and the moving parts. Python is the most important place to start, so this page opens with the complete Python curriculum, then covers the "what and why" that makes the hands-on chapters click. Every concept is tied to the course capstone: an AI DevOps Engineer you'll assemble in Part V.
By the end of this page you'll understand
- The difference between a chatbot and an agent — and why it matters.
- The seven building blocks every agent is made of.
- How an agent works step by step (the loop).
- Why "LLMs are the brain, agents are the doers."
- The common agent workflow patterns — and which ones the DevOps agent uses.
0 · Start here — learn Python first 🐍 intermediate
Python is the most important thing to start with. Every lab, every project, and the entire capstone in this course are written in Python — so before the concepts click into working code, get comfortable with the language. The course ships a complete, self-contained Python curriculum: 20 hands-on lessons from absolute basics all the way to expert AI-engineering, each linked to where the course actually uses it.
Basics, data & structures, functions/OOP, advanced, expert, real-world engineering. Start at P1 →
Complexity, stacks/queues/lists, hashing, trees/heaps, graphs, sorting/searching — from scratch. Start at D1 →
Async, numerics/tensors, tokenization, validation, vector DBs, MLOps. Start at A1 →
The full curriculum — and every individual lesson — is always in the left menu at the top, above the course chapters. Come back to it whenever you hit Python you want to understand more deeply.
1 · What is Agentic AI? intermediate
🤖 Chatbot
Answers questions. You ask, it replies. One turn, no action in the world. It knows things and talks — that's it.
"How do I debug a crash-looping pod?" → a paragraph of advice.
🦾 Agent
Plans, uses tools, takes action, completes tasks. You give it a goal; it figures out the steps, uses tools to do them, checks its work, and delivers a result.
"This pod is crashing" → it gathers logs, diagnoses, and opens a fix PR.
Agentic AI is AI that can take action toward a goal. It can plan, use tools, remember context, and complete multi-step tasks — not just chat about them.
2 · Why Agentic AI matters intermediate
Handles repetitive, multi-step work end-to-end without a human driving each step.
Breaks a fuzzy goal into concrete steps and sequences them itself.
Chooses what to do next based on what it observes — not a fixed script.
It's the direction the whole field is heading: from "AI that tells you how" to "AI that does it, with you supervising."
3 · The building blocks of an agent advanced
Every agent — including yours — is assembled from these seven pieces. You'll build each one by hand later; here's what they are.
What the agent is trying to achieve. → "produce a broadcast-ready cut."
Deciding the steps to get there.
Calling external tools — search, APIs, code, media processors.
Remembering context across steps and sessions.
Choosing what to do next based on results.
Actually executing a step in the world.
A human checks or approves before risky/irreversible steps.
| Block | Built in |
|---|---|
| Tool usage, Action | Chapter 4 (agent + tools) |
| Memory | Chapter 4 (stateful agent) |
| Planning, Decision-making | Chapter 4 (the loop) |
| Human-in-the-loop | Chapter 4 & 6 (approval gates) |
| Goals | Chapter 2 (system prompt) & every chapter |
4 · How an agent works (step by step) advanced
This is the single most important picture in the chapter: it shows the agent loop — the repeating cycle an AI agent runs to get a job done. Read the five numbered circles left to right, then follow the coloured arrow that curves back to the start.
- Circle 1 — "Get task" (the filled purple one) is where a job arrives, e.g. "an alert just fired." That's the agent's goal for this run.
- Circles 2→5 are the thinking-and-doing steps, and the straight blue arrows between them mean "then": 2 Break into steps (make a plan) → 3 Choose tool (which command fits?) → 4 Do it (actually run the tool) → 5 Check result (did that work? is the evidence solid?).
- Circle 6 (the small green circle, lower right) is the decision point after checking: is the task finished, or not yet? The green arrow labelled
improve & loopleads into it. - The dashed teal arrow sweeping from 6 back up to circle 2 is the loop: if the task isn't done, the agent takes what it learned and plans again, repeating the cycle. That "check, then improve and repeat" arrow is exactly what makes an agent smarter than a one-shot script.
In short: An agent = plan → pick a tool → act → check → repeat until done. A plain program runs its steps once in a fixed order; an agent keeps looping and adjusting based on what it sees, so it can handle messy, real-world tasks.
Task → break into steps → choose the right tool → do the step → check the result → improve and repeat until done. That "check & improve" loop is what makes an agent more than a script.
kubectl? aws?) → 4 run it → 5 check (root cause found? evidence solid?) → 6 propose the fix as a PR. Identical shape.5 · LLMs vs AI Agents advanced
🧠 LLM — the brain
Understands language and generates text. It can suggest what to do, reason about a problem, and decide — but it can't act on the world by itself.
🦾 Agent — the doer
An LLM plus tools, memory, and a loop. It takes the brain's decisions and actually executes them, step after step, until the task is complete.
kubectl, terraform, git) do it. The agent is the wiring between them.6 · Common agent workflows expert
Agents are assembled in a few recurring shapes. You'll recognize these when you build Chapter 4.
This diagram is a quadrant — four small mini-diagrams, one per corner — each showing a common shape that agents are wired into. In every mini-diagram a box is a step and an arrow means "flows to." The coloured word above each corner names the pattern.
- Top-left — Chaining: three boxes in a straight row with arrows (step → step → step). The steps always run in the same fixed order, like an assembly line.
- Top-right — Routing: one box splits into two, so the arrows fan out. The agent first classifies the input, then picks one branch to follow — like a switch that sends easy vs. hard questions down different paths.
- Bottom-left — ReAct loop: a
reasonbox and anactbox with an arrow that curves back on itself (labelledobserve → loop). The agent reasons, acts, looks at the result, then reasons again — this is the same loop as the first diagram, and it's what Chapter 4 builds. - Bottom-right — Orchestrator: a
planbox with arrows fanning out to three boxes. One "manager" step splits the work into subtasks, runs them, and gathers the results back together.
In short: These are just four ways to connect the boxes: chaining = fixed line, routing = pick a branch, ReAct = loop, orchestrator = fan out and gather. Real agents mix and match them — you don't have to memorise them now, just recognise the shapes when you meet them in Chapter 4.
| Pattern | What it does | The DevOps agent |
|---|---|---|
| Planner | Breaks the goal into a task list first, then executes. | Plans the full provisioning before writing Terraform |
| Executor | Carries out each planned step with tools. | Runs get-logs → describe → check-recent-deploys |
| Reflection loop | Reviews its own result and redoes weak parts. | "Does this terraform plan destroy anything? Reconsider." |
| ReAct | Alternates reasoning and acting, step by step. | Inspect → hypothesize → gather more evidence → conclude |
| Multi-step | Chains many sub-tasks into one bigger job. | Diagnose → fix → open PR → verify, end-to-end |
7 · The capstone through this lens expert
The course's destination (Chapter 8) is an AI DevOps Engineer — an agent that onboards into any company's stack and diagnoses, proposes, and (carefully) executes infrastructure work. Here's the honest architecture, using every concept above.
kubectl, terraform, aws, git. It's a textbook agent where the tools happen to be infrastructure CLIs — which is why it fits this course so cleanly.| Layer | Role | Tech | Course link |
|---|---|---|---|
| Trigger | Fire on an alert / Slack command / PR | webhook → handler | your AWS repo |
| Knowledge | Know this company's runbooks & conventions | RAG | Ch 3 |
| Brain | Diagnose & decide → a structured plan | Claude (structured JSON) | Ch 2 + Ch 4 |
| Hands | Inspect & act (read-only free; writes gated) | kubectl, terraform, aws, git | Ch 4 tools |
| Review | Human approves any state change | policy / approval gate | Ch 4 + Ch 6 |
| Trust | Prove decisions are correct & safe | evals | Ch 5 |
- Read-only first, gated writes later. The agent starts by diagnosing — it can't change anything. It earns the right to act one operation at a time, on evidence. Prod stays human-approved indefinitely.
- Copilot, not lights-out. The win is turning an hour of toil into a 60-second PR review — not an unattended agent running
terraform applyon prod. Full autonomy comes only where evals prove an operation safe.
What's next expert
You now have the mental model. Two ways forward:
- See the Learning Roadmap — the step-by-step path and the common mistakes to avoid.
- Or jump into building: Chapter 1 makes your first API call.
get_weather, picture kubectl_get or terraform_plan. Every lab ends with a "🏗️ Toward the capstone" note showing exactly how it plugs into the AI DevOps Engineer.🪜 Practice ladder beginner → industry
Six graded exercises, easy to real-world. Try each before opening its solution.
Context: The first fork in agentic AI is deciding whether a job even needs an agent. A chatbot answers in one turn; an agent plans, uses tools, and acts toward a goal — and confusing the two leads to over- or under-engineering.
Your task: Classify each request as a chatbot job or an agent job and justify each in one line: (a) “explain how to fix a crash-looping pod,” (b) “this pod is crashing — gather logs, diagnose, and open a fix PR.”
Requirements:
- Label (a) as chatbot: one turn, answers a question, takes no action in the world
- Label (b) as agent: given a goal, it plans, uses tools, acts, and delivers a result
- Justify each in a single sentence tied to the lesson's definition
- Name the distinguishing test: does it act toward a goal or merely describe how?
💡 Hint: Ask of each: after the reply, has anything changed in the world? Only the agent gathers logs and opens a PR.
Show solution
(a) Chatbot. It answers a question in one turn and takes no action in the world — you ask, it replies with a paragraph of advice.
(b) Agent. You give it a goal and it plans steps, uses tools (gather logs), takes action (diagnose), and delivers a result (opens a PR). It acts toward a goal, not just chats about it.
The lesson's one-liner: a chatbot could describe how to fix a broken deployment; the agent actually does it. That difference — plan, use tools, take action, complete multi-step tasks — is what makes (b) an agent problem.
Context: Every agent, including the course capstone, is assembled from the same seven pieces. Being able to name them and point at a concrete instance of each is the vocabulary the rest of the course assumes.
Your task: List the seven building blocks of an agent from the lesson, then give one concrete capstone example each for the Tool usage and Human-in-the-loop blocks.
Requirements:
- Enumerate all seven: Goals, Planning, Tool usage, Memory, Decision-making, Action, Human-in-the-loop
- One-line description of what each block is
- Tool usage example is a real infra CLI call (e.g.
kubectl getorterraform plan) - Human-in-the-loop example gates a state change (a human approves before
terraform apply) - Reflect the lesson's rule: read-only diagnosis is free, writes are gated
💡 Hint: The blocks map onto the loop: goal in, plan, pick a tool, act, remember, decide, and a human checkpoint before anything irreversible.
Show solution
The seven building blocks:
1. Goals - what it's trying to achieve
2. Planning - deciding the steps to get there
3. Tool usage - calling external tools (APIs, code, CLIs)
4. Memory - remembering context across steps/sessions
5. Decision-making - choosing what to do next from results
6. Action - actually executing a step in the world
7. Human-in-the-loop - a human approves risky/irreversible stepsTool usage (capstone): the agent calls real infrastructure CLIs — e.g. kubectl get to pull pod logs/events or terraform plan to preview a change. Human-in-the-loop (capstone): before any state change (a terraform apply on prod), a human reviews and approves the proposed fix PR — read-only diagnosis is free, writes are gated.
Context: The agent loop — get task, plan, choose tool, act, check, repeat — is the single most important picture in the chapter. Turning it into runnable code makes concrete what separates an agent from a one-shot script.
Your task: Write a small pure-Python skeleton that expresses the lesson's loop using stub functions — plan, choose_tool, act, and check — driven by an agent(task) that runs.
Requirements:
- Model all six steps: receive task, plan, choose tool, act, check, loop on the decision
- Use a
whileloop that re-plans whenchecksays not done - Carry state across iterations in a
memorylist (the observe step) - Stubs may be trivial, but the program must run and terminate
- Make clear how this differs from a fixed script that runs its steps once
💡 Hint: The distinguishing feature is the while + check: an agent re-plans based on what it observed, rather than executing a fixed sequence once.
Show solution
def plan(task, memory): # step 2: break into steps
return ["gather_logs", "diagnose"] # stub plan
def choose_tool(step): # step 3
return {"gather_logs": "kubectl", "diagnose": "llm"}[step]
def act(tool, step): # step 4: do it
return f"ran {tool} for {step}"
def check(results): # step 5: is evidence solid / task done?
return len(results) >= 2 # stub: done once we've acted twice
def agent(task):
memory = [] # step 1: get task -> goal for this run
while True:
for step in plan(task, memory):
tool = choose_tool(step)
memory.append(act(tool, step)) # observe -> memory
if check(memory): # step 6: done?
return memory
# else: improve & loop -- plan again with what we learned
print(agent("fix crash-looping pod"))This mirrors the diagram exactly: circle 1 is receiving the task, 2–5 are plan → choose tool → act → check, and circle 6 is the decision point whose dashed arrow loops back to plan when the task isn't done. The distinguishing feature versus a plain script is the while loop with check: an agent re-plans based on what it observes, rather than running a fixed sequence once. memory is what carries context across iterations.
Context: Agents are wired into a few recurring shapes — chaining, routing, the ReAct loop, and the orchestrator. Recognising which shape fits a task is what lets you pick an architecture instead of reaching for the loop every time.
Your task: For each of the four workflow shapes, describe its structure in one line and give a task where it is the right fit.
Requirements:
- Cover all four: chaining, routing, ReAct loop, orchestrator
- Chaining = fixed steps in order; routing = classify then pick a branch
- ReAct loop = reason → act → observe, curving back until done
- Orchestrator = a planner fans work to subtasks, then gathers results
- Each fit example should genuinely suit that shape (e.g. incident diagnosis for ReAct)
💡 Hint: The key contrast: chaining runs a fixed line once, while the ReAct loop's “check then improve” wins when the steps aren't known in advance.
Show solution
| Shape | Structure | Good fit |
|---|---|---|
| Chaining | Fixed steps in order (step → step → step), like an assembly line. | A known, stable transform: extract → summarize → format a report. |
| Routing | Classify the input, then pick one branch. | Support triage: send easy FAQs one way, complex tickets another. |
| ReAct loop | Reason → act → observe, curving back on itself until done. | Incident diagnosis where steps aren't known in advance and depend on what you find. |
| Orchestrator | A planner fans work out to subtasks, then gathers results. | Research across many sources in parallel, then synthesize. |
The key contrast the lesson draws: chaining runs a fixed line once; the ReAct loop's "check then improve and repeat" wins on messy, real-world tasks whose steps aren't known up front, because it gathers more evidence and adjusts. Real agents mix and match these shapes.
Context: Real agent deployments are judged on their architecture, not their demo. The AI DevOps Engineer's six layers — trigger, knowledge, brain, hands, review, trust — are the honest blueprint the whole course builds toward.
Your task: Lay out the six-layer architecture of the AI DevOps Engineer, naming the role and tech for each layer, then state which layer is the “brain” and why the LLM is not the tool.
Requirements:
- Name all six layers with their role and tech (webhook, RAG, Claude, CLIs, approval gate, evals)
- Identify the brain as the LLM/agent that diagnoses and decides a structured plan
- Explain that the brain orchestrates tools but doesn't do the work itself
- Name the real tools that do the work:
kubectl,terraform,aws,git - Tie it to the lesson's one-liner: LLMs are the brain; agents are the doers
💡 Hint: The agent is the wiring between a decision and the CLIs that execute it — a textbook agent where the tools happen to be infrastructure CLIs.
Show solution
| Layer | Role | Tech |
|---|---|---|
| Trigger | Fire on an alert / Slack command / PR | webhook → handler |
| Knowledge | Know this company's runbooks & conventions | RAG |
| Brain | Diagnose & decide → a structured plan | Claude (structured JSON) |
| Hands | Inspect & act (read-only free; writes gated) | kubectl, terraform, aws, git |
| Review | Human approves any state change | policy / approval gate |
| Trust | Prove decisions are correct & safe | evals |
The brain layer is the LLM/agent — it reasons about the problem and orchestrates the real tools, but it doesn't do the work itself. The actual changes are made by kubectl, terraform, aws, git. That is the crucial truth from the lesson: "LLMs are the brain; agents are the doers" — the agent is the wiring between a decision and the CLIs that execute it, which is why it's a textbook agent where the tools happen to be infra CLIs.
Context: The moment an agent can touch production, the argument shifts from capability to safety. An exec pushing for unattended writes on prod is the pressure every real agent team faces — and the lesson's two scoping rules are the defensible answer.
Your task: An exec wants the DevOps agent running terraform apply on prod unattended “to save time.” Using the lesson's two scoping rules, write a short rebuttal and the safe path to more autonomy.
Requirements:
- Invoke rule 1 — read-only first, gated writes later; prod stays human-approved
- Invoke rule 2 — copilot, not lights-out; the win is a 60-second PR review, not autonomy
- Explain why unattended
terraform applyon day one makes one bad plan catastrophic - Give a staged path: diagnose → open a PR → build evals → auto-approve narrow, proven ops
- State the principle: autonomy is granted by measurement (evals), not by exec urgency
💡 Hint: Anchor the rebuttal in the Review and Trust layers — full autonomy comes only where evals prove a specific operation safe, lower environments first.
Show solution
Rebuttal, grounded in the lesson's two honest scoping rules:
- Read-only first, gated writes later. The agent starts by diagnosing — it can't change anything. It earns the right to act one operation at a time, on evidence. Prod stays human-approved indefinitely. Handing it unattended
terraform applyon prod on day one inverts this and makes a single bad plan catastrophic and irreversible. - Copilot, not lights-out. The real win is turning an hour of toil into a 60-second PR review — not an unattended agent mutating prod. Full autonomy comes only where evals prove a specific operation safe.
Safe path to more autonomy: (1) ship read-only diagnosis that opens a reviewable fix PR; (2) build the eval suite (the "Trust" layer) so you can measure correctness and safety per operation; (3) auto-approve only the narrow operations whose evals prove safe, in lower environments first; (4) keep prod state changes human-gated behind the approval policy. Autonomy is granted by measurement, not by exec urgency — the same discipline the capstone's Review and Trust layers exist to enforce.
Knowledge check check yourself
The lesson's one-liner is 'LLMs are the brain; agents are the doers.' What does an agent add to an LLM, and why does that distinction matter for the DevOps capstone?
Show answer
Contrast the ReAct-loop pattern with a plain chaining workflow. When does the loop's 'check then improve and repeat' give an agent an edge over a fixed sequence of steps?