TL;DR: Agentic AI is the practice of putting a language model in a loop with tools so it can look things up, compute, act and check its own work over several steps. A course that teaches it well is organised around that loop and makes you build it: the loop itself on the raw API, tools with schemas the model can select from, budgets and error handling so a run cannot spin forever, memory and context control, the standard patterns and when each one wins, tool servers over the Model Context Protocol, multi-agent routing, guardrails against injection and unsafe actions, an evaluation harness with a regression gate, and traces that show what a run did and what it cost. A course that only tours a framework is a product demo. The guide below lists the ten units a good course covers, the five artefacts you should have by the end, and a six-week syllabus for doing it yourself.
An engineer takes a weekend course, wires a framework's agent class to a search tool and a calculator, and demos it on Monday. It answers three questions correctly and everyone is impressed. On Wednesday it loops thirty times on a question about an order that does not exist, on Thursday it issues a refund because a customer typed "refund me" into the chat, and on Friday nobody can say what it did on Wednesday because nothing was recorded. The demo was agentic AI. The Wednesday-to-Friday part is the course.
Search interest in agentic AI courses is high and much of what ranks is a list of framework features. This guide is about what the course should contain and what you should be able to show afterward.
Start here
The agents module of the AI Engineer course is built the way this guide describes: every unit ends in a sandbox lab with a checker, from the tool loop written by hand to an evaluation harness with a per-case regression gate. The curriculum is open to browse; the lessons, labs and projects are included with Pro. For where agents sit in the wider skill set, read the AI engineer roadmap.
Agentic AI in one loop
Send the conversation to the model with a list of tools attached. If the reply carries tool calls, run the matching functions, append one result message per call with its id, and send the conversation again. If the reply is text, that text is the answer. Everything else in the field sits on top of those lines: memory is what you put into the conversation, planning is how the model decides the next call, multi-agent systems are loops that call other loops, and guardrails are code that sits between the model's request and the function that would run it.
A course that starts anywhere else, with a framework's class hierarchy or a diagram of autonomous agents, is asking you to trust a loop you have never seen. Build it first. It takes about a hundred lines and an afternoon.
The ten units a good agentic AI course covers
Ten units, what each one teaches, and what you build in it
| Unit | What you learn | What you build |
|---|---|---|
| 1. The tool loop | The wire format of a tool call, ids, the messages that must be threaded back | A loop on the raw chat API, no framework |
| 2. Tool design | Schemas, descriptions that get a tool selected, results as JSON the model can read | A registry derived from the specs; errors returned as results |
| 3. Budgets and failure | Step, tool-call and token budgets; malformed arguments; gateway errors | A runaway cut at the budget; a recorded failure replayed offline |
| 4. Memory and context | What goes into the conversation, what gets truncated, what gets summarised | Result truncation with a marker; a trace per step |
| 5. Patterns | ReAct, direct tool calling, plan-and-execute; latency and reliability of each | The same agent three ways, benchmarked |
| 6. Multi-agent routing | Supervisors, specialists, handoffs and when one agent is enough | A supervisor routing between two specialists |
| 7. MCP and tool servers | Exposing tools over the Model Context Protocol; discovery; transport | An MCP server serving your own tools |
| 8. Guardrails | Prompt injection through tool results, side effects, approval flows | A policy hook with an audit log; input and topical rails |
| 9. Evaluation | Trajectory scoring, argument checks, judges, calibration, per-case gates | A golden set, a report, and a gate that blocks a bad prompt |
| 10. Observability | Spans per tool call, cost per run, sampling, a regression gate on latency and cost | Traces from a real run and a report over them |
The order matters. Units one to four are the loop and its safety rails, and they are the units most courses skip because frameworks provide them. Units five to seven are architecture, which only makes sense once the loop is understood. Units eight to ten are what turns an agent into something a team can run, and they are where the Wednesday-to-Friday problems get solved.
The hands-on test: five things you should have shipped
Read a course syllabus and ask whether it produces these. If it does not, it is a lecture series.
- A tool-using agent on the raw API, with budgets, errors returned as results, and a trace of every step. If you cannot write this in an afternoon after the course, the course taught you a framework rather than agents.
- An MCP server exposing your own tools, called by an agent that discovered them.
- A guarded agent that refuses a refund above a limit, records the denial, reports it honestly, and survives an injection planted in a tool result.
- An evaluation report over a golden set, with tool trajectories and arguments scored alongside the answer, and a gate that blocked a prompt change on a protected case.
- A traced production run with cost per request and a p95 latency per stage, sampled so that every failure is kept.
Each of these is a lab in the AI Engineer course's agents and evaluation modules, checked by code rather than by a quiz.
A six-week syllabus for doing it yourself
Week 1: the loop. Build the agent on the chat completions API with three plain tools. Add step, tool-call and token budgets. Replay a recorded runaway and watch it get cut. Lab: build an agent from scratch.
Week 2: tools, memory and patterns. Rewrite the tool descriptions and measure how selection changes. Truncate oversized results. Build the same agent as ReAct, direct tool calling and plan-and-execute, and benchmark them. Labs: agent patterns, agent memory.
Week 3: tool servers and routing. Expose the tools over MCP. Add a supervisor that routes between two specialist agents and decide, with numbers, whether it beats one agent with more tools. Labs: MCP tool servers, multi-agent orchestration.
Week 4: guardrails. Put a policy hook in front of every side-effecting tool, log every decision, and plant an injection in a tool result to see it caught. Add input and topical rails. Lab: safety and guardrails. The AI Red Teaming course covers the attacker's side of this week in depth.
Week 5: evaluation. Write a golden set with expected answers, tool paths and arguments. Build the graders, add a judge and calibrate it, produce a report per prompt version, and gate on per-case regressions. Lab: evaluate an AI agent; the agent evaluation guide is the reading.
Week 6: production. Trace every step, price every run, sample so failures are always kept, and add a latency and cost gate to CI. Lab: LLM observability, with the observability guide.
What to skip, and what to distrust
Skip any course whose first week is a framework tour and whose last week is "deploy to production" with no evaluation in between. Distrust demos that never show a failure: agents fail in specific, repeatable ways (runaways, invented arguments, actions taken from a sentence in a tool result), and a course that never shows one has not taught you to handle them. Be careful with no-code agent builders as the whole curriculum; they are fine for a first prototype and they hide exactly the parts that go wrong on Wednesday.
Frameworks themselves are not the problem. After the loop is understood, a framework's state machine, memory abstraction or MCP client is a reasonable thing to adopt. The order is the point: build the loop, then decide what to delegate.