
In this course, we’ll go from first principles to a working, testable AI agent system.
We’ll start by building a mental model for Agentic AI — what an “AI agent” actually is, how it differs from a normal LLM chatbot, and when you should (and should not) use an agent. We’ll compare three styles of building intelligent behavior: classic code-driven automation, pure LLM prompting, and agentic systems where the model can plan, act with tools, and reflect.
Then we’ll get hands-on with the OpenAI Agents SDK. You’ll learn the core building blocks: Agents, Runner, Tools (Python functions exposed to the model), Handoffs between agents, Hooks for side effects, Guardrails for safety and policy, and Context/Memory. We’ll also walk through the Agent Loop (Observe → Think/Plan → Act → Reflect), which gives the model a repeatable “sense–decide–do–reflect” workflow instead of just answering once.
From there, we’ll build a full multi-agent application: an airline customer support assistant. You’ll implement a triage agent, specialized agents for FAQs, seat changes, and cancellations/rescheduling, tool calls that actually update state, and handoff logic that passes control between agents. We’ll also add a simple front end (Gradio UI) so you can interact with it like a real support assistant.
Finally, we’ll make it production-minded. You’ll add lightweight evaluation (eval) to automatically test routing, tool usage, confirmation flow, and policy compliance. You’ll also see how to point the same agent code at either OpenAI models or an OpenAI-compatible local model, so you’re not locked in.
By the end, you’ll have not just code snippets, but an end-to-end mental model and a working reference implementation you can adapt to your own org, your own data, and your own workflows.
In this chapter, we’ll look at three different ways teams try to “add AI” to a product:
Code-driven automation – Classic engineering: you write logic, you control every branch, it’s deterministic. Great for well-defined flows, terrible when the user request is messy or the path changes in the middle.
LLM-driven assistants – You point a large language model at the problem and let it respond in natural language. Fast to prototype, but it struggles with guarantees, multi-step procedures, state, compliance, or doing real work through your systems.
Agentic systems – You give the model a job, tools, memory, and boundaries. The model plans, chooses actions, and can hand off to other agents or escalate to a human. You get flexibility like an assistant, but you also get structure, auditability, and control.
We’ll talk about when each approach is appropriate, and more importantly, when an “AI agent” is actually justified. You’ll learn the 5-question test for deciding if your use case really needs agentic behavior (planning, tool use, memory, handoff, autonomy) or if a simpler approach is safer and cheaper.
By the end of this chapter, you’ll have a mental decision tree:
– When do I keep it simple?
– When do I just use an LLM?
– When do I invest in a true agent?
That design instinct — choosing the right level of intelligence and control up front — is what prevents you from overbuilding a chatbot that can’t be trusted, or overspec’ing an agent for a problem that didn’t need one.
This chapter, “AI Agents for Agentic AI,” is where we define what an agent actually is — and when you actually need one.
We start by making “agent” concrete. An AI agent isn’t just a chatbot with a fancy prompt. It’s a system that can do four things in a loop:
Observe what’s going on,
Think/Plan the next step,
Act by calling tools and touching real systems, and
Reflect on whether the goal is done or if it needs to continue.
That loop is what makes the behavior agentic instead of just conversational. The agent is moving toward an outcome, not just answering a question.
We also unpack the traits of a real agent: it can take actions through tools (not just talk), it can carry context and memory across turns, it can follow policy and escalate, and it can even hand off to a different specialized agent or a human when it’s out of scope. In other words: it’s not just talking — it’s participating in the workflow.
Then we go one level deeper and tackle a critical question: Do you even need an agent here?
This is where we introduce the “agent or not?” decision test. We’ll walk through how to look at a use case and ask:
Is there a goal that requires multiple steps and judgment, not just a single answer?
Will it need to call tools or APIs to actually get something done?
Does it need to track state or memory across steps?
Is there a need to route or hand off (for example, to billing vs support vs ops)?
Do we want it to act with some autonomy — or is this just a one-shot prompt?
If the answer to most of those is “yes,” you’re in agentic territory. If not, you might be better off with a simpler assistant or even a traditional API workflow.
By the end of this chapter, you’ll be able to do two things:
Explain what makes something an AI agent in practical, implementation terms.
Look at a real problem and decide honestly: is this an agentic use case, or am I overengineering it?
That decision is the difference between building something reliable and shippable vs. building something overly clever that no one will put in production.
Lecture: Environment Setup & Your First AI Agent
In this lecture, we’ll get hands-on and actually build our first working AI agent using the OpenAI Agents SDK.
We’ll start by setting up the environment so everyone can run the same code:
Installing the required libraries
Configuring the OpenAI client (or your local model) and API key safely
Verifying that the SDK can talk to a model
Then we’ll create a minimal agent from scratch — just a name, basic instructions, and a model — and call it with Runner.run(...). You’ll see how little code it takes to get an LLM-powered agent to respond.
By the end of this lecture:
You’ll have a runnable notebook / environment
You’ll understand the two core building blocks (Agent and Runner)
You’ll be able to ask your own agent questions and get answers back
This sets the foundation for everything else in the course: tools, handoffs, memory, guardrails, evaluation, and full multi-agent systems.
Build AI agents that don’t just talk — they act.
Most teams stop at “ChatGPT inside a UI.” That’s not an agent.
This course teaches you how to design, build, and evaluate real AI agents using the OpenAI Agents SDK. You’ll learn how to give models tools, memory, policy boundaries, and the ability to route work — so they can solve real problems like customer support, operations, and workflow automation.
Instead of slideware, we build a full end-to-end system together: an airline customer support assistant that can route requests, answer policy questions, change seats, handle cancellations and reschedules, respect business rules, and escalate when needed. You’ll also learn how to test it, monitor it, and plug it into a simple UI.
What you’ll learn
The difference between traditional automation, LLM “assistants,” and true agentic systems — and when you should use which.
How to decide if your use case actually needs an agent (or if a single LLM call is enough).
How the Agent Loop works (Observe → Think/Plan → Act → Reflect) and how to force the model to operate step-by-step instead of hallucinating.
How to expose real tools (Python functions / APIs) to the model so it can look up data, take actions, and update systems — safely.
How to build multi-agent systems with triage and handoffs (for example: FAQ agent, seat booking agent, cancellation and rebooking agent).
How to attach guardrails for policy, confirmation, and safety.
How to persist context and memory across turns.
How to evaluate the agent’s behavior automatically — routing, tool usage, escalation, and confirmation gates — using a lightweight JSONL eval harness.
How to run your agent against both OpenAI models and OpenAI-compatible local models (e.g. self-hosted / vLLM / Qwen-style endpoints).
How to wrap it in a front end (Gradio) so stakeholders can try it like a real support assistant.
How the course flows
1. Mindset and architecture
We start by building a mental model of Agentic AI. You’ll learn what an AI agent actually is in practical terms: a system that can observe what’s happening, plan the next step, call tools to act, and reflect on whether it’s done — not just answer in plain text. We compare code-driven automation, pure “chatbot-style” LLMs, and agentic designs.
We also walk through a 5-question test you can use with any new idea to decide: “Is this really an agent use case, or am I overcomplicating it?”
2. Core building blocks of the OpenAI Agents SDK
You’ll get hands-on with the SDK primitives you’ll use every day:
Agent: the brain with instructions and role.
Runner: the execution engine that drives turns.
Tools: Python functions the model can call to get facts or take actions.
Handoffs: how one agent can delegate to a more specialized agent.
Hooks: how to inject state or perform setup logic right when a handoff happens.
Guardrails: how to block unsafe input or enforce policy around output.
Context & memory: how the agent carries knowledge through a conversation.
The Agent Loop (Observe → Think/Plan → Act → Reflect): how to orchestrate multi-step work.
You’ll see minimal “hello world” versions of each concept and then gradually stack them into something production-like.
3. Real project: Airline Customer Support Agent
Next, we build a working multi-agent support system. This includes:
A Triage Agent that decides what the user is asking and routes to the right specialist.
An FAQ Agent that answers policy questions from a controlled knowledge base.
A Seat Booking Agent that can take a confirmation number and change a seat — via a tool call, not just text.
A Cancellation & Rescheduling Agent that can fetch fare rules, present rebooking options, and apply cancellation policy safely (with explicit confirmation before doing anything irreversible).
You’ll learn how agents hand off to each other, how they populate context (like confirmation numbers or flight IDs), and how guardrails prevent them from doing unauthorized work.
4. Observability and UI demo
We build a tiny front end in Gradio so you (and your stakeholders) can chat with the system like a real airline support bot. You’ll also see how to log tool calls, handoffs, and decisions for debugging and auditability.
5. Evaluation and safety
Finally, you’ll learn how to test agents like software. We’ll build a small evaluation harness that:
feeds in realistic customer prompts,
checks whether the right agent took control,
verifies that the correct tools were called (and forbidden tools were not),
enforces that certain actions require confirmation.
We’ll generate a pass/fail scorecard so you can see if you broke routing, safety, or policy after making changes. This is the difference between “cool demo” and “something you could actually deploy.”
Who this course is for
AI/ML engineers and LLM developers who want to go beyond chat interfaces.
Backend / platform / ops engineers who want safe, automatable agents that touch real systems.
Product engineers / founders building internal copilots and support bots.
Technical leads who need to evaluate whether “agentic AI” is real or hype.
You should be comfortable with basic Python. You do not need to be a deep learning researcher.
Why this matters
Most companies are about to wire LLMs into critical workflows — support, operations, monitoring, onboarding, billing. Doing that safely requires more than a prompt. It requires agents that have roles, memory, tools, guardrails, escalation, and evaluation.
By the end of this course, you’ll know how to build that. And you’ll walk away with working, inspectable code you can adapt to your own use case.