Agentic AI Foundations

0 · Start here — learn Python first 🐍 intermediate

Here's a trap I've watched sink a lot of motivated people. They arrive excited about agents, skim the concept pages, and dive straight into Chapter 4 to "build an agent." Two hours later they're stuck — not on anything about agents, but on a dictionary that won't unpack, a for loop that indents wrong, an import that fails. The AI part was never the blocker; the Python underneath it was. They bounced off the language, not the idea. This section exists so that never happens to you.

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.

Think of Python here the way a chef thinks of knife skills. Nobody signs up for cooking school because they're passionate about chopping onions — they want to make the beautiful dish. But every dish runs through the knife, so the chef who skipped knife practice is slow, frustrated, and cutting themselves all night. Python is your knife. Agents, RAG, tool-calling, evals — the "beautiful dishes" of this course — are all expressed in Python, so an hour spent getting fluent now pays itself back tenfold when the interesting chapters stop fighting you and start flowing.

And to name the fear directly, because it stops people: you do not need to be a "real programmer" to do this. Agentic AI code is mostly plain, readable Python — functions that call an API, dictionaries that hold a message, loops that repeat until done. If you can read the labs in this course and follow what each line does, you're ready; you don't need years of software engineering behind you. The curriculum below is deliberately laddered so an absolute beginner can start at P1 and climb, while someone already fluent can skim and skip ahead. Either way, treat Python as the ground you stand on, not a detour — the concepts on the rest of this page will feel abstract until you've seen them land in code you can run.

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

Start with a moment you've probably had. You paste a stack trace into a chatbot and it writes you a beautiful three-paragraph explanation of what's wrong and exactly which commands to run. Helpful — but then you open the terminal, you run the commands, you read the output, you come back and paste the next thing. The AI knew the answer the whole time; you were its hands and feet. An agent is what you get when the AI grows its own hands and feet — when it can run those commands, read that output, and decide the next step, all without you shuttling text back and forth.

Here's the everyday analogy that makes the line crisp. A chatbot is a brilliant consultant on the phone: ask anything, get expert advice, but they never leave their desk — nothing in your world actually changes until you go do it. An agent is a contractor you hand a key: you describe the outcome you want ("get the leaking pipe fixed"), and they show up, inspect, decide what tools to grab, do the work, check it held, and only call you when they need a sign-off. The consultant tells; the contractor does. That single difference — action toward a goal — is the whole subject of this course.

The common mistake beginners make is assuming "agent" just means "a smarter chatbot" or "a chatbot with a longer memory." It doesn't. A chatbot could have a genius-level IQ and a perfect memory and still be a chatbot, because it never touches the world — it only ever produces text for you to act on. What flips it into an agent isn't raw intelligence, it's agency: the wiring that lets it call tools, observe real results, and loop until the job is done. Keep that test in your pocket as you read on: after the AI finishes, has anything actually changed out in the world? If the answer is "no, it just told me things," you have a chatbot; if the answer is "yes, it gathered evidence and opened a fix," you have an agent. The two side-by-side cards below make the contrast concrete before we pin down the definition.

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

Picture the last time a real task ate your afternoon. Not one hard question — a chain of small ones. An alert fires; you pull logs; the logs point at a bad deploy; you check what changed; you cross-reference the runbook; you draft a fix; you get someone to review it. Any single step, a chatbot could have helped with in seconds. But you were the one carrying the thread across all of them — holding the context, deciding the next move, gluing the pieces together. That gluing-together is exactly the work agentic AI is built to take off your plate.

Here's why that's a bigger deal than "a faster chatbot." A one-turn assistant helps with steps; an agent owns outcomes. The analogy is the jump from a calculator to a spreadsheet: a calculator answers one sum at a time and you copy each result forward by hand, while a spreadsheet holds the whole model, re-runs when something changes, and hands you the finished answer. Agents do that for multi-step work — they keep the context, sequence the steps themselves, and adapt when a step surprises them. The value isn't that they're smarter per step; it's that you stop being the human clipboard shuttling state between steps.

The mistake to avoid is reaching for an agent for everything, because "agentic" is the exciting word. If a job is genuinely one-shot — "summarize this paragraph," "classify this ticket" — an agent is overkill: more moving parts, more cost, more ways to fail, for a task a single call already nails. Agents earn their complexity precisely when the task is multi-step, uncertain, and stateful — when you don't know step 3 until you've seen the result of step 2. The three capabilities below — automation, planning, decision-making — are the levers that make that possible, and they're worth reading as "what an agent can do that a lone LLM call cannot."

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

The word "agent" can feel like a black box — magic in, results out — and that vagueness is what makes it intimidating. So let's break the box open. An agent isn't one mysterious thing; it's a small kit of ordinary parts wired together, and once you can name the parts, the magic turns into engineering you can actually build. That's the whole aim of this section: replace "an agent, somehow" with "these seven pieces, connected like so."

Think of it like the parts of a car. A car isn't a single indivisible marvel — it's an engine, a steering wheel, wheels, a fuel tank, a dashboard, brakes, and a driver, each with one clear job, combining into something that gets you places. An agent is the same: a goal (where you're going), planning (the route), tools (the engine that does work), memory (the trip so far), decision-making (the steering), action (actually moving), and a human-in-the-loop (the driver who can grab the wheel). Learn the parts once and every agent you ever meet — simple or frontier — decomposes into the same kit.

The mistake here is skipping straight to "tools" and ignoring the rest, because tool-calling is the flashy part everyone demos. But an agent that can call tools with no memory forgets what it just learned; one with no human-in-the-loop happily runs a destructive command; one with no real decision-making is just a fixed script wearing a costume. The seven blocks matter together — the reliability and safety of a real agent live in the unglamorous ones (memory, decision-making, the human checkpoint) as much as in the exciting one. Read the cards below as a checklist you'll return to: every agent you build in this course, up to the capstone, is these same seven pieces, and you'll construct each by hand later. Right now, just get comfortable naming them and what each is.

4 · How an agent works (step by step) advanced

If you take one thing from this entire page, take this loop. Everything else — the seven blocks, the workflow shapes, the capstone architecture — is detail hanging off this single skeleton. An agent gets a task, makes a plan, picks a tool, does something, checks whether it worked, and then — the crucial part — decides whether to go around again. Miss the loop and you've missed what an agent is; get the loop and the rest is just filling it in.

The homely analogy is how you actually fix things in real life. Say your car won't start. You don't run a fixed script; you loop: guess it's the battery (plan) → grab the jump leads (choose tool) → try a jump (act) → still dead? (check) → new guess, maybe it's the starter (plan again) → and round you go until it turns over. Each attempt teaches you something that reshapes the next attempt. That "try, look at what happened, adjust, try again" rhythm is precisely the agent loop — and it's why an agent can handle a messy problem whose steps nobody could write down in advance.

The mistake to watch for is picturing an agent as a straight pipeline — task in one end, answer out the other, done. That's a workflow, not an agent, and it breaks the instant reality doesn't match the plan: the very first tool call returns something unexpected and a straight pipeline just barrels on with garbage. The loop is what buys robustness — the "check the result" step catches the surprise, and the "improve and repeat" arrow feeds it back into a fresh plan. Read the diagram below with your eye on that curved arrow returning to the start: the five steps in a row are the easy part, but the arc looping back is the whole point.

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.

5 · LLMs vs AI Agents advanced

People blur these two words constantly, and the blur causes real confusion — so let's separate them for good. "LLM" and "agent" get used almost interchangeably in casual talk, but they're different layers of the same system, and mixing them up is why beginners can't tell why their "agent" didn't do anything. An LLM is a component; an agent is the machine built around that component. One thinks; the other acts.

The cleanest analogy is a brain in a jar versus a whole person. A large language model is an astonishing brain: it understands language, reasons, weighs options, and produces the right decision — but sitting in its jar it can't pull a lever, read a dial, or open a door. It can only say what should be done. An agent is that brain given a body: eyes to observe (read tool output), hands to act (call tools), a notebook to remember (memory), and the nervous system that keeps the cycle going (the loop). The intelligence lives in the brain; the doing lives in the body wrapped around it.

Here's the mistake this framing kills: expecting an LLM, by itself, to change something in the world — and being baffled when it just describes the change instead. That's not a failure, it's the LLM doing exactly its job: it decides, it never executes. If you want a file written, a command run, a PR opened, you (or the agent scaffolding you build) must hand the model tools and wire up the loop that carries its decisions into action. Getting this distinction bone-deep is what the rest of the course rests on: the LLM is the smartest part but the least capable on its own, and the engineering — the part you're here to learn — is everything that turns a decision into a done thing. The two cards below name the split; the one-liner that follows is worth memorising.

6 · Common agent workflows expert

Once you've built a couple of agents, a quiet realization arrives: you keep drawing the same handful of diagrams. The task changes — support triage, incident diagnosis, research synthesis — but the wiring falls into a few recurring shapes you've seen before. That's not a coincidence; it's the good news. You don't invent a new architecture per problem. You recognise which of a small set of proven shapes fits, and reach for it. This section names those shapes so you stop reinventing them.

Think of them like sentence structures in a language. English has only a few basic patterns — statement, question, command, conditional — yet they compose into infinite sentences. Agent workflows are the same small grammar: chaining (a fixed line of steps), routing (classify, then branch), the ReAct loop (reason → act → observe, repeat), and the orchestrator (fan work out, gather it back). Every elaborate agent you'll ever read about is these primitives, combined and nested. Learn the grammar once and you can parse — and design — any agent you meet.

The mistake nearly everyone makes first is defaulting to the loop for everything, because the ReAct loop is the one that feels "agentic." But the loop is also the most expensive and least predictable shape — every iteration is another model call and another chance to wander. If a task's steps are actually known and fixed, plain chaining is cheaper, faster, and easier to debug; if it's a clean either/or, routing beats looping. The skill isn't always using the fanciest shape — it's matching the shape to the task, saving the loop for problems whose steps genuinely can't be known in advance. As you read the four shapes below, don't memorise them; just tune your eye to recognise them, because you'll meet all four again when you build Chapter 4.

7 · The capstone through this lens expert

Every concept on this page has been building toward one payoff, so let's cash it in. Abstract ideas — brain vs. doer, the loop, the seven blocks, the workflow shapes — only truly stick once you watch them assemble into something real. So here we take the whole vocabulary and point it at the concrete thing you'll build: the AI DevOps Engineer. If the earlier sections felt theoretical, this is where the theory grows a spine.

Here's the analogy that keeps the capstone honest, and it's the one misconception worth killing before you write a line of it. The agent is a surgeon, not a scalpel. A surgeon doesn't cut with their hands — they decide where to cut and wield precise instruments to do it, and a good operating theatre has checklists and a second pair of eyes before anything irreversible happens. Our agent is exactly that: the LLM is the surgeon's judgment (diagnose, decide, plan), the real tools — kubectl, terraform, aws, git — are the instruments that actually cut, and a human sign-off is the theatre checklist. The mistake that sinks people is imagining the AI itself "does" the infrastructure work by magic; it doesn't. It reasons and orchestrates; boring, battle-tested CLIs do the doing. That's not a limitation to apologise for — it's what makes the whole thing trustworthy enough to ship.

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.

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.

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 steps

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"))

Knowledge check check yourself