AI Engineer Agentic Track: The Complete Agent & MCP Course

If you want to learn:

- What is the OpenAI Agents SDK and how does this open source agent framework compare to LangGraph and other agent frameworks?

- Why do all AI agent frameworks use async Python and what is asyncio?

- What is the difference between a coroutine and a function in async Python?

- How do async and await keywords work with the event loop?

- How do you run multiple AI agent tasks in parallel using asyncio.gather?

- Is the OpenAI Agents SDK available in Python and TypeScript, and can it work with non-OpenAI models?

Then this lecture is for you!

In this hands-on lecture, you'll be introduced to the OpenAI Agents SDK, Ed Donner's favourite agent framework, and you'll prepare for it by mastering the one skill every AI agent framework depends on: asynchronous Python. You'll learn that, while it is built by OpenAI, the OpenAI Agents SDK is an open source framework that works with almost any model, comes in both Python and TypeScript versions, and is the production-ready successor to OpenAI's experimental Swarm. You'll see where it fits in the agent frameworks landscape, between no framework, the lightweight options, and the more opinionated ones, and why building agents with the OpenAI Agents SDK keeps abstractions to a minimum with a simple, code-first approach.

You'll then take a deep dive into async Python and asyncio, because all the major agent frameworks run on asynchronous code. You'll start with the short version (turn every `def` into `async def`, and `await` every async call) before going deeper into what is really happening. You'll understand why an `async def` becomes a coroutine rather than a function, how calling it simply returns a coroutine object, and how `await` schedules that coroutine on the event loop. You'll grasp the aha moment that asyncio is cooperative multitasking, not true concurrency, with only one coroutine running at a time until it yields control at an `await`.

You'll see why this matters so much for AI agent workloads, where you're typically IO-bound waiting on an LLM response, and how `asyncio.gather` lets many coroutines run apparently in parallel. You'll learn why asyncio is lighter than threading or multiprocessing, avoiding race conditions and operating-system overhead. By the end, you'll be ready to write production-ready agents using the OpenAI Agents SDK with confidence in the async foundations beneath every agent running call.

If you want to learn:

- What are the core concepts of the OpenAI Agents SDK and how do you use them?

- What is the Agent class and how is a system prompt set with instructions?

- What is the difference between agents-as-tools and handoffs for multi-agent collaboration?

- What are guardrails in the OpenAI Agents SDK and how do they control inputs and outputs?

- What are the three steps to using the OpenAI Agents SDK: Agent, with trace, and runner.run?

- How should you use coding agents like Cursor and Claude Code while learning to build agents?

Then this lecture is for you!

In this hands-on lecture, you'll learn the core concepts of the OpenAI Agents SDK before you build anything in code, so the lab makes perfect sense. You'll see why this lightweight, open source agent framework stays out of your way and avoids what Ed calls "framework voodoo," making the once-painful "janky JSON" of tool use trivially easy. You'll be introduced to the central Agent class: one LLM combined with a system prompt (called instructions) and a set of tools. You'll get Ed's key guidance, echoed in OpenAI's own docs, to always start as simple as possible with a single agent before splitting into multiple sub-agents.

You'll then meet the SDK's two mechanisms for letting agents collaborate: agents-as-tools and handoffs, and you'll understand that this collaboration is really just simple prompting where one LLM's output becomes the next LLM's input, nothing like Google's A2A. You'll learn about guardrail controls as the framework's answer to agent reliability, and discover that you can either use the built-in implementation or simply hand-write a guardrail in Python.

You'll walk through the three steps to using OpenAI Agents SDK well: create an instance of Agent, optionally wrap your work in `with trace` for observability, and call `runner.run` to execute one "application level turn," the agent running loop that calls the LLM repeatedly until the task is done. You'll get a preview of streaming, tools, and adding memory, plus practical advice on staying in the driving seat when using OpenAI alongside coding agents. By the end, you'll understand every primitive you need to start building production-ready agents with the OpenAI Agents SDK.

If you want to learn:

- How do you build your first AI agent with the OpenAI Agents SDK using Agent and Runner.run?

- Why do you do `pip install openai-agents` (not `pip install agents`) and import Agent, Runner, Trace?

- Why does calling runner.run return a coroutine, and why do you need to await it?

- What is observability and how do you trace agents with `with trace` in the OpenAI Agents SDK?

- How do you view agent traces at platform.openai.com/traces?

- How do you stream agent output with runner.run_streamed in Python?

Then this lecture is for you!

In this hands-on lecture, you'll build your very first AI agent with the OpenAI Agents SDK and run it through the agent running loop. You'll start by importing Agent, Runner and Trace from the `agents` package, and you'll learn the crucial install detail: the package on PyPI is `openai-agents`, so you use `uv add openai-agents` or `pip install openai-agents`, never the legacy `pip install agents`. You'll then create your first Agent, a "jokester," giving it a name, instructions (the system prompt) and a model, and call `Runner.run` with the agent and a user prompt.

You'll hit a classic async gotcha: calling `runner.run` returns a coroutine object because it is an async function, so you must `await` it, then read `result.final_output`. You'll also learn about `result.to_input_list`, which returns the full conversation as a list of dictionaries in OpenAI format, handy later for adding memory.

You'll then explore observability, a cornerstone of building production-ready agents. You'll wrap your call in `with trace` and view the timeline at platform.openai.com/traces, seeing the exact system prompt, user input and output for each LLM call. You'll learn that tracing is a free service baked into the OpenAI Agents SDK that works with any model as long as an OpenAI API key is set, and that you can integrate other observability framework platforms like Langfuse or MLflow. Finally, you'll add streaming with `runner.run_streamed`, collecting events with an `async for` loop. By the end, you'll be confidently using OpenAI Agents SDK to create, trace and stream your own agents with the OpenAI Agents SDK.

If you want to learn:

- How do you add a tool to an AI agent with the OpenAI Agents SDK function_tool decorator?

- How does function_tool replace the "janky JSON" of manual tool use schemas?

- Why do you need type hints and a docstring for a function to become a tool?

- What is the function_tool object and what is params_json_schema?

- How do you pass tools to an Agent and have it call them with runner.run?

- How do you verify in the traces that an agent actually used a tool?

Then this lecture is for you!

In this hands-on lecture, you'll learn how easy tool use becomes with the OpenAI Agents SDK by turning an ordinary Python function into an agent tool with a single decorator. You'll start from the Pushover push-notification function you built in week one, the one that previously required a huge blob of hand-written "janky JSON" to describe it to the LLM. This time, you'll see that all that boilerplate disappears.

You'll rewrite the function as `push_tool` and make three small changes: add a docstring comment describing what it does, add type hints for the arguments and return value, and decorate it with `@function_tool`, imported from `agents`. You'll discover that after decorating, `push_tool` is no longer a plain function but a `function_tool` object, complete with a name, a description pulled straight from your docstring, and a `params_json_schema` built automatically from your type hints. This is the framework generating the JSON schema for you, so you never touch it by hand again.

You'll then create a new "notifier" Agent and, for the first time, pass a `tools` list when constructing it, simply dropping `push_tool` straight in. You'll call `runner.run` with a task like "notify the user that pizza is here," `await` it, and watch the notification arrive. Finally, you'll open the OpenAI traces to confirm the agent decided to call the push tool, see the arguments it passed, and read the tool's response, an essential observability habit. By the end, you'll be able to give any AI agent real capabilities by decorating any Python function with `@function_tool`, making building agents with the OpenAI Agents SDK remarkably fast and clean.

If you want to learn:

- How do you add memory and sessions to an AI agent with the OpenAI Agents SDK?

- Why does every runner.run call start as a blank slate with no conversation history?

- How do you maintain state by passing a list of dictionaries with to_input_list?

- How do you use SQLiteSession for short-term memory in the OpenAI Agents SDK?

- What is the difference between an in-memory session and storing memory to a database file?

- How does the context window limit conversation history, and how do you compact it?

Then this lecture is for you!

In this hands-on lecture, you'll learn how adding memory works in the OpenAI Agents SDK, where memory is handled through a primitive called sessions. You'll first prove to yourself that every `runner.run` call is a blank slate: you'll tell an assistant agent "my name is Ed," then ask "what's my name?" in a second `runner.run` and watch it draw a blank. You'll understand that conversation history is maintained within a single application turn, but a separate `runner.run` starts from scratch.

You'll then learn two simple, common ways to maintain state between calls. The first is the brute-force approach: instead of a plain string, pass `runner.run` a full list of dictionaries in OpenAI format. You'll use `response.to_input_list()` to grab the conversation so far, append a new user message, and pass the whole thing back in, exactly like managing history with `openai.chat.completions.create`. This shows you that "memory" is nothing mystical, just a Python list of dicts you can store in a flat file, an S3 bucket, MongoDB, or anywhere you like.

You'll then meet the built-in `SQLiteSession` object, imported alongside Agent, Runner and Trace. You'll create a session with an ID that tracks one conversation, pass `session=session` to `runner.run`, and see the agent remember your name across calls. You'll learn the difference between an in-memory database and persisting to disk by passing a filename like `memory.db`. Finally, you'll cover how the finite context window can eventually fill up, and tricks like truncating or compacting history. By the end, you'll know how adding memory to agents with the OpenAI Agents SDK really comes down to storing conversation history, a key skill for production-ready agents, and how this compares to dedicated memory tools like mem0 and zep.

If you want to learn:

- How do you build an automated sales team with AI agents and the OpenAI Agents SDK?

- What is a multi-agent system of SDR (sales development rep) agents that draft and send emails?

- What are the two main approaches to agent orchestration: by code and by LLMs?

- What is the difference between orchestrating agents as tools versus handoffs?

- Why is orchestration by code more reliable and predictable than orchestration by LLMs?

- Why should you evaluate AI agent outputs against real business metrics?

Then this lecture is for you!

In this hands-on lecture, you'll be introduced to the first major project of the week: building a multi-agent automated sales outreach function, a team of SDR (sales development rep) AI agents that draft cold emails so you can pick the best and send it. This classic business automation is the perfect vehicle for exploring agent orchestration, the different ways agents can communicate, pass instructions, and collaborate within the OpenAI Agents SDK. You'll be reminded that behind the scenes there's no magic, just messages, conversation history and prompts flowing between LLM calls, exactly as in week one.

You'll get a clear preview of the orchestration techniques you'll use when building a multi-agent system with OpenAI Agents SDK. First is multi-agent orchestration by code: making multiple `runner.run` calls and stitching them together with your own Python. This is the simplest, most bulletproof, most predictable approach. Then you'll preview orchestration by LLMs, in two flavours, agents-as-tools and handoffs, which give the AI agent more autonomy to plan the workflow itself, at the cost of reliability and predictability.

You'll also hear Ed's honest framing of why, in most production multi-agent system implementations, teams favour orchestrating by code over the more fashionable LLM-driven approach. And you'll get an important best-practice warning: this lab deliberately jumps straight into multiple agents and skips rigorous evaluation, so you understand that real success means measuring outputs against a commercial metric like email open rates, not just plausible-looking content. By the end, you'll be ready to start building agents into a working SDR sales team using the OpenAI Agents SDK.

If you want to learn:

- How do you set up email sending for your SDR AI agents in the OpenAI Agents SDK?

- How do you send email from Python using SMTP with Gmail, Outlook, iCloud or Microsoft 365?

- How do you create an app-specific password and configure EMAIL_SMTP_SERVER in your .env?

- What is the difference between SMTP and bulk providers like SendGrid and Resend?

- How do you fall back to Pushover notifications instead of email for your multi-agent system?

- How do you wrap email sending in a send_message function for your AI agent to use?

Then this lecture is for you!

In this hands-on lecture, you'll set up the email-sending plumbing your SDR multi-agent system needs before you start on orchestration. You'll learn why Ed avoids the heavyweight setup of bulk providers like SendGrid (owned by Twilio) and Resend, which require a verified domain and DNS records, and instead chooses a lightweight SMTP approach that sends a handful of emails directly from your own inbox. You'll see that this is a deliberate choice so the focus stays on building a multi-agent system with OpenAI Agents SDK, not on email infrastructure.

You'll configure three values in your `.env` file: `EMAIL_SMTP_SERVER` (such as smtp.gmail.com, smtp-mail.outlook.com, smtp.office365.com or smtp.mail.me.com), an `EMAIL_APP_PASSWORD` created as an app-specific password, and your `EMAIL_ADDRESS`. You'll learn the Gmail quirk of stripping spaces from the 16-character app password, and confirm that emails are only ever sent from you to you. You'll then write a `send_email` function using Python's standard-library `smtplib` and fire off a test message to verify it works.

You'll also build in resilience: a `use_email` flag that, when email isn't set up, falls back to Pushover push notifications instead, reusing your push function from week one. You'll wrap everything in a single `send_message` function, the one your AI agent will actually call as a tool, which routes to whichever channel is working. By the end, you'll have a working communications layer ready to plug into your multi-agent orchestration workflow, so your AI agents can actually send the sales emails they draft.

If you want to learn:

- What is the difference between orchestrating AI agents by code versus by LLMs?

- How does agent orchestration by code chain multiple runner.run calls together?

- How does orchestration by LLMs use one runner.run with tools that call other agents?

- What does OpenAI's Agent Orchestration documentation say about the two orchestration approaches?

- How do structured outputs help you orchestrate a multi-agent system deterministically?

- When should you use agent orchestration by code versus LLM-driven orchestration in production?

Then this lecture is for you!

In this hands-on lecture, you'll get a clear conceptual grounding in the two ways to handle agent orchestration in the OpenAI Agents SDK before you implement them. You'll learn that orchestrating by code means making multiple `runner.run` calls, interpreting each response with your own Python, and constructing the next call, very similar to the manual LLM chaining you did in week one. It's the most obvious, most reliable, most bulletproof approach. You'll then learn that orchestrating by LLMs means a single `runner.run` on one agent equipped with tools, where calling a tool sends a message to another agent, giving the LLM the autonomy to plan the workflow itself.

You'll read through OpenAI's own "Agent Orchestration" documentation alongside Ed, which describes the two main ways to orchestrate: allowing LLMs to make decisions, or determining the flow via your code. You'll see the two LLM-driven patterns the SDK provides, agents as tools and handoffs, and the code-driven techniques: chaining the output of one agent into the input of the next, and using structured outputs to decide what happens next in a more regimented, deterministic way.

You'll understand the real trade-offs that matter when building a multi-agent system with OpenAI Agents SDK: orchestration by code gives predictability and determinism, which is why most production multi-agent system implementations favour it, while orchestration by LLMs powers highly autonomous agent orchestration platforms and products like Claude Code, Codex and Cowork. By the end, you'll know exactly which multi-agent orchestration approach to reach for, and you'll be ready to implement orchestration by code for your SDR sales team.

If you want to learn:

- How do you orchestrate sales AI agents by code with the OpenAI Agents SDK?

- How do you run three SDR agents in parallel with asyncio.gather under one trace?

- How do you build a Sales Picker agent to choose the best cold email?

- How do you add a send_email_tool with @function_tool to send the chosen email?

- How do you force an agent to use a tool with model_settings and tool_choice="required"?

- How do you verify a code-orchestrated multi-agent workflow in the OpenAI traces?

Then this lecture is for you!

In this hands-on lecture, you'll implement agent orchestration by code for your SDR sales team using the OpenAI Agents SDK. You'll start by writing a shared intro for your system prompts (a sales agent for "ComplAI," a SOC 2 compliance SaaS) and three distinct instructions, professional, humorous and concise-executive, to create three Agent objects with different email styles. You'll run one with `runner.run_streamed` to see streaming again, then run all three in parallel using `asyncio.gather`, wrapped under a single `with trace` umbrella so the whole workflow appears together in the logs.

You'll then build a fourth agent, the Sales Picker, with instructions to imagine being a customer and select the single best cold email. You'll "smush" the three drafts into one string and pass them to the picker, an elegant example of multi-agent orchestration by code that is, in Ed's words, almost boring in its simplicity, because it's just Python calling one `runner.run` after another.

Next, you'll make it actionable by adding a `send_email_tool`, decorated with `@function_tool` and given a full docstring describing each argument, so the SDK auto-generates the JSON schema. You'll create a "sales_sender" agent equipped with that tool, and use `model_settings` with `tool_choice="required"` to force reliable tool use, a practical fix Ed found necessary. You'll run the full pipeline, three parallel drafts plus a picker that sends the winning email, and verify everything in the OpenAI traces, seeing the agents run in parallel, the tool call, and the email landing in your inbox. By the end, you'll have a complete, predictable code-orchestrated multi-agent system with OpenAI Agents SDK, and the confidence to iterate on prompts when building agents for production.

If you want to learn:

- How do you orchestrate AI agents with tools (agents as tools) in the OpenAI Agents SDK?

- How do you turn an agent into a tool with agent.as_tool()?

- How do you build a Sales Manager agent that uses sales-writer agents as tools?

- How does orchestration by LLMs run everything inside a single runner.run?

- How do you visualise a multi-agent workflow as a graph in the OpenAI Agents SDK?

- When does the agents-as-tools pattern work best for multi-agent orchestration?

Then this lecture is for you!

In this hands-on lecture, you'll implement agent orchestration by LLMs using the agents-as-tools pattern in the OpenAI Agents SDK, Ed's preferred LLM-driven approach. You'll learn that calling `.as_tool()` on any agent generates boilerplate wrapper code that turns that agent into a tool, one whose input becomes the user prompt for the wrapped agent, all running within the same `runner.run`. You'll see this is ideal when one agent (a manager or planner) calls another and expects control to return to it.

You'll take your three style-specific sales agents and convert each into a tool with `as_tool()`, naming them sales_email_writer_1, 2 and 3 with clear descriptions (you'll see why a duplicative-sounding description is sometimes needed for reliability). You'll add these three plus the `send_email_tool` to give a Sales Manager agent four tools in total. You'll write the manager's instructions as a natural-language version of the workflow: generate drafts using each of the three tools, evaluate and select, then send only the single best email.

You'll then use the SDK's built-in graphing feature to visualise the multi-agent system, seeing the Sales Manager branch out to its four tools, with an agent hidden behind each writer tool. The beauty of orchestration by LLMs is that running it is just a single `runner.run` to the manager, the LLM does all the orchestrating itself. You'll inspect the OpenAI traces to confirm the three writer agents ran in parallel, the manager reasoned, then called the send tool, and the email arrived. By the end, you'll be able to build flexible multi-agent orchestration where the LLM coordinates building agents as tools inside the OpenAI Agents SDK.

If you want to learn:

- How do you delegate between AI agents with handoffs in the OpenAI Agents SDK?

- What is the difference between agents-as-tools and handoffs for multi-agent orchestration?

- How do you add a handoffs list to a Sales Manager agent so it passes control to a sales sender?

- How are handoffs implemented behind the scenes as tools with special prompting?

- Why can't agent names contain spaces when they become tools in the OpenAI Agents SDK?

- How do you visualise and verify a handoff in the OpenAI traces?

Then this lecture is for you!

In this hands-on lecture, you'll complete your tour of LLM-driven agent orchestration by implementing handoffs in the OpenAI Agents SDK, the third and (in Ed's candid view) least favourite technique. You'll learn the key conceptual difference: with agents-as-tools, control goes from agent A to agent B and back to A, whereas with a handoff, agent A delegates and passes control across to B, not expecting it to return. You'll also learn that handoffs are implemented behind the scenes as tools with extra "framework voodoo" prompting baked in, which is why they can be less reliable.

You'll build a flow similar to the code-orchestrated one: a Sales Manager that generates drafts using three sales agents as tools, then hands off to a sales_sender agent to choose and send the best email. You'll see that, unlike `as_tool()`, you don't wrap a handoff, you simply pass the agent into a `handoffs` list when constructing the manager, alongside its `tools`, `instructions` and `model`. You'll use the SDK's graphing feature to visualise the difference, seeing the thick, non-optional handoff line from manager to sender.

You'll run the single `runner.run` and hit a real-world gotcha Ed encountered live: agent names can't contain spaces when they're turned into tools, so they must use underscores, though the OpenAI Agents SDK recovers automatically with a warning. You'll inspect the traces to see the three agents run in parallel, the first-ever handoff, and the sender's email arriving in your inbox. You'll close with rich exercises, from refining email-generation prompts to a hard challenge of switching to SendGrid or Resend, or a Telegram bot, to build a fully automated sales agent. By the end, you'll understand all three multi-agent orchestration patterns and have a firm view on which to use when building agents with the OpenAI Agents SDK.

If you want to learn:

- What are agent guardrails in the OpenAI Agents SDK and how do input and output guardrails work?

- How do you use non-OpenAI models like Gemini, Kimi K2 and GPT-OSS with the Agents SDK?

- How do you set a base URL and AsyncOpenAI client to use a different LLM provider?

- What is the difference between input guardrails, output guardrails and tool guardrails?

- What is a guardrail tripwire and when does it raise an exception?

- What is MCP and how does the OpenAI Agents SDK make using MCP servers easy?

Then this lecture is for you!

In this hands-on lecture, you'll go deeper into the OpenAI Agents SDK by learning to use other models, previewing guardrail concepts, and getting a sneak peek of MCP. You'll start by wiring up multiple LLM providers in three steps: look up the OpenAI compatible base URL, create an `AsyncOpenAI` client with that base URL and API key, then create an `OpenAIChatCompletionsModel` object naming the client and model. You'll do this for Gemini, Kimi K2 (via OpenRouter), and OpenAI's GPT-OSS open source model (via Groq), and learn the crucial rule: pass a string for an OpenAI model, but a model object for any other provider.

You'll then re-run the SDR sales workflow as a multi-agent orchestration-by-tools setup, but with three agents powered by three different models. You'll reuse `as_tool()`, a shared `messenger.py` module for email sending, and a `send_email_tool`, then run a Sales Manager and inspect the traces to compare how fast Gemini, Kimi K2 and GPT-OSS each ran, and which model the manager picked.

You'll get a thorough conceptual introduction to guardrails, the OpenAI Agents SDK's answer to agent reliability and agent security. Reading OpenAI's documentation, you'll learn the three types, input guardrails, output guardrail and tool guardrails, and the important gotchas: input guardrails only run on the first agent, output guardrails only on the last, and a triggered tripwire raises an exception that halts the multi-agent workflow. Finally, you'll get a teaser of sandboxes and MCP, the topics that round out this agents sdk deep-dive. By the end, you'll be ready to write real guardrail code and understand where the OpenAI agent framework is headed next.

If you want to learn:

- How do you use structured outputs with the OpenAI Agents SDK and Pydantic?

- How do you define a Pydantic BaseModel and pass it as an Agent output_type?

- How do LLMs generate JSON that maps to a Python object via a JSON schema?

- What is constrained decoding and how does it guarantee valid structured output?

- How do you use Field descriptions to guide what an agent puts in each field?

- How do guardrails relate to structured outputs in the OpenAI Agents SDK?

Then this lecture is for you!

In this hands-on lecture, you'll master one of Ed's favourite topics: structured outputs with the OpenAI Agents SDK. You'll learn how an LLM, which only really generates tokens, can be made to produce a Python object instead of free text. The trick comes down to good prompting and JSON: you describe the object as a JSON schema in the system prompt, the model generates conforming JSON, and the framework populates your object from it. You'll see why Pydantic is the perfect library for this, letting you map a Python object to and from JSON simply by subclassing `BaseModel`.

You'll go one level deeper into the genuinely clever engineering behind structured outputs: constrained decoding. You'll understand how, during inference, the model zeroes out the probability of any next token that would break your schema, making valid JSON output almost certain, and you'll learn that not every provider (Groq, for example) supports this. You'll also pick up the best practice of keeping your output schema relatively simple and mapping to more complex structures in code afterwards.

You'll then build it for real, defining an `EmailReview` Pydantic class subclassing `BaseModel` with fields like `is_professional`, `number_of_sentences` and `contains_placeholders`, each given a type and a `Field` description in natural language to guide the model. You'll inspect the generated schema with `model_json_schema()`, create a "Checker" agent with `output_type=EmailReview`, and run it on a deliberately unprofessional email. You'll get back a populated object, not text, letting you write code like `if review.is_professional`. This sets up the lecture's finale on guardrails, where Ed explains his reservations about the SDK's built-in guardrail implementation. By the end, you'll be using structured output confidently to put robust, code-friendly scaffolding around your AI agent calls in the OpenAI Agents SDK.

If you want to learn:

- How do you write input and output guardrails in code with the OpenAI Agents SDK?

- How do you use the @output_guardrail decorator and return a GuardrailFunctionOutput?

- How do you build a guardrail that itself makes an LLM call with runner.run and structured outputs?

- How do you trigger a tripwire to halt agent execution and raise an exception?

- Why does Ed recommend writing simple guardrails with plain Python and runner.run instead?

- How do sandbox agents and MCP servers (like Context7) work in the OpenAI Agents SDK?

Then this lecture is for you!

In this hands-on lecture, you'll write real input guardrails and output guardrail code in the OpenAI Agents SDK, then learn a simpler alternative Ed prefers. You'll define an `email_guardrail` function decorated with `@output_guardrail`, taking context, agent and the message to check. Inside it, you'll call `runner.run` on the "Checker" agent from the previous lecture, retrieve the `EmailReview` structured output via `result.final_output`, and decide there's a problem if the email contains placeholders or isn't professional. You'll return a `GuardrailFunctionOutput` and set `tripwire_triggered`, learning that a triggered tripwire halts execution and raises an exception.

You'll prove it works by creating a "Cowboy" agent whose instructions tell it to "speak like a cowboy," attaching your `email_guardrail` to its `output_guardrails` list, and running it, watching the guardrail raise an "output guardrail tripwire" exception. You'll confirm in the OpenAI traces that the checker found the email unprofessional with placeholders, triggering the tripwire.

You'll then learn Ed's recommended simpler approach: rather than relying on the framework's hardwired guardrail constructs, write your controls as plain Python with explicit `runner.run` calls, checking inputs before the next call and outputs before sending, which keeps things transparent and portable across any agent framework. Finally, you'll explore two optional extras: sandbox agents, the newest runtime feature, where you'll set up a manifest, capabilities and sandbox run config to have an agent find and fix a bug in `orders.py`, and a sneak preview of MCP, plugging in the Context7 MCP server so an older model can answer questions about the very latest APIs. By the end, you'll be able to build robust guardrails, forcing tool use where needed, and you'll understand how the OpenAI Agents SDK handles agent security, sandboxing and MCP.

If you want to learn:

- How do you build a deep research agent with the OpenAI Agents SDK?

- What are the four agents (search, planner, writer, emailer) in an open source deep research app?

- Why do you orchestrate a deep research workflow by code rather than by LLMs?

- How does a planner agent break a user query into multiple web searches?

- What are OpenAI hosted tools and how do they fit into a research agent?

- How do you plan a multi-agent deep research project before writing the code?

Then this lecture is for you!

In this hands-on lecture, you'll lay the groundwork for one of the most iconic agentic AI use cases: your own deep research agent, built using the OpenAI Agents SDK. You'll learn how OpenAI pioneered deep research about eighteen months ago, going off to run multiple internet searches and draft a report, and how you'll recreate that experience yourself. Crucially, because this is a step-by-step workflow, you'll orchestrate it by code, making multiple `runner.run` calls so the system is bulletproof and predictable, rather than handing control to a single manager agent.

You'll set up your constants, choosing a cheap model like GPT-5.4-mini (with GPT-5.4-nano as an even cheaper option), a `use_email` flag, and a `how_many_searches` value that controls how many individual web search calls run. You'll see the api cost implications upfront and how to dial searches down if needed.

You'll then get a clear map of the four specialized agents you'll build. The search agent looks something up on the internet using a tool. The planner agent takes a user query and breaks it into multiple search terms (five by default) using structured outputs. The writer agent generates a report from the combined search results. And the emailer agent sends the finished report out. You'll learn that each agent gets a matching Python function that calls `runner.run`, four runner.run calls in all to orchestrate the whole research assistant pipeline. By the end, you'll understand the full architecture of this open source deep research project and be ready to start building agents for it, appreciating how simple the "magic" of deep research really is when you build it with the OpenAI Agents SDK.

If you want to learn:

- How do you build a search agent using OpenAI hosted web search tools in the OpenAI Agents SDK?

- What are OpenAI's hosted tools and how do they differ from function tools you write yourself?

- How do you add the WebSearchTool to an agent's tools list?

- How much does the hosted web search tool cost per call, and how do costs add up?

- What other hosted tools exist (file search, code interpreter, image generation, hosted MCP)?

- Why do hosted tools lock you into the OpenAI ecosystem for your deep research agent?

Then this lecture is for you!

In this hands-on lecture, you'll build the first of your four deep research agents, the search agent, using the OpenAI agents SDK and OpenAI's hosted web search tools. You'll learn that hosted tools run on OpenAI's managed infrastructure rather than your computer, so you don't write the function tool yourself, but there are catches: they cost money (about one cent per web search for now) and they lock you into the OpenAI ecosystem, meaning learners using the openai stack with Gemini can't use them directly. You'll see why Ed recommends hosted tools for prototyping but building your own open source search for production, something you'll do in later weeks.

You'll tour the full range of OpenAI hosted tools, the file search tool (for hosted vector stores and RAG), the code interpreter tool, the hosted MCP tool, the image generation tool, and the tool search tool, and Ed's honest take on when each is and isn't worth the api cost. You'll do the maths on running five searches per deep research agent run, and how a day of experimenting can add up to a dollar.

You'll then build the search agent itself. You'll write instructions making it a research assistant that searches the web for a given term and returns a concise two-to-three-paragraph summary under 300 words. You'll use `model_settings` with `tool_choice="required"` to force tool use, and add a `WebSearchTool()` instance to the agent's tools list. You'll call `runner.run` with a query and watch the results come back, then inspect the OpenAI traces, learning that hosted tools appear as part of the Responses API call rather than as a separate tool. By the end, you'll have a working web search research agent and a clear understanding of OpenAI hosted tools within the OpenAI Agents SDK.

If you want to learn:

- How do you build a planner agent with structured outputs in the OpenAI Agents SDK?

- How do you define WebSearchItem and WebSearchPlan Pydantic models for a deep research agent?

- Why should you put the reason before the query in your structured output?

- How do you set output_type on an agent to generate a list of web searches from a query?

- How do you build the writer agent and ReportData model for a markdown report?

- How do you create the email agent with a send_email_tool for your research agent?

Then this lecture is for you!

In this hands-on lecture, you'll build the planner, writer and email agents of your deep research agent using the OpenAI agents SDK, leaning heavily on structured outputs. You'll start with the planner agent and define two Pydantic models: `WebSearchItem`, holding a `reason` and a `query`, and `WebSearchPlan`, holding a list of those items. You'll learn a subtle but important best practice, putting the `reason` before the `query` so the model reasons about why it's searching before generating the search term, which produces better queries because the order of fields is the order the LLM generates them.

You'll create the planner agent with `output_type=WebSearchPlan`, run it on a user query like "the most popular AI agent frameworks," and get back a structured `WebSearchPlan` object containing five web searches, each with its reasoning and search term. You'll inspect the schema with `model_json_schema()` to see exactly how it all fits together.

You'll then build the writer agent, defining a `ReportData` Pydantic model with a `short_summary`, a `markdown_report`, and a list of `follow_up_questions`, and writing instructions that push for a lengthy, detailed markdown report of at least 1,000 words. Finally, you'll build the fourth agent, the emailer, creating a `send_email_tool` with `@function_tool` that routes to email or Pushover based on `use_email`, and an email agent instructed to convert the report into a clean HTML email. By the end, you'll have all four specialized agents of your multi-agent research assistant defined and ready to orchestrate, showcasing the power of structured outputs in the OpenAI Agents SDK.

If you want to learn:

- How do you run four agents in parallel with asyncio in a deep research agent?

- How do you write functions that call runner.run for each agent in your multi-agent workflow?

- How do you use asyncio.gather to run five web searches in parallel?

- How do you orchestrate a deep research pipeline by code from planner to email?

- How do you verify a parallel research agent run in the OpenAI traces?

- How does using a bigger model and more searches improve deep research output quality?

Then this lecture is for you!

In this hands-on lecture, you'll bring your deep research agent to life by writing the four Python functions that orchestrate its agents, and running multiple searches in parallel with asyncio. You'll learn that each function is essentially a single `runner.run` call wrapped in print statements. The `run_searches` function calls `runner.run` on the planner agent to get the search plan, then turns each of the five search items into a coroutine and uses `asyncio.gather` to run them all in parallel through the search agent. The remaining functions call `runner.run` on the writer agent and the email agent.

You'll see how clean orchestration by code is: a bit wordy because everything is done carefully, but completely predictable. You'll then run the full deep research pipeline on a real query, "the most popular AI agent frameworks 2026," and watch the status updates flow, planning searches, performing five parallel searches, writing the report, and sending the email. You'll confirm the email actually arrives in your inbox.

You'll inspect the OpenAI traces to see the workflow in action: the planner agent runs first, then five search agents run in parallel, followed by the writer agent and the email agent, all grouped under one trace thanks to `with trace`. You'll appreciate that orchestrating by code doesn't prevent the LLM from making decisions, because structured outputs can still drive what happens next. Finally, you'll crank things up, switching to a beefier model (GPT-5.5) and 20 searches, re-executing the agent definitions, and seeing noticeably stronger output quality, at a slightly higher api cost. By the end, you'll have a fully working, parallelised deep research agent using the openai agents SDK, ready to productionize.

If you want to learn:

- How do you turn a deep research Jupyter notebook into Python modules for deployment?

- How do you structure four agents (search, planner, writer, email) as separate Python modules?

- How do you read a default model name and use_email flag from a .env file?

- How do you build a ResearchManager class with a run method that orchestrates the workflow?

- What are Python generators and the yield statement, and why do they matter for Gradio?

- Why do yields let you update the Gradio interface as each step completes?

Then this lecture is for you!

In this hands-on lecture, you'll begin the finale of the deep research project by taking it out of Jupyter notebooks and into clean Python modules, the first step toward deploying a real ai app. You'll recap the four agents you built, search, planner, writer and email, and refactor each into its own module inside a `deep_research` folder. You'll add a nice touch: each module reads a `DEFAULT_MODEL_NAME` from your `.env` file, falling back to GPT-5.4-mini, and reads `HOW_MANY_SEARCHES` and `USE_EMAIL` the same way, so the whole app is configurable without editing code.

You'll carry over everything you built: the `WebSearchTool` and `model_settings` in the search agent, the `WebSearchItem` and `WebSearchPlan` Pydantic models with `output_type` in the planner agent, the `ReportData` structured output in the writer agent, and the `send_email_tool` plus `tool_choice="required"` in the email agent. You'll see why iterating on instructions in the lab first, then locking them into modules, is such a good practice.

You'll then gather the `runner.run` calls into a `research_manager.py` module, splitting planning into `plan_searches` and `perform_searches` (which uses `asyncio.gather` for parallel web search), plus `search`, `write_report` and `send_email`. You'll wrap it all in a `ResearchManager` class with a single `run` method that calls each function in turn. Crucially, you'll learn about Python generators and the `yield` statement, and why turning `run` into a generator lets Gradio update the interface live as each step completes. By the end, you'll have a production-style, modular deep research codebase ready for a Gradio ai app interface.

If you want to learn:

- How do you build a Gradio UI for your deep research agent?

- How do you connect a Gradio interface to a ResearchManager run generator with yields?

- How do you run a Gradio app with `uv run simple.py` and `uv run app.py`?

- How do you wire a button and text box to a run callback that streams status updates?

- How can a coding agent like Claude Code polish your Gradio demo with custom CSS?

- How do you show live status updates and a research report in a Gradio interface?

Then this lecture is for you!

In this hands-on lecture, you'll build a Gradio interface on top of your modular deep research agent, turning it into a real ai app. You'll start with `simple.py`, writing a function that iterates over the `ResearchManager.run` generator and treats each yielded value as a status update for the UI. You'll wire up a minimal Gradio interface, a single text box and button, connected to a `run` callback that streams results into a report field, and learn that this is all the Gradio plumbing you need.

You'll launch the Gradio app with `uv run simple.py`, open it in the browser, and ask "What are the most popular AI agent frameworks in 2026?" You'll watch the live updates appear, courtesy of those `yield` statements, including a clickable link to the live trace, then see the finished research report rendered in the UI. This shows you how easy it is to build a working Gradio demo around an agentic workflow.

You'll then level up the look. Because the default Gradio app is immediately recognisable, you'll see how Ed used a coding agent (Claude Code) to repolish the UI into `app.py`, generating a separate `styles.py` with custom CSS, JavaScript, examples and a header, all hooked in via `ui.launch`. You'll run `uv run app.py` to see the sharp, modern, dark-and-light-mode interface with canned example questions, and run fresh research queries through it, marvelling at how a coding agent handles the data science UI polish that many engineers find tricky. By the end, you'll have a beautiful, fully functional Gradio interface for your deep research ai app, ready to deploy.

If you want to learn:

- How do you deploy your deep research app on Hugging Face Spaces?

- How do you log in to Hugging Face with `uvx hf auth login --token` and check `hf auth whoami`?

- How do you deploy a Gradio app with `uv run gradio deploy`?

- How do you add API keys and secrets as variables on a Hugging Face Space?

- Why does Hugging Face Spaces block SMTP email, and how do you use Pushover instead?

- How can you extend the deep research app with clarifying questions and LLM orchestration?

Then this lecture is for you!

In this hands-on lecture, you'll deploy your deep research ai app to Hugging Face Spaces, putting your Gradio app live on the internet. You'll start from the `deep_research` folder and handle authentication, logging in with `uvx hf auth login --token` and your `HF_TOKEN`, and confirming your identity with `uvx hf auth whoami`. You'll learn that `uvx` automatically sets up and runs a Hugging Face tool as a handy shortcut.

You'll then run `uv run gradio deploy`, answering the prompts to set the title (Deep Research), the app file (`app.py`), basic hardware, no secrets at this stage, and no GitHub Action. You'll watch your Hugging Face Space get created, then open it and fix the inevitable missing-environment-variable errors by going into Settings and adding your keys under Variables and Secrets, pressing New Secret for each one (your OpenAI API key, `use_email`, and your Pushover user and token).

You'll learn an important deployment gotcha: Hugging Face Spaces blocks direct SMTP email to prevent spam, so for deploy gradio apps like this you should either use a professional provider such as SendGrid or Resend with a verified domain, or simply set `use_email` to false and rely on Pushover push notifications. After restarting the Space, you'll run the default query and confirm both the report and a push notification arrive. Finally, you'll get three rich challenges to take your deploy your ai app further, adding clarifying questions, weaving those clarifications through the searches, and rebuilding the orchestration from code to agents-as-tools so a manager agent can autonomously decide when to ask more questions. By the end, you'll have a live deep research app deployed on Hugging Face Spaces, plus a roadmap to make it even more powerful.

If you want to learn:

- What is CrewAI and why is it the most popular multi-agent framework?

- How does the CrewAI open source framework compare to OpenAI Agents SDK and LangGraph?

- What is the difference between CrewAI Crews and CrewAI Flows?

- How do teams of AI agents collaborate to solve complex problems with CrewAI?

- Why is CrewAI described as a batteries-included, opinionated crewai framework?

- How do you start building multi-agent AI systems and your first crew with CrewAI?

Then this lecture is for you!

In this hands-on lecture, you'll meet CrewAI, the fan-favourite crewai framework that kicks off Week 3 of the course. Ed Donner orients you on the agentic landscape: you began with no framework, moved on to the lightweight OpenAI Agents SDK, and now you arrive at CrewAI, which sits in the more opinionated, batteries-included category. You'll learn why it's loved for being simple, quick to get started, and ideal for building multi-agent AI systems where teams that work together collaborate to automate and solve complex problems.

You'll also untangle the CrewAI product landscape so you don't get confused. The real website is crewai.com (not crew.ai), where you'll see paid products like CrewAI AMP (the agent management platform sometimes branded CrewAI Enterprise), a multi-agent runtime to deploy, run and monitor agents in production, and CrewAI UI Studio, a low-code/no-code platform similar to n8n. But the star of the show, and the focus of this course, is the CrewAI Open Source Framework, the free library that lets you orchestrate ai agent systems quickly and at scale. You'll understand why CrewAI monetizes those peripheral products while the open source core stays free.

Finally, you'll explore the two flavours inside the framework: CrewAI Crews, described as the intelligence, where teams of agents with different roles collaborate toward a goal, and CrewAI Flows, the higher-level orchestration backbone that strings Crews together with structured automations. By the end of this lecture, you'll know exactly what CrewAI is, how to navigate its ai system ecosystem, and why Crews are the construct you'll configure and use most as you start deploy multi-agent systems with crewai and llms throughout this week.

If you want to learn:

- What are the core CrewAI concepts of agents, tasks, and crews?

- How do role, goal, and backstory combine into an agent's system prompt in CrewAI?

- What is the difference between sequential and hierarchical crews in a multi-agent system?

- How do agents.yaml and tasks.yaml separate configuration from code in the crewai framework?

- How do you configure llms and switch providers in CrewAI using LiteLLM?

- What .env gotchas trip people up when building multi-agent AI systems with CrewAI?

Then this lecture is for you!

In this hands-on lecture, you'll master the core terminology behind CrewAI before building anything. You'll learn that an ai agent in CrewAI, like in every framework, is an llm with a system prompt, tools, and memory, but CrewAI is opinionated: it wants three pieces of information, the role (the agent's purpose), the goal (what it's trying to achieve, ideally with success criteria), and the backstory (relevant context). CrewAI combines these into a system prompt for you, so you benefit from the Crew team's prompt engineering at the cost of a little transparency.

Next you'll learn the second concept, the task, a specific assignment with a description and expected output that is assigned to an agent, much like a user prompt. Then comes the crew itself, a bunch of agents and tasks together. You'll see that crews run in two modes: sequential, where tasks run in defined order plus dependencies (akin to orchestration by code), and hierarchical, where a manager llm decides the order (orchestration by LLM). You'll also learn that getting tasks right matters even more than the agents.

Finally, you'll discover how CrewAI cleanly separates definitions from code using YAML files, agents.yaml and tasks.yaml, alongside the Python files crew.py and main.py. You'll learn how CrewAI uses LiteLLM to configure almost any llm, the gotcha that Gemini needs GEMINI_API_KEY (not just GOOGLE_API_KEY), and why you must delete the inner .env file CrewAI creates. By the end, you'll understand every building block needed to start building multi-agent AI systems and your first crew.

If you want to learn:

- How do you install CrewAI as a uv tool on your computer?

- What does `uv tool install crewai==1.14.4` do and why pin the version?

- How do you check installed tools with `uv tool list` and uninstall an old CrewAI?

- How do you add CrewAI skills to Cursor or Claude Code with `npx skills add`?

- What is the MS Build Tools gotcha for Windows users installing CrewAI?

- How should you organize the reference and coursework folders for building multi-agent projects?

Then this lecture is for you!

In this hands-on lecture, you'll install CrewAI on your computer so you're ready to start building multi-agent AI systems. You'll learn what a uv tool is: a global command installed through the UV environment that you can run anywhere, independent of any UV project, just like the Hugging Face `hf` tool. Since the crewai framework uses UV throughout, you'll feel right at home. You'll run `uv tool list` to see what's already installed, `uv tool uninstall crewai` to start from a clean slate, then `uv tool install crewai==1.14.4` to pin the exact version used in the course so everything works identically. You'll also learn that you can install the latest version if you prefer, while watching for CrewAI's occasional breaking changes.

Next you'll set up optional but powerful coding-agent help. You'll learn how the CrewAI team publishes skills that teach a coding agent everything about the crewai framework, and you'll install them with `npx skills add crewaiinc/skills`, selecting skills like Ask Docs, Design an agent, Design a task, and Getting started. You'll choose which agents to support (Cursor and Claude Code), then install them globally via a symlink so your coding agents can give you a helping hand.

Finally, you'll learn the gotchas and project layout. Windows users must install the MS Build Tools or hit an obscure Chroma error, and you'll check the special README inside the `3_crewai` folder for updates. You'll organize a `reference` folder (the instructor's projects) and a `coursework` folder (where you replicate them). By the end, CrewAI will be installed, your tools configured, and you'll be ready to create your first crew.

If you want to learn:

- How do you create your first CrewAI project structure with `crewai create crew`?

- What scaffolding files does CrewAI generate (agents.yaml, tasks.yaml, crew.py, main.py)?

- How do you run a crew with `crewai run` from inside the project directory?

- How do you configure an llm inside a CrewAI agents.yaml file?

- Why must you delete the inner .env file CrewAI creates in a new project?

- How do you fix the Apple silicon error with `uv python pin 3.13` in CrewAI?

Then this lecture is for you!

In this hands-on lecture, you'll create your very first crew project structure and run it end to end. You'll learn that every CrewAI project is itself a UV project, and that you scaffold one with the command `crewai create crew` followed by your project name. You'll watch CrewAI chug through and build a deep directory hierarchy: a top-level project folder, a `src` directory, a crew sub-directory, a `config` folder holding the two YAML files agents.yaml and tasks.yaml, and the two Python files crew.py and main.py. You'll answer the setup prompts (provider, model, key), then immediately delete the inner .env file so it can't override your project's keys, and run `uv python pin 3.13` to fix a packaging error on Apple silicon Macs.

Next you'll explore the default researcher project CrewAI generates, a mini deep-research crew with a researcher agent and a reporting analyst. You'll open agents.yaml to see the role, goal, and backstory structure, and add an `llm:` line (carefully indented to match role/goal/backstory) to configure your model of choice, such as GPT-5 mini. You'll examine tasks.yaml to see each task's description, expected output, and assigned agent, and peek into crew.py and main.py, where you set the topic input.

Finally, you'll kick everything off with `crewai run`, watch CrewAI build the UV environment, install ~140 packages, and execute the research and reporting tasks in sequence. By the end, you'll have produced a `report.md` on the most popular AI agent frameworks and seen your first multi-agent ai system run out of the box.

If you want to learn:

- How do you build a debate crew with two agents using CrewAI?

- How do you define a debater and a judge agent with role, goal, and backstory?

- How do you write three tasks (propose, oppose, decide) in tasks.yaml?

- How do you assign tasks to specific agents in a multi-agent system?

- How do you use placeholder variables like `{motion}` in CrewAI YAML files?

- How do you set output files for each task in a crewai framework project?

Then this lecture is for you!

In this hands-on lecture, you'll build your second CrewAI project from scratch, a debate crew where agents collaborate in a structured competition. Instead of accepting the default researcher, you'll run `crewai create crew debate`, delete the auto-created .env, and (on Apple silicon) run `uv python pin 3.13`. You'll then open the config folder and edit the two YAML files that drive the prompts, starting with agents.yaml, where you define two agents: a debater and a judge. Each agent gets a role, a goal with success criteria, a backstory, and an llm, and you'll use the `{motion}` placeholder variable in curly braces so the topic can be populated later from main.py.

Next you'll configure tasks.yaml with three tasks. The propose task and the oppose task are both assigned to the debater agent, while the decide task is assigned to the judge agent. You'll learn that each task has a clear description and an output file, so propose, oppose, and decide each write their own markdown result. You'll see why people love CrewAI's clean separation: instead of prompts scattered through your code, the prompts, agents, and tasks live neatly organized in the config folder, a major advantage over earlier projects like the deep research app.

By the end of this lecture, you'll have fully defined two agents and three tasks for a real debate, understand exactly how tasks are assigned to agents, and be ready to wire everything together in crew.py and set the motion in main.py. You'll be one step away from running your own live, multi-agent AI debate with CrewAI.

If you want to learn:

- How do you set up crew.py with agents and tasks in CrewAI?

- What do the `@agent` and `@task` decorators do in a CrewAI crew.py module?

- How do you wire crew.py functions to entries in agents.yaml and tasks.yaml?

- How do you set the `{motion}` input in main.py and call `crew.kickoff`?

- How do you enable tracing with `crewai traces enable` and read the traces?

- How does CrewAI pass context between tasks in a multi-agent system?

Then this lecture is for you!

In this hands-on lecture, you'll complete your debate crew by setting up the two Python files, crew.py and main.py, then run it live. You'll start with crew.py, the module that defines your crew by bringing together your agents and tasks. You'll learn that the CrewAI scaffolding gives you functions decorated with `@agent` and `@task`, and that these functions simply associate each agent and task with its matching entry in the YAML files. You'll delete the default debate-class agents and paste in your debater and judge functions, then do the same for the three tasks (propose, oppose, decide), making sure the keys match the YAML exactly, since a typo produces an obscure CrewAI error.

Next you'll edit main.py, where the `run` function builds an `inputs` dictionary. You'll replace the defaults so that `motion` is captured from user input, then pass it into `debate.crew.kickoff(inputs=...)` so your placeholder variable populates every prompt. You'll run `crewai traces enable` to turn on tracing, then `crewai run` to kick everything off, entering a motion such as "there should be strict laws to regulate LLMs" and watching the propose, oppose, and decide tasks fire in sequence.

Finally, you'll inspect the results and the traces. You'll learn that CrewAI passes the full conversation history along, so the judge automatically receives the proposing and opposing arguments as context, and you'll confirm this by drilling into the decide task's LLM call and messages. You'll see the `output` folder with propose.md, oppose.md, and decide.md. By the end, you'll have run a complete multi-agent AI debate and know how every file in a CrewAI project fits together.

If you want to learn:

- What are the five steps to creating a CrewAI project every time?

- How do you add tools to agents with crewai out of the box?

- How do you set context and dependencies between tasks in a multi-agent crew?

- What is the difference between sequential and hierarchical agent orchestration?

- When should you put static information in YAML versus crew.py code?

- How does the art and science of agent building come together in CrewAI?

Then this lecture is for you!

In this hands-on lecture, you'll slow down the pace and learn the repeatable five-step recipe for building multi-agent AI systems with CrewAI, the process you'll use for every project this week. Step one is to create agents and a project with `crewai create crew my_project`, answer the prompts, and delete the inner .env. Step two is to fill in the two YAML files, agents.yaml and tasks.yaml, using placeholder variables in curly braces. Step three is to complete the crew.py module, where you create your agents and tasks and make sure every key exactly matches the YAML. Step four is editing main.py to set the inputs dictionary. Step five is `crewai run` (often preceded by `crewai traces enable`) to kick off your crew.

Along the way you'll deepen your understanding of CrewAI as an opinionated, batteries-included ai system framework. You'll learn that you can skip YAML entirely and define everything in code (for example `agent.llm=`), but the recommended practice is to keep static information and prompts in YAML for a clean separation, while wiring it together in crew.py. You'll also revisit the two agent orchestration modes: sequential (orchestration by code, tasks in defined order plus dependencies) and hierarchical (orchestration by a manager LLM), reinforcing how CrewAI relates to the autonomous agents work from the previous week.

Finally, you'll preview the two new features this day adds to your financial analyst project: tools, where you equip your analyst agent with capabilities that come out of the box with Crew, and context, where you force one task to run after another and pass its output forward. By the end, you'll have the five-step implementation recipe burned into memory and be ready to build a real financial researcher crew.

If you want to learn:

- How do you build a financial researcher crew with CrewAI?

- How do you define a researcher and analyst agent in agents.yaml for financial analysis with crewai?

- How do you add the Serper Dev tool for free web search to your agents?

- How do you use the `context` field to pass one task's output into another?

- How do you set up a SERPER_API_KEY in your .env file?

- How do you keep an analyst agent's research up to date with the current date?

Then this lecture is for you!

In this hands-on lecture, you'll start building a CrewAI financial researcher, a multi-agent ai project that digs into information about any company. Following the five-step recipe, you'll run `crewai create crew financial_researcher` inside your coursework folder, delete the inner .env, and pin Python on Apple silicon. Then you'll move to step two and write the two YAML files. In agents.yaml you'll define a senior financial analyst/researcher agent and an analyst agent that writes a strategy report, each with a role, a goal containing success criteria, a backstory, and an llm such as GPT-5 mini, plus the `{company}` and `{current_date}` placeholder variables.

Next you'll write tasks.yaml with one task per agent: a research task assigned to the researcher and an analysis task assigned to the analyst. You'll learn the importance of instructing the model that information must be up to date and relevant to now, so it searches for current data instead of relying on stale training knowledge. Crucially, you'll meet the new context field, which tells the analysis task to include the research task's output in its context, letting you make dependencies explicit. You'll learn the subtle default: without `context`, CrewAI implicitly passes all prior task outputs, but specifying context narrows it to exactly what you list, an example of the double-edged "framework voodoo" of an opinionated crewai framework.

Finally, you'll prepare a real web-search tool. You'll learn that CrewAI ships with many tools out of the box and choose the Serper Dev Tool for free Google search via serper.dev, sign up for 2,500 free queries, create an API key, and add `SERPER_API_KEY` to your .env. By the end, you'll have agents, tasks, and a search tool ready for your first true financial analysis with crewai project.

If you want to learn:

- How do you configure the crew.py module for your financial researcher?

- How do you add the Serper Dev tool to an agent in crew.py with `tools=[...]`?

- How do you import `SerperDevTool` from `crewai_tools`?

- How do you set the company and current_date inputs in main.py?

- How do you run a financial analysis with crewai and read the report output?

- How does CrewAI turn your YAML into the system prompt you see in the traces?

Then this lecture is for you!

In this hands-on lecture, you'll configure the crew.py module and finish building your CrewAI financial researcher, an ai agent implementation that researches and analyzes any company. Picking up at step three, you'll copy your two agents (researcher and analyst) and two tasks (research task and analysis task) into crew.py, where each function maps exactly to its entry in the YAML files. The key addition this time is tools: on the researcher agent you'll add `tools=[SerperDevTool()]`, then resolve the import error by adding `from crewai_tools import SerperDevTool` at the top of the module, equipping your agent with free web search just like you specify tools at the agent level in other frameworks.

Next you'll complete step four in main.py, changing the `run` function so it takes a `company` from user input and builds an `inputs` dictionary with both `company` and `current_date`, the two placeholder variables from your YAML. You'll call `financial_researcher.crew.kickoff(inputs=...)`, then move to step five: `crewai traces enable` followed by `crewai run`. You'll enter a company such as Apple, watch the research task fire off live Serper searches for current 2026 information, and see the analysis task write a comprehensive report into the `output` folder.

Finally, you'll spend quality time in the traces to understand CrewAI under the hood. You'll see the two agents, the search-the-internet-with-Serper tool calls and their inputs and outputs, and most importantly the actual system prompt CrewAI assembled from your YAML, with your goal turned into "Your personal goal is" and the prior task's research injected as context. By the end, you'll have a working financial analyst crew and a clear mental model of CrewAI's agent orchestration.

If you want to learn:

- What is the CrewAI stock picker project and what will it teach you?

- How do structured outputs with Pydantic work in CrewAI agents?

- How do you build a custom tool with the `@tool` decorator in a CrewAI workflow?

- What is the difference between sequential and hierarchical process when you orchestrate a crew?

- How do you turn on unified memory in CrewAI with `memory=True`?

- How do you set up CrewAI traces with `crewai login` and `app.crewai.com`?

Then this lecture is for you!

In this hands-on lecture, you'll kick off the stock picker project day, a CrewAI deep dive that layers several powerful features onto the five-step process you already know. You'll start with a recap of those five steps (`crewai create crew`, the YAML files, crew.py, main.py inputs, and `crewai run`) and where you choose `process.sequential` versus `process.hierarchical`. Then you'll preview the new techniques you'll use to define agents and create tasks: structured output with Pydantic, custom tools, the hierarchical process, and memory.

You'll learn that structured outputs in CrewAI work much like in OpenAI Agents SDK, using Pydantic objects (subclasses of BaseModel) to define a JSON schema, then specifying an output type at the task level. You'll also learn that, just as before, you can build your own custom tool with a decorator, this time CrewAI's `@tool` decorator, and you'll preview a push-notification tool. You'll explore the process hierarchical mode, where a manager LLM delegates tasks autonomously, giving you a more powerful alternative to the deterministic sequential workflow.

Finally, you'll meet CrewAI's unified memory, a beautifully simple construct where setting `memory=True` gives your crewai agents tools to read and write memory automatically, the blessing and curse of an abstracted framework. You'll also learn to set up tracing properly with three steps: sign up at app.crewai.com, run `crewai login` to connect your CLI, and activate tracing via code (`tracing=True`), the `CREWAI_TRACING_ENABLED` env variable, or `crewai traces enable`. By the end, you'll be ready to build a stock picker with structured outputs, custom tools, memory, and multi-agent orchestration.

If you want to learn:

- How do you build the CrewAI stock picker crew step by step?

- How do you define agents for a trending company finder, financial researcher, and stock picker?

- How do you create tasks that produce JSON output files in a CrewAI workflow?

- How do you add Pydantic classes for structured output in crew.py?

- How do you use `output_pydantic=` on a task to get structured results?

- How do you use the `context` field to orchestrate task dependencies in a multi-agent system?

Then this lecture is for you!

In this hands-on lecture, you'll build the stock picker crew step by step, following the CrewAI five-step process. You'll run `crewai create crew stock_picker`, delete the inner .env, pin Python, then write your YAML files. In agents.yaml you'll define three agents: a trending company finder (a news analyst that searches the latest news to find two or three trending companies), a financial researcher (which deeply analyzes each company), and a stock picker (which selects the best one for investment, notifies the user, and writes a detailed report), each using a placeholder for the sector and current date.

Next you'll write tasks.yaml with three tasks. The find-trending-companies task outputs `trending_companies.json`, the research task analyzes each company and outputs JSON, and the pick-best-company task sends a push notification and writes a markdown decision. You'll use the context field to explicitly orchestrate dependencies between tasks, learning the subtle point that being explicit actually narrows the context (focusing on just the prior task) rather than including all previous outputs by default.

Then comes step three, crew.py, where the real power appears. You'll import `BaseModel` and `field` from pydantic and the SerperDevTool, then add Pydantic classes, TrendingCompany, TrendingCompanyList, TrendingCompanyResearch, and TrendingCompanyResearchList, using the `description` field so the LLM knows how to populate each attribute. You'll map your three agents and three tasks to the YAML, give the finder and researcher the Serper tool, reference a new `send_push_notification` tool, and add `output_pydantic=` to the relevant tasks so they emit structured output as JSON. By the end, you'll have the entire stock picker wired up and ready to add its custom push tool.

If you want to learn:

- How do you add structured outputs and custom tools to your CrewAI crew?

- How do you write a custom push-notification tool with the `@tool` decorator in Python?

- How do you import a custom tool into crew.py with a relative import?

- How do you turn on unified memory in a CrewAI crew with `memory=True`?

- How do you switch from `process.sequential` to `process.hierarchical` with a manager agent?

- How does CrewAI inject memories and structured output into the prompt behind the scenes?

Then this lecture is for you!

In this hands-on lecture, you'll finish the stock picker by adding a custom tool, structured outputs, memory, and a hierarchical process. You'll start by writing your own tool: inside the `tools` folder you'll create `push_tool.py` and use CrewAI's modern `@tool` decorator (`@tool("send_push_notification")`) on a typed function with a docstring, sending a good old Pushover request.post and returning the result. You'll then import it into crew.py with a relative import (`from .tools.push_tool import send_push_notification`) and give it to the stock picker agent, while the finder and researcher keep the built-in Serper Dev tool. You'll recap how structured output works: define a Pydantic object and set `output_pydantic=` on the task, and it just works, producing JSON files in the `output` folder.

Next you'll run the crew with `crewai run`, watch it search the internet, pick a company like Broadcom, and fire a real push notification to your phone. You'll inspect the `output` folder's decision.md and JSON files, confirming the Pydantic schema shaped the results, and view the run in the traces at app.crewai.com.

Finally, you'll add two more features. You'll enable CrewAI's unified memory by setting `memory=True` on the crew and agents so it won't pick the same stock twice. Then you'll orchestrate the crew differently by adding a fourth manager agent in agents.yaml, creating it in crew.py with `allow_delegation=True`, passing `manager_agent=manager`, and switching `process.sequential` to `process.hierarchical`. You'll re-run, see the manager delegate to the three workers, and discover in the traces how CrewAI injects "memories from past conversations" (agentic RAG retrieval) into the prompt. By the end, you'll have a complete multi-agent stock picker, while learning Ed's caution to always start with one agent, one task, and never trade on an LLM's unverified output.

If you want to learn:

- How do you build a coding agent developer crew with CrewAI?

- Why did CrewAI remove `allow_code_execution=True` and how do you replace it?

- How do you install Docker Desktop to run AI coding agents safely?

- What is a Docker sandbox and why run Python in a container?

- What are the prerequisites for building a crewai coding agent?

- How does a docker sandbox isolate code execution from your computer?

Then this lecture is for you!

In this hands-on lecture, you'll begin building the developer agent, a CrewAI coding agent that can write and run Python. You'll start with the now-familiar five-step refresher, then learn an important change: in earlier versions of Crew you could simply set `allow_code_execution=True` (with `code_execution_mode="safe"`) to give an agent the power to run code, but CrewAI has removed this functionality. You'll learn the likely reasons, CrewAI now partners with paid cloud sandbox vendors via built-in tools, and giving every user one-flag local code execution was deemed too risky. With great power comes great responsibility, so you'll instead build your own tools to execute code carefully and safely.

Next you'll learn why you'll run everything inside Docker. You'll install Docker Desktop from docker.com if you don't already have it, picking the right platform and following the prompts (Windows users choose the WSL backend). You'll learn that Docker gives you a container, a little computer inside your computer, an isolated sandbox that protects the rest of your machine while your agent runs Python. You'll open Docker Desktop, see the Containers and Images views, and confirm Docker is running, no sign-in required, just the install.

Finally, you'll understand the shape of this two-day project: start simple today with a single agent that runs Python in a docker sandbox, then extend it tomorrow into a full engineering team. You'll see that this is the disciplined way to build, beginning small and expanding. By the end of this lecture, you'll have Docker installed, understand exactly why a docker sandbox matters for ai coding agents, and be ready to scaffold the Coda coding project in CrewAI.

If you want to learn:

- How do you create the Coda coding project in CrewAI?

- How do you set up a single agent and single task for a crewai coding agent?

- How do you check Docker with `docker ps` before building a coding agent?

- How do you build custom sandbox tools to list, read, and write files in Python?

- Why must code execution run in a docker sandbox rather than directly on your machine?

- How do you use the `@tool` decorator to create tools for AI coding agents?

Then this lecture is for you!

In this hands-on lecture, you'll create the Coda coding project, a crewai coding agent built the disciplined way with just one agent and one task. You'll run `crewai create crew coda` in your coursework folder, delete the inner .env, pin Python, and run `docker ps` to confirm Docker is working with no containers yet. Following step two, you'll write minimal YAML files: an agents.yaml defining a single Python developer agent that uses its sandbox tools to write a Python script in the sandbox directory and run it, and a tasks.yaml with one coding task whose expected output is a `solution.md` summary. This time you're following the golden rule of starting with one agent, one task.

Next you'll set up crew.py, mapping the single `@agent` and `@task` to the YAML. You'll confirm that the old `allow_code_execution=True` flag no longer does anything in CrewAI, which means you must write your own tools. In the `tools` folder you'll create `sandbox_tools.py` and walk through code that first locates (and creates) a `sandbox` directory inside the Coda project, then defines four tools using CrewAI's `@tool` decorator.

Finally, you'll learn three of those four tools in detail: `list_sandbox_files` lists the file names in the sandbox, `read_sandbox_file` reads a named file's contents, and `write_sandbox_file` writes (or overwrites) a file, each with a clear docstring so the coding agent knows how to call it. You'll understand that reading and writing files within one controlled directory is safe, but actually executing Python is riskier and must run in a docker sandbox. By the end, you'll have a Coda project with custom file tools ready, and you'll be set up to add the all-important code execution tool that runs Python safely in Docker.

If you want to learn:

- How do you run Python safely in a Docker sandbox tool with CrewAI?

- How does the `run_sandbox_python` tool use `docker run` to execute code?

- How do you mount the sandbox directory into an ephemeral docker container?

- How do you import sandbox tools into crew.py and set the assignment in main.py?

- Why should the coding agent's assignment be set by you, not from user input?

- How do you verify your crewai coding agent wrote and ran a python script in the traces?

Then this lecture is for you!

In this hands-on lecture, you'll complete your Coda coding agent by building the tool that matters most: `run_sandbox_python`, which safely runs a python script inside an isolated Docker sandbox. You'll walk through the tool's docstring and logic, learning that it shells out to a `docker run --rm` command that mounts the local sandbox directory to a `/workspace` directory inside a short-lived Docker container based on a Python 3.13 image, runs `python <filename>` with a 60-second timeout, and returns whatever the script printed to standard output. Because the container only has access to the sandbox folder and the container is deleted after each run, your code execution stays fully sandboxed and isolated from the rest of your computer. You'll then collect all four tools into a `sandbox_tools` list.

Next you'll wire everything together. You'll import the sandbox tools into crew.py so the yellow squiggle disappears, then edit main.py to set the `assignment` input. You'll learn an important security principle: because the agent writes and runs code, you always hard-code the assignment yourself rather than exposing it to a user interface or reading it from the web, so the coding agent never executes something you didn't specify.

Finally, you'll run `crewai run` with an assignment to compute one million terms of the Leibniz series for pi. You'll watch the agent create a `sandbox` directory, write `leibniz.py`, execute it in Docker, and report a result like 3.14159. You'll inspect the sandbox file, the `solution.md` output, and the traces to confirm it really used `list_sandbox_files`, `write_sandbox_file`, and `run_sandbox_python`. By the end, you'll have built your own miniature Claude Code, an ai coding agent that writes and runs Python in a secure docker sandbox, ready to scale into a full engineering team tomorrow.

If you want to learn:

- How do you build an engineering team multi-agent crew with CrewAI?

- How do you configure a team of ai agents for software development?

- How do you write strong agents.yaml prompts for an engineering lead and engineers?

- How do you give a CrewAI agent MCP access to Context7 for the latest APIs?

- Why does an engineering lead design a system without writing any code?

- How do you build software teams of AI agents that collaborate with CrewAI?

Then this lecture is for you!

In this hands-on lecture, you'll begin the engineering team project, the finale of Week 3, where a team of ai agents collaborates to build a real piece of software using CrewAI, the leading multi-agent platform. You'll learn the mindset: you're building your own opinionated Claude Code, where you decide how your coding agents solve problems instead of using a pre-built tool. After running `crewai create crew engineering_team`, deleting the inner .env, and pinning Python, you'll set up the agents.yaml that defines four roles: an engineering lead, a backend engineer, a frontend engineer, and a test engineer.

Next you'll learn what makes a great agent prompt by studying each role. The engineering lead is told to design the system, describe modules, classes, functions and signatures, but explicitly not write any code, because these agents love to over-eagerly generate code and solve the whole problem. You'll learn to configure important guidance: all engineers have a sandbox to write, execute and test code, everything runs in a UV project with Gradio installed, and the lead should use its Context7 MCP tools to check the latest APIs and include explicit Gradio 6 guidance (since Gradio 6 came out after the model's knowledge cutoff). You'll see how the lead is assigned a strong frontier model like GPT-5.5.

Finally, you'll define the backend, frontend, and test engineers, each with sandbox tools and clear constraints: the backend writes pure Python modules with no third-party packages and no UI, the frontend is a Gradio expert who builds a polished UI and writes a validate script. You'll learn that great prompts come from iterating repeatedly based on agent performance. By the end, you'll have all four agents defined and understand how to automate real software teams of AI agents with CrewAI.

If you want to learn:

- How do you define tasks for your engineering team crew in CrewAI?

- How do you write one task per agent for a team of ai agents?

- How do you pass design and code context between tasks in a multi-agent crew?

- How do you give agents MCP access to Context7 in crew.py?

- How do you patch a CrewAI MCP bug with hyphenated tool names?

- How do you configure agents.yaml and tasks.yaml for software teams of AI agents?

Then this lecture is for you!

In this hands-on lecture, you'll define the tasks for your CrewAI engineering team, the step CrewAI says matters even more than defining the agents. You'll write tasks.yaml with the simplest structure, one task per agent: a design task for the engineering lead, a code task for the backend engineer, a frontend task for the frontend engineer, and a test task for the test engineer. You'll learn how outputs and context flow through the crew: the design task writes a design file straight into the sandbox so others can read it, the code task receives the design in its context, and you'll add the design task as context to the frontend and test tasks too, so every agent sees the full picture.

You'll study each task's clear wording, the design task takes business requirements via a placeholder and outputs markdown without writing code, the code task implements the design in Python, the frontend task writes a Gradio app in `app.py` plus a `validate.py` script, and the test task writes unit tests for the backend without breaking the Gradio app. You'll see how repetition between system and user prompts and crisp instructions produce reliable multi-agent behaviour, and how iterating on these prompts is the main way to improve results.

Then you'll move to crew.py, where you map the four agents and tasks to the YAML and add something new: MCP. You'll learn how easy CrewAI makes it, just pass `mcps=[...]` with a remote MCP server like Context7 to equip the engineering lead and frontend engineer with tools to look up the latest APIs. You'll also patch a real CrewAI bug where hyphenated tool names break MCP resolution, by creating `patch.py` and importing it for its side effect in main.py. By the end, you'll have tasks, context, and MCP fully configured for your team of ai agents.

If you want to learn:

- How do you equip engineering agents with sandbox tools in CrewAI?

- How do you run code in a UV project inside a Docker container with `uv run`?

- How do you reset the sandbox and run `uv init` and `uv add gradio` each run?

- How do you import sandbox tools into crew.py for your team of ai agents?

- How do you set the business requirements input in main.py?

- How do you fix CrewAI's tool caching bug so file listings update correctly?

Then this lecture is for you!

In this hands-on lecture, you'll equip your CrewAI engineering agents with upgraded sandbox tools so a real team of ai agents can write, test, and run a working application. You'll create `sandbox_tools.py` and walk through it: the usual housekeeping that creates a sandbox directory, plus a new `reset_sandbox` helper (not a tool) that wipes the sandbox, runs `uv init` to set up a fresh UV project, and runs `uv add gradio`, giving the agents a clean Python 3.13 project with Gradio installed every run. Three of the four tools, list, read, and write sandbox files, are identical to the previous day's coding agent.

The key change is the execution tool. Instead of running plain `python <file>`, it now runs `uv run <file>` so code executes inside the configured UV project. Because that happens inside the container, you'll switch the Docker base image from plain Python 3.13 to Astral's official image that ships with uv preinstalled, so `uv run` just works. You'll also bump the timeout from 60 to 300 seconds for this more generic tool set, then import these tools into crew.py so all the coder agents (but not the design-only engineering lead) get sandbox access, and add `tracing=True`.

Then you'll build main.py: import `reset_sandbox`, call it before kickoff, and set the business requirements input, a real account management system for a trading simulation platform that you'll actually reuse in Week 6. Finally, you'll fix a sneaky CrewAI bug: its clever tool-result caching returns the same output when a tool is called twice with identical arguments, which broke `list_sandbox_files`. You'll override it by setting each tool's cache function to always return false. By the end, your multi-agent engineering crew will be fully tooled and ready to run.

If you want to learn:

- How do you use multiple AI models (GPT, Gemini, Claude) in one CrewAI crew?

- How do you assign a different llm to each agent in agents.yaml?

- How do you route models through OpenRouter to mix and match providers?

- How do you run an engineering team crew with `crewai run` to build a real app?

- How does a team of ai agents collaborate to build a Gradio trading simulator?

- How do you compare crews of different llm combinations in the CrewAI traces?

Then this lecture is for you!

In this hands-on lecture, you'll unleash your CrewAI engineering team and see a team of ai agents collaborate to build a complete application using multiple AI models at once. First you'll configure each agent with a different llm in agents.yaml: GPT-5.5 for the engineering lead, Gemini 3.1 Pro Preview for the backend engineer, Anthropic's Claude Opus 4.7 for the frontend engineer, and GPT-5.5 again for the test engineer, several routed through OpenRouter so you can mix and match providers and set precise spending limits on your API keys. You'll learn how flexible building your own Claude Code harness is, you can swap any model at any step, including free or cheap models like DeepSeek if you're willing to iterate more.

Then you'll run `crewai run` and watch the crew work: the sandbox directory appears, the engineering lead uses its Context7 MCP tool to look up the Gradio API, then the backend, frontend, and test engineers build, run, and fix code in their Docker sandbox. You'll `uv run app.py` to launch the finished Gradio app, a trading simulation account manager that creates accounts, deposits cash, buys and sells shares, tracks profit and loss, and correctly blocks insufficient-funds and insufficient-shares trades, built in minutes for around $4.

Finally, you'll dig into the traces to confirm the multi-agent orchestration worked: the engineering lead's MCP calls, the test engineer writing tests, hitting an error, fixing it, and passing, a textbook example of an LLM with tools in a loop. You'll verify in the raw data that GPT-5.5, Gemini 3.1, and Claude Opus 4.7 each ran, then compare three crews (mixed, GPT+Claude, all-GPT-5.5) and judge the winner. By the end, you'll know how to automate real software teams of AI agents with CrewAI, and you'll have wrapped up Week 3 at the 50% mark, ready for LangGraph.

If you want to learn:

- What is LangChain and how does the LangChain ecosystem fit together for building AI agents?

- What is the difference between LangChain the company, the open source framework, LangChain Core, LangGraph, and LangSmith?

- What are the four abstraction layers for building AI agents with LangChain and when do you use each?

- How does the pre-built create_agent function relate to LangGraph and a React agent loop with tool calling?

- What are Deep Agents and how is this high-level harness different from a low-level agent framework?

- How do you decide between LangChain agents, LangGraph, and other AI agents using Python frameworks?

Then this lecture is for you!

In this hands-on lecture, you'll get a clear, opinionated tour of the entire LangChain and LangGraph ecosystem so you can confidently start building AI agents with LangChain in Python. Instructor Ed Donner untangles the confusing terminology around LangChain the company, the open source framework, and the broader integration ecosystem that includes the LangChain Core library, LangGraph, LangSmith observability, and LangSmith Deployment (formerly LangGraph Platform). You'll trace the history from Harrison Chase's 2022 release through LCEL, the 1.0 breaking change, and the recent pivot to an agent engineering platform.

The heart of this tutorial is the four-layer mental model for working with AI agents with LangChain. Layer one is LangChain Core, the building blocks that wrap LLM calls. Layer two is LangGraph, the dependency-graph orchestration framework for stateful, repeatable workflows. Layer three is create_agent, the convenient pre-built wizard that builds a LangGraph graph under the hood to run an LLM in a loop with tools, much like a React agent. Layer four is Deep Agents, an all-in, batteries-included harness with a file system, sub-agents, and to-do lists for long-running goals.

You'll understand exactly why create_agent is built in LangChain yet produces a LangGraph graph that calls LangChain Core components, and why Deep Agents sits at the top. This is the conceptual foundation that makes every later lab click. By the end, you'll know precisely which layer to reach for when you create an AI agent, and you'll be ready to learn how to build AI systems with LangChain tools and tool calling, starting with LangChain Core itself.

If you want to learn:

- How do you call an LLM in Python using LangChain Core with the ChatOpenAI class?

- What is the difference between invoke and stream when calling models in LangChain?

- How do you use ChatOpenAI to talk to any OpenAI-compatible API like OpenRouter with a base URL and API key?

- How do typed message objects (SystemMessage, HumanMessage, AIMessage) compare to lists of dicts in LangChain?

- How does the @tool decorator work and how do you inspect name, description, args, and invoke a LangChain tool?

- How do you produce structured Pydantic outputs with with_structured_output in LangChain Core?

Then this lecture is for you!

In this hands-on lecture, you'll roll up your sleeves in Cursor and write your first real code with LangChain Core, the building-blocks layer of the LangChain ecosystem. Ed Donner introduces the five core techniques you need for building AI agents with LangChain: model wrappers like ChatOpenAI and ChatAnthropic, typed messages, the @tool decorator, the LLM loop, and structured outputs. You'll import ChatOpenAI from langchain_openai, create a model with gpt-5-mini, and make your very first call using invoke, the universal method that runs anything in LangChain.

You'll then swap invoke for stream to stream poem tokens back in real time, and point ChatOpenAI at OpenRouter by passing a model name, a base URL, and your API key so you can call Claude Haiku through the same integration. This tutorial shows how LangChain replaces messy lists of dicts with disciplined SystemMessage, HumanMessage, and AIMessage objects, while still accepting the classic OpenAI format.

The lecture then introduces tool calling. You'll decorate a get_share_price function with @tool, add a docstring and type hints, and inspect its name, description, args JSON schema, and call it with invoke. This is the pre-built framework convenience that makes AI agents using Python far cleaner. By the end, you'll be fluent in the LangChain Core building blocks, ready to bind these LangChain tools to an LLM and learn how to build AI agents that loop, paving the way for a true React agent-style workflow.

If you want to learn:

- How do you bind LangChain tools to an LLM using bind_tools in LangChain Core?

- Why does invoking an LLM with tools return a tool-call request instead of running the tool?

- How do you write a simple agent loop in Python that handles tool calling step by step?

- How do you build a minimal AI agent that is an LLM in a loop with tools to achieve a goal?

- How do you generate structured Pydantic outputs with with_structured_output in LangChain?

- Why might you choose lower-level LangChain Core over a pre-built React agent framework?

Then this lecture is for you!

In this hands-on lecture, you'll close out the LangChain Core layer by wiring an LLM up to real tool calling, the foundation of building AI agents with LangChain. Ed Donner shows how to take the ChatOpenAI model and call bind_tools, passing a list of @tool-decorated functions like get_share_price. This returns a new llm_with_tools object that, when you call invoke, knows it can use those LangChain tools.

A key lesson here is that invoking an LLM equipped with tools does not automatically run the tool. Just like week one, the model simply responds that it wants to call a tool. You'll write a hands-on, deliberately janky if-statement loop that calls the LLM, iterates through tool calls, runs get_share_price via invoke, and then calls the LLM a second time with the result. The outcome is a working, if simple, AI agent: an LLM in a loop with tools to achieve a goal, built entirely from the LangChain Core building blocks. This shows exactly why the higher framework layers exist and what they automate for you.

You'll also revisit structured outputs, defining a Pydantic BaseModel and calling with_structured_output so the model returns a clean typed object with fields like name, ticker, and founded year. By the end, you'll understand the manual mechanics of tool calling in Python, appreciate why LangGraph and the pre-built create_agent React agent layers add discipline, and be fully prepared to learn how to build AI agents using orchestration. This is AI agents using the lowest level of LangChain, giving you maximum control before you create an AI agent the easy way.

If you want to learn:

- What is LangGraph and how does it orchestrate agentic AI workflows as a dependency graph?

- What are nodes, edges, state, and conditional edges in LangGraph?

- Why is LangGraph state immutable and what does that mean for stateful AI agents?

- What is a reducer in LangGraph and how does it merge parallel state updates?

- What are the five steps to define and compile a LangGraph graph before you run it with invoke?

- How do LangChain and LangGraph work together to make agentic workflows repeatable and durable?

Then this lecture is for you!

In this hands-on lecture, you'll move up to layer two of the stack and learn how LangGraph orchestrates agent workflows for building AI agents that are reliable and repeatable. Ed Donner explains why this framework matters: the hacky for-loops and if-statements from LangChain Core are tamed by LangGraph, which puts engineering discipline around multiple LLM calls. LangGraph is a dependency-graph system for stateful, long-running agents, and it is the orchestration backbone that enterprises love for its durability.

You'll master the core vocabulary of agents with LangGraph: the graph that represents the whole workflow, the state snapshot that carries information, the nodes that each do a unit of work (usually a node is just a Python function), and the edges that connect them, including conditional edges drawn as dotted lines. Ed walks through the five steps you repeat again and again: define a state class, start the graph builder, add nodes, add edges, and compile the graph, after which running it is a one-line invoke call.

The lecture then tackles the two ideas that trip people up. First, why state is immutable: a node never mutates the incoming object but returns a brand-new state, illustrated with a counting node. Second, the reducer, a special function like the off-the-shelf ones LangGraph provides, that merges a new state into the existing one so parallel nodes never overwrite each other, much like collaborative edits in Google Docs. By the end, you'll deeply understand the generative AI orchestration model behind LangGraph, ready to build your first graph and see workflows with LangGraph come to life in code.

If you want to learn:

- How do you build your first LangGraph with nodes, edges, and state in Python?

- How do you define a LangGraph state with TypedDict, Annotated, and the add_messages reducer?

- How do you use StateGraph, add_node, add_edge, START, END, and compile to assemble a graph?

- How do you add a tool node and a conditional edge with tools_condition to build a tool loop?

- How do you wire ChatOpenAI, bind_tools, and a chatbot node into an agentic workflow?

- How do you extend a LangGraph with a second node, like a translator, for richer workflows with LangGraph?

Then this lecture is for you!

In this hands-on lecture, you'll build your very first LangGraph from scratch in Cursor, turning the theory of nodes, edges, and state into running code. Ed Donner starts by defining a state object as a TypedDict with a messages field, using Annotated to attach the add_messages reducer imported from langgraph.graph.message. You'll then create a deliberately silly node that ignores the state and returns a nonsense sentence, proving that LangGraph is framework-agnostic and has nothing inherently to do with LLMs.

From there you'll follow the five steps for real: start the StateGraph builder, add your node with add_node, connect START to your node to END with add_edge, compile the graph, and draw the diagram before running it with invoke. You'll then upgrade the node to call ChatOpenAI via llm.invoke, creating a true chatbot graph that produces real model responses, all built on the LangChain Core components from day one.

The lecture then layers in tools to create a proper agentic AI loop. You'll add a built-in GoogleSerperRun search tool plus a homemade send_push_notification tool, bind them with bind_tools, and introduce a special tool node plus a conditional edge using tools_condition. Seeing the diagram makes the tool loop click instantly. Finally you'll extend the graph with a translator node and five edges to translate responses into Spanish. By the end, you'll be able to design and run multi-node workflows with LangGraph, cleanly describing agents and workflows as graphs instead of spaghetti code for building ai agents.

If you want to learn:

- How does the LangGraph tool loop work with a tool node, tools_condition, and conditional edges?

- How do you route an agent workflow so an LLM can call tools and feed results back?

- What is a superstep in LangGraph and how does it relate to parallel nodes and reducers?

- How do you add observability to LangChain and LangGraph with LangSmith tracing?

- What is a checkpointer, and how do MemorySaver and SqliteSaver enable stateful AI memory?

- How does thread_id keep separate conversation state for many users in agents with LangGraph?

Then this lecture is for you!

In this hands-on lecture, you'll deepen your LangGraph mastery by revisiting the tool loop and then unlocking two of the most powerful features for building agentic systems: observability and durable memory. Ed Donner recaps how a tool node runs tools, how bind_tools equips a model, and how the tools_condition conditional edge routes the workflow so the chatbot node can call tools and loop back with the results before reaching END. This is the repeatable, resilient pattern at the heart of agentic workflows.

Next you'll add LangSmith, the free observability platform in the LangChain ecosystem. You'll sign up at smith.langchain.com, create a project, generate an API key, and paste the four LANGSMITH environment variables into your .env so every model call and tool call is traced automatically, complete with tokens, latency, and cost. No extra code is required, making it a fantastic way to debug agents and workflows visually.

The lecture then explains the superstep, the major unit of execution in LangGraph: nodes that run in parallel belong to one superstep, sequential nodes to separate supersteps, and one graph.invoke is a full application turn much like runner.run. You'll see how reducers merge state within a superstep, while the checkpointer manages state between supersteps. Ed introduces MemorySaver for in-memory checkpoints and SqliteSaver for persistent storage, both keyed off a thread_id so each conversation thread has its own stateful memory. By the end, you'll understand how LangGraph delivers reproducible, observable, stateful AI workflows ready to wire into code.

If you want to learn:

- How do you add memory to a LangGraph with a MemorySaver checkpointer and a thread_id config?

- How do you persist stateful conversation memory across runs using SqliteSaver and a memory.db file?

- How do you inspect graph state with get_state and get_state_history in LangGraph?

- How do you time-travel and replay a LangGraph from an earlier checkpoint ID?

- How do you wire up LangSmith tracing and read traces, tokens, latency, and cost?

- How do you wrap a LangGraph workflow in a Gradio chat UI for a stateful AI agent?

Then this lecture is for you!

In this hands-on lecture, you'll finish the LangGraph crash course by making your agent workflow truly stateful with checkpointers, then explore the time-travel and observability superpowers that make LangGraph so loved in the enterprise. Ed Donner first shows what happens without memory: each graph.invoke starts fresh, so the agent forgets your name. Then you'll add a MemorySaver at compile time and pass a config with a thread_id like "conversation one", and suddenly the agent remembers across turns, all without changing your nodes at all.

You'll go further by swapping in a SqliteSaver context manager that writes checkpoints to a memory.db SQLite file, so memory survives a process restart. The lecture explains how this works: because you use a checkpointer, LangGraph preserves the state passed into each node between calls to invoke, giving you memory for free in your agentic workflows. You'll then call get_state and get_state_history to inspect saved messages and the eight checkpoints behind two turns, including the minus-one pre-step.

Most impressively, you'll rewind time by building a replay config with an earlier checkpoint ID and resuming the conversation from that point, a capability that shines in complex workflows with langgraph. Ed also tours the LangSmith traces, showing input and output tokens, latency, and cost, and wraps everything in a simple Gradio chat UI with a hard-coded thread_id. By the end, you'll command memory, replay, observability, and a UI for building ai agents with LangChain and LangGraph, ready for the easier create_agent layer next.

If you want to learn:

- What is create_agent in LangChain and how does this agent layer simplify building AI agents?

- How does create_agent act as a wizard that builds a LangGraph agent loop behind the scenes?

- What features do you get out of the box with create_agent, like memory, structured outputs, and MCP?

- What is middleware in LangChain create_agent and how does it extend the agent loop?

- How do you set up Node and Playwright to give an AI agent browser integration?

- How does create_agent compare to other agent types and LangChain agents frameworks?

Then this lecture is for you!

In this hands-on lecture, you'll meet create_agent, the agent layer of LangChain and the architecture that feels most like a true AI agent framework, much like OpenAI Agents SDK or CrewAI. Ed Donner introduces create_agent as a wizard: a single function where you specify a model, tools, and a system prompt, and it builds a complete agent loop for you. Behind the scenes it compiles the very same LangGraph graph you built by hand on day two, but you never have to worry about it, so you operate at a higher level while keeping all of LangGraph's power and resiliency.

This is the perfect trade-off for building AI agents with LangChain: you give up some granular control in exchange for dramatic simplicity, and you get batteries-included features along for the ride. You'll preview the zoo of capabilities coming up: a simple model-and-prompt agent, the async ainvoke method alongside invoke, tools via the @tool decorator passed straight into create_agent, memory, structured outputs, middleware hooks, and even a touch of MCP, the hot topic of web search and integration.

The lecture also sets up the lab environment. You'll install Node, the JavaScript runtime, using winget on Windows or brew on a Mac, and prepare to use Playwright, Microsoft's browser-automation software, so an agent you create can commandeer Chrome and feel genuinely autonomous. By the end, you'll understand why create_agent is Ed's favorite point on the stack for creating AI agents with LangChain, and you'll be ready to build a simple agent, then build agents with LangChain that browse the web. This is building AI at its most convenient, with an API key and a few lines of Python.

If you want to learn:

- How do you build a simple AI agent with create_agent in LangChain?

- How do you pass a provider:model string and system prompt into create_agent?

- What is the difference between invoke and ainvoke when running a LangChain agent?

- How do you give a create_agent agent tools using the @tool decorator?

- How do you visualize the underlying LangGraph graph with get_graph and draw?

- How does create_agent make building AI agents with LangChain as easy as OpenAI Agents SDK?

Then this lecture is for you!

In this hands-on lecture, you'll build a simple agent in Cursor and marvel at how easy building AI agents with LangChain becomes at the create_agent layer. Ed Donner imports create_agent from langchain.agents and calls it with just a model string in provider:model form, like openai:gpt-5-mini, plus a system prompt. The wizard reads the provider and selects the right wrapper, such as ChatOpenAI, sparing you boilerplate. You then run the agent with invoke, asking it to explain the Model Context Protocol, and it just works, your first create_agent AI agent in only a couple of lines of Python.

You'll also meet ainvoke, the async sister of invoke that you await, perfect for the IO-bound nature of agents. Then you'll add tools: defining fake get_weather and get_population functions with the @tool decorator and passing them straight into create_agent, exactly as you would pass function tools in OpenAI Agents SDK. The agent uses both tools to report the weather and population of Rome, proving tool calling works seamlessly through this framework integration.

The most satisfying moment comes when you call get_graph and draw on the agent object, revealing the exact LangGraph graph that create_agent built under the hood, complete with model node, conditional edges, and tools. Thanks to day two, you understand precisely what this architecture means. By the end, you'll be able to create an AI agent, equip it with tools, and see the LangGraph that powers it, ready to build agents with LangChain that have memory, structured outputs, and browser automation. This is using LangChain to build agents the convenient way.

If you want to learn:

- How do you add memory to a create_agent AI agent with a checkpointer in LangChain?

- How do you use MemorySaver and a thread_id config to give a LangChain agent conversation memory?

- How do you get structured Pydantic outputs from a create_agent agent?

- What is middleware in LangChain create_agent and how do you hook into the agent loop?

- How do you write a wrap_tool_call middleware to intercept every tool call?

- What built-in middleware does create_agent provide, like summarization and human-in-the-loop?

Then this lecture is for you!

In this hands-on lecture, you'll supercharge a create_agent agent with memory, structured outputs, and middleware, three features that make building AI agents with LangChain both powerful and easy. Ed Donner starts with memory: you call create_agent with a model, tools, and a checkpointer set to MemorySaver, then pass a config with a thread_id. Thanks to day two you know exactly what this does behind the scenes, and now it takes just one line. The agent remembers a planned trip to London across multiple messages, demonstrating effortless conversational memory.

Next you'll add structured outputs, defining a Pydantic CityReport class with city, weather, and population fields and passing it as the response format to create_agent, just like OpenAI Agents SDK and CrewAI. The agent uses its tools and returns a clean typed object you read via the structured_response field. Equipping an LLM with tools and structured outputs is a cinch at this layer of the framework.

The highlight is middleware, a clean way to add hooks into the agent loop before a model is called, after it answers, or around each tool call. You'll use the wrap_tool_call decorator to write custom middleware that prints every tool invocation, then pass it into create_agent and watch it fire four times across two cities. Ed also tours the batteries-included middleware: summarization middleware to shorten context, PII redaction, and human-in-the-loop middleware to pause for approval. By the end, you'll know how to build agents with LangChain that have memory, return structured data, and use middleware, advancing your architecture for creating AI agents with LangChain before adding Playwright browser integration.

If you want to learn:

- How do you give an AI agent a browser using Playwright and Node?

- How do you install Node and verify npx for browser automation in Python projects?

- How do you run npx Playwright to screenshot a web page like Hacker News in Chrome?

- Why must you restart Cursor after installing Node for the shell to pick it up?

- How does browser automation set the stage for building AI agents with LangChain that browse the web?

- How does Playwright integration make a LangChain agent feel truly autonomous?

Then this lecture is for you!

In this hands-on lecture, you'll equip your toolkit to give an AI agent the ability to launch and drive a real browser, a thrilling step toward building AI agents with LangChain that feel genuinely autonomous. Ed Donner walks through installing Node, the JavaScript runtime, checking node --version for at least version 22, and using winget on Windows or brew on a Mac if it is missing. He flags a common gotcha: if you install Node after launching Cursor, the underlying shell will not see it, so you must quit and reopen Cursor and rerun every cell from the top, with a computer restart as a last resort on stubborn PCs.

With Node and npx ready, you'll run a Playwright command directly: npx -y playwright screenshot pointed at news.ycombinator.com, told to use the Chrome browser, writing the result to playwright-check.png. Playwright is Microsoft's browser-automation software, and npx is the JavaScript equivalent of uvx, letting you run a published tool instantly. When it runs, a browser window pops up, navigates to Hacker News, captures a screenshot, and displays it in the notebook, proving you can automate a browser, navigate to a page, and show the results.

Crucially, this step has nothing to do with LLMs, LangChain, or LangGraph yet, it is pure Playwright and Node, the foundation you need before handing browser control to an agent. By the end, you'll have a working browser-automation pipeline and the architecture in place to build agents with LangChain that perform web search and research. This sets up the next lecture, where you'll wrap Playwright in an MCP server and let a create_agent AI agent commandeer the browser autonomously, a perfect example of building AI that acts in the real world.

If you want to learn:

- How do you use MCP with LangChain and Playwright to give an AI agent browser tools?

- What is the Playwright MCP server and what 23 browser tools does it provide?

- How do you connect to an MCP server with the MultiServerMCPClient in LangChain?

- How do you pass MCP tools into create_agent and run the agent with ainvoke?

- Why is using an MCP server easier than writing 23 browser tools with the @tool decorator?

- How do you debug an agent's browsing behavior in LangSmith traces?

Then this lecture is for you!

In this hands-on lecture, you'll deliver the punchline of the day by combining MCP, Playwright, and create_agent to build an AI agent that autonomously commandeers a browser. Ed Donner explains the power of MCP: rather than writing 23 separate Playwright tools with the @tool decorator, each needing a description and parameter schema, Microsoft has packaged everything into a Playwright MCP server you can use immediately. This is building AI agents with LangChain at its most convenient, leaning on a ready-made integration.

You'll use the LangChain MultiServerMCPClient class to connect to the Playwright MCP server over the stdio transport, passing the command and arguments. When you ask it what tools it offers, it returns 23 browser tools for actions like navigate, take a screenshot, resize a window, and press a key. You then call create_agent with your provider:model string, all 23 browser tools, and a system prompt telling it to use the browser tools, and run it with ainvoke since browsing is async. The task: go to Hacker News and report the titles of the top three stories.

When it runs, a browser window flashes open and closed, and the agent battles through navigation, screenshots, and even JavaScript to extract the headlines, a vivid illustration of an AI agent as an LLM in a loop with tools persisting until it achieves its goal. Ed then digs into LangSmith traces to see why the mini model made a meal of it. By the end, you'll know how to build agents with LangChain that use MCP servers and Playwright for real web search and research, mastering this architecture for creating AI agents with LangChain that act autonomously in the browser.

If you want to learn:

- What is a Deep Agent and how is it a complete AI agent harness?

- How do Deep Agents extend create_agent with a file system, tools, and subagents?

- How does a Deep Agents harness handle long-running tasks and complex tasks with delegation?

- How does Deep Agents compare to the Claude Agent SDK and OpenAI sandbox agents?

- What default tools, like file system and to-do list tools, come with building deep agents?

- Why is Deep Agents considered the highest level of abstraction in the LangChain stack?

Then this lecture is for you!

In this hands-on lecture, you'll reach the fourth and highest layer of the stack, Deep Agents, a complete agent harness in the LangChain ecosystem. Ed Donner explains what a harness actually means: beyond the create_agent framework you already used, Deep Agents lets you describe the environment your agent operates in. It comes with default tools, a file system it can read and write, a to-do list, and the ability to delegate to subagents, running in a longer loop until it achieves its goal. This Deep Agents overview frames it as a batteries-included, agentic environment for ambitious work.

The key shift is in how you direct the agent. Instead of handing it a single task, you give it a bigger-picture intent, a multi-step goal, and the harness figures out how to run its loop, use its tools, and call its subagents to get there, ideal for long-running tasks and genuinely complex tasks. Ed makes this concrete by comparing Deep Agents to the Claude Agent SDK, which programmatically drives Claude Code: you set an intent, and it works for an extended period, using tools, including coding, before reaching a conclusion.

The crucial advantage of Deep Agents vs Claude Agent SDK is that while Claude Agent SDK is locked to Anthropic models, Deep Agents is part of LangChain and works with any supported LLM. You'll understand the context engineering and multi-agent delegation that sits behind Deep Agents, and why it resembles the OpenAI sandbox agents from week two. By the end, you'll grasp exactly what an agent harness is, why Deep Agents tops the stack, and be ready to use Deep Agents to build a real research assistant in the next lecture.

If you want to learn:

- How do you build a Deep Agents research assistant for a real commercial multi-step task?

- What are skills and how does a SKILL.md file with YAML front matter teach an agent your house style?

- What is progressive disclosure and why does it make skills so context-efficient for AI agents?

- How do skills differ from tools, and when should you use each when building deep agents?

- How does a Deep Agents harness use a file system, subagents, and skills together?

- Why are tools more robust than skills thanks to constrained decoding and schemas?

Then this lecture is for you!

In this hands-on lecture, you'll set up a commercial Deep Agents project: researching an electric-vehicle fleet rollout and having a team of agents produce a branded PowerPoint. Ed Donner outlines the plan for this multi-step assignment, where a Deep Agent writes its own to-do list, works through it, uses a sandbox file system on your hard drive, delegates to subagents, and uses a skill to learn your company's PowerPoint house style, all agentic delegation in action through a true harness.

The lecture's core concept is skills, a simple way to give extra capabilities to an AI agent. A skill is a markdown SKILL.md document whose top section is YAML front matter holding just a name and description; the rest is markdown instructions, here your house style for a one-slider recommendation deck. When the agent starts, it sees only the front matter and reads the full file only if relevant, an idea called progressive disclosure that keeps the context window lean. Invented by Anthropic for Claude Code, skills have become near-ubiquitous, and they shine at the agent harness level.

Ed then contrasts skills with tools in a thoughtful three-part answer. Skills are mainly a feature for end users of agent products like Claude Code or Codex, where you customize prompts; when you are building deep agents and writing your own code, you have full control over prompts and context engineering. Technically, tools are more robust because their inputs follow a schema enforced by constrained decoding, whereas skills rely on the model generating correct tokens. By the end, you'll understand skills, progressive disclosure, and the skills-versus-tools trade-off, ready to use both when building deep agents for real complex tasks.

If you want to learn:

- How do you set up the Deep Agents harness with create_deep_agent in LangChain?

- How do you configure a sandbox file system backend so an AI agent can read and write files?

- What extra tools, like write_todos and write_file, does a Deep Agent get for free?

- How do you give a Deep Agent a search tool and a system prompt for a research multi-step task?

- How do you inspect the LangGraph graph that create_deep_agent builds under the hood?

- How do you run a Deep Agent with invoke and watch it write a markdown briefing to the sandbox?

Then this lecture is for you!

In this hands-on lecture, you'll set up the Deep Agents harness in Cursor and run your first Deep Agent on a real commercial brief. Ed Donner explains that Deep Agents wraps the create_agent framework you already know in an opinionated, batteries-included harness. After imports (noting a deprecation warning for the GoogleSerperRun community tool), you'll point a Path object at a sandbox directory that the agent can work in exclusively, the environment where you'll watch files appear.

You'll create your first agent by calling create_deep_agent, which looks much like create_agent: you pass a model like gpt-5-mini, a list of tools including GoogleSerperRun, and a system prompt instructing it to plan with its to-do tool and write findings as a markdown briefing. The new ingredient is a backend pointed at the sandbox folder, defining the world the agent can operate in. Printing the agent reveals that create_deep_agent has built another LangGraph graph with extra scaffolding nodes wrapping the model and tools, exactly how it adds file-system access and extra tools.

Then you'll give it a real brief: research the US public EV charging landscape, estimate charging ports, pick two major providers, and write a one-page briefing to charging.md. You run it with invoke and watch it work. Inspecting the tools it called reveals write_todos, GoogleSerper, and write_file, tools you never explicitly supplied but that came along for the ride with the harness, proving Deep Agents automatically equips the agent with a to-do list and file-system tools. By the end, you'll have a working Deep Agent that plans, searches, and writes a tidy briefing to the sandbox, the foundation for building deep agents with subagents and delegation next.

If you want to learn:

- How do you delegate to subagents with Deep Agents in LangChain?

- How do you define a research subagent with a name, description, and system prompt?

- How does a lead agent use the task tool to delegate complex tasks to a subagent?

- How does Deep Agents delegation compare to OpenAI Agents SDK handoffs and CrewAI hierarchies?

- How do you inspect which tools the lead agent used, like write_todos and task?

- How do you read LangSmith traces to see middleware, summarization, and prompt caching at work?

Then this lecture is for you!

In this hands-on lecture, you'll unlock one of the most powerful features of Deep Agents: delegation to subagents. Ed Donner shows how a lead agent can hand off a focused job to one or more subagents, a multi-agent pattern that resembles OpenAI Agents SDK's agent-as-tool and handoffs, or CrewAI's hierarchical process, but operates at the higher agent harness level. Here the lead agent gets a task tool that lets it delegate generally, much like Claude Code delegating to a subagent.

You'll write two system prompts, one for the overall lead that writes comparison briefings and delegates each vehicle's research, and one for a research subagent that finds three concise facts a fleet buyer cares about. Defining the subagent is as simple as a dictionary with a name (vehicle_researcher), a description, and the system prompt. You then call the agent with a model, a single search tool, the overall instructions, your subagent, and the sandbox backend. The mission: compare the Tesla Model Y and Ford Mustang Mach-E for a 100-car fleet and write a markdown comparison.

Running it with invoke, you'll inspect the lead agent's tools and discover it used write_todos and a new task tool, calling task twice to delegate research before writing fleet.md, a clear view of delegation in action for long-running tasks. Ed then opens LangSmith to reveal the harness machinery: summarization middleware and Anthropic prompt-caching middleware wrapping each LLM call, plus the to-do list and Serper searches for both cars. By the end, you'll know how to architect multi-agent Deep Agents with subagents and delegation, and understand the context engineering an opinionated harness performs behind the scenes when building deep agents.

If you want to learn:

- How do you add skills and a PowerPoint tool to Deep Agents in LangChain?

- How do you write a custom create_slide tool that generates a branded PowerPoint slide?

- How do you organize a skills directory with a SKILL.md house-style guide for an AI agent?

- How do you build a slide-maker subagent that uses a tool plus a skill?

- How does progressive disclosure load a skill only when the agent needs it?

- How do you run a Deep Agent that reads a briefing and produces a finished PowerPoint deck?

Then this lecture is for you!

In this hands-on lecture, you'll deliver the satisfying punchline of the Deep Agents lab: having your agent team produce a branded PowerPoint slide that summarizes its research. Ed Donner combines two capabilities, a homemade tool and a skill. The tool is create_slide, built on a slidekit.py template using a PowerPoint library in the uv project, complete with the fonts and brand colors of a fictional fleet-analyst brand. The skill, meanwhile, captures the proprietary house-style guide for how the company's one-slider recommendation decks should look.

You'll examine the SKILL.md file: its YAML front matter holds a name and description that always load into context, while the markdown body, with instructions for a short title, three bullets, a recommendation, brand colors, and reading the briefing, loads only when the agent decides it is needed. This is progressive disclosure in action, like a prompt that appears just-in-time. You'll then define a slide_maker subagent with a name, description, system prompt, the create_slide tool, and a skills directory it can read, where each subfolder becomes a skill via its SKILL.md.

With create_deep_agent assembled from the model, the slide_maker subagent, a presentation system prompt, and the sandbox backend, you'll run it with invoke, asking it to read fleet.md and produce a one-slide deck. The harness spawns the subagent, which uses the create_slide tool and reads its skill to decide the content and house style, producing fleet.pptx, a polished branded slide. By the end, you'll know how to extend Deep Agents with skills and custom tools for real multi-step complex tasks, completing your mastery of building deep agents with subagents, a file system, and delegation.

If you want to learn:

- What is the Sidekick project and how is it a personal AI agent coworker?

- How do you build an operator agent that plans, uses tools, and checks its own work?

- How does the Sidekick use create_agent with tools, middleware, and memory?

- How do you add human-in-the-loop approval and an evaluator to an autonomous AI agent?

- How do middleware blocks add a to-do list, PII redaction, and a budget cap to a LangChain agent?

- How do success criteria let a Sidekick AI agent know when it has accomplished its goal?

Then this lecture is for you!

In this hands-on lecture, you'll meet the commercial project the whole week has built toward: the Sidekick, a personal AI agent coworker built with LangChain create_agent. Ed Donner reveals that rather than returning to messy LangGraph, this project stays at the create_agent layer, his favorite, so you can accomplish far more with less code. The Sidekick is a general agentic use case, originally OpenAI's operator agent idea: an autonomous AI assistant you give a task and success criteria, and it works with tools until it achieves the goal.

You'll preview the architecture. The heart is a worker built with create_agent that carries a ton of tools and memory, plus middleware that surfaces a to-do list onto the UI so you can watch its plan. More middleware adds guardrails, redacting personal information and enforcing a budget cap, all in a couple of lines. There is also human-in-the-loop functionality to pause for your input, which you could do with multiple invoke calls but is elegant through the framework.

Finally, outside the create_agent worker, a separate LLM call acts as an evaluator, checking that the success criteria were met, a clean best-practice workflow combining an agent loop with a simple chatbot-style judge. The Sidekick will feel real-world and autonomous: it browses the web through Playwright, accesses the file system, manages a to-do list, and sends push notifications. By the end, you'll understand the Sidekick's design and be ready to learn to build this open source-style coworker, combining everything from LangChain and LangGraph into one polished agent that you can learn how to build and make your own.

If you want to learn:

- How do you build the Sidekick AI agent with LangChain create_agent?

- What middleware building blocks give a Sidekick a to-do list, PII redaction, and a model-call cap?

- How do you add human-in-the-loop middleware and a tolerate-tool-errors wrapper to an agent?

- How do you organize a sidekick_tools module with Pushover, Serper, and Wikipedia tools?

- How does an evaluator with structured outputs check whether success criteria were met?

- How do you keep a Playwright browser session alive across an autonomous AI agent run?

Then this lecture is for you!

In this hands-on lecture, you'll start building the Sidekick coworker in Cursor, seeing what it is like to use create_agent to assemble something genuinely big. Ed Donner lays out the plan: a single create_agent worker equipped with a bunch of tools and a stack of middleware building blocks that add capabilities off the shelf. You'll add to-do list middleware so the agent's plan is observable and displayable in a UI, PII middleware to redact email addresses, model-call-limit middleware to cap the run at 30 model calls, and human-in-the-loop middleware to pause for approval, all classic patterns for building a simple AI agent that scales.

You'll also write your own tolerate-tool-errors middleware that wraps tool calls so a failing tool is handled gracefully instead of throwing. Around the agent, Ed sets up a lightweight harness: the worker attempts the task, an evaluator (just a model with structured outputs) checks whether the success criteria are met, and if not, it loops back, an elegant workflow layered on top of the agent. There is also a technical detail for keeping the Playwright browser window alive so it does not open and close repeatedly.

After the imports, including ChatOpenAI, create_agent, the human-in-the-loop middleware, and InMemorySaver (the new alias for MemorySaver), you'll tour the sidekick_tools module. It collects the Pushover push-notification tool, the built-in GoogleSerperRun, and a WikipediaQueryRun tool, plus a get_all_tools helper. By the end, you'll understand the full middleware stack and tools store behind the Sidekick, and be ready to build agents with LangChain that are resilient, observable, and autonomous, a real template for using LangChain to learn how to build a powerful personal coworker.

If you want to learn:

- How do you build a simple Sidekick AI agent with tools using create_agent?

- How do you give an agent search, push-notification, and Wikipedia tools in LangChain?

- How do you run a Sidekick worker asynchronously with ainvoke and a thread_id?

- How does human-in-the-loop middleware pause an agent for approve, edit, or reject decisions?

- How do you resume an interrupted agent with a Command and a resume decision?

- How do you implement a human approval step before a tool like book_meeting runs?

Then this lecture is for you!

In this hands-on lecture, you'll build a simple working version of the Sidekick and then add the powerful human-in-the-loop functionality that makes it feel safe and autonomous. Ed Donner starts by calling create_agent with a model in provider:model form (openai:gpt-5-mini), three tools from the sidekick_tools module (search, send_push_notification, and Wikipedia lookup), and a system prompt casting it as a helpful personal assistant. The familiar LangGraph diagram appears, a model with conditional edges to tools, and you run it through an async ask coroutine using ainvoke with a thread_id. The task: find who won the 2023 Nobel Prize in Physics and send a push notification, which arrives instantly.

Next you'll add human-in-the-loop control. LangChain provides human_in_the_loop_middleware that lets the agent pause and wait for a user to approve, edit, reject, or respond and resume. You'll create a fake book_meeting tool and an approval agent that uses it, passing the middleware with interrupt_on configured for book_meeting and an in-memory checkpointer. When you ainvoke with "book a meeting with Sam on Friday," the agent does not book it; instead it returns an interrupt asking for approval, showing the tool name and arguments.

You'll then resume by calling ainvoke again, not with a message but with a Command whose resume carries a decision of type APPROVE, and the meeting books. Ed also demonstrates REJECT, which skips the tool and lets the model try a different approach, plus the EDIT option for changing parameters. By the end, you'll know how to build a simple AI agent with tools and a robust human approval step, key skills for building a simple AI agent that you can trust, and the exact pattern the full Sidekick will use for its workflow.

If you want to learn:

- How do you build the full Sidekick module with create_agent in LangChain?

- How do you organize an AI agent into a sidekick.py module with a Sidekick class?

- How do you stack middleware for to-do lists, PII redaction, model-call limits, and human-in-the-loop?

- How do you add an evaluator using ChatOpenAI with structured outputs as an LLM-as-judge?

- How do you write a tolerate-tool-errors middleware with wrap_tool_call for resilience?

- How does putting specialist knowledge into the prompt make a Sidekick a true personal coworker?

Then this lecture is for you!

In this hands-on lecture, you'll reveal the full Sidekick by moving from a notebook into a proper sidekick.py module, structured around a Sidekick class. Ed Donner reassures you there is no new magic, it is just more of the same create_agent patterns, plus a simple ChatOpenAI evaluator at the end. The module opens with a Pydantic EvaluatorOutput class for structured outputs, capturing whether the success criteria were met and whether more user input is needed, the foundation of the LLM-as-judge step.

You'll study the prompt, where you inject specialist knowledge, like telling the agent to use Google Flights with a natural-language query, because building a simple AI agent that is genuinely useful comes down to priming it well. Then you'll see a custom tolerate_tool_errors middleware built with wrap_tool_call, which catches tool failures and hands a message back to the model so it can try another approach. The setup coroutine creates self.worker via create_agent, passing the model, the full set of tools from get_all_tools, and the system prompt with the current date appended at the end for prompt caching.

The middleware stack is rich: tolerate_tool_errors, to-do list middleware, PII middleware for emails and credit cards, model-call-limit middleware capped at 30 runs, and human-in-the-loop middleware whose interrupt_on watches send_push_notification and request_human_help, all wired to a memory checkpointer. Outside the agent, self.evaluator is a ChatOpenAI with structured output for EvaluatorOutput, judging whether the work met the criteria. By the end, you'll understand the complete, modular Sidekick architecture and how to build ai agents with LangChain that are resilient, guarded, and self-evaluating, ready to explore its 41 tools and full graph next.

If you want to learn:

- How do you explore the Sidekick's 41 tools and its full LangGraph graph?

- How do you call sidekick.setup to build the worker and evaluator with create_agent?

- What does a real create_agent LangGraph graph with middleware, model, tools, and human-in-the-loop look like?

- How do you run a Sidekick turn with run_turn, a message, and success criteria?

- How does the evaluator decide success and retry the AI agent up to three times?

- How does the Sidekick browse the web with Playwright and complete a complex flight-search task?

Then this lecture is for you!

In this hands-on lecture, you'll bring the Sidekick to life and explore the impressive machinery behind it. Ed Donner calls sidekick.setup, which builds the create_agent worker and the ChatOpenAI evaluator, and reveals it is configured with a remarkable 41 tools. Printing sidekick.tools shows the lineup: a whole batch of Playwright browser tools, plus Serper, push notification, Wikipedia, and file-system tools, a comprehensive toolkit for an autonomous AI coworker.

You'll then visualize sidekick.worker's graph. Because the middleware names contain square brackets that break the graphing software, Ed uses a small workaround to render it, and the result is a real, sophisticated LangGraph: starting at the top, flowing through layers of middleware, into the model via conditional edges, through human-in-the-loop steps before and after, down to a single tools node packaging all 41 tools, and finally to END. This is the perfect illustration of why create_agent is such a joy: it builds this elaborate graph for you, with all the power of LangGraph running behind the scenes, so you never assemble it line by line.

Next you'll run a real turn with the run_turn coroutine, passing a message and success criteria. The first task asks the Sidekick to report the top Hacker News story, and you watch a browser window pop up, the agent read the page, and the evaluator confirm the success criteria were met, with up to three retries if not. Then comes a complex mission: find the best round-trip flight from New York to London, write the top three to flight.md, and send a push notification. You'll watch the to-do list progress, approve a paused step, and see the recommendation written to the sandbox. By the end, you'll appreciate how building a simple AI agent with create_agent scales into a powerful, real LangChain coworker.

If you want to learn:

- How do you build a Gradio app for your Sidekick AI agent with human approval?

- How do you wrap a LangChain create_agent coworker in a polished chatbot-style UI?

- How do you surface a to-do list plan in the Gradio interface as the agent works?

- How does human-in-the-loop approval appear in the UI before a tool runs?

- How do you let an evaluator judge success criteria and retry inside a Gradio app?

- How do you style a Gradio app using CSS and JavaScript generated by a coding agent?

Then this lecture is for you!

In this hands-on lecture, you'll give your Sidekick a beautiful front end by building a Gradio app with human-in-the-loop approval, the finishing touch on your personal AI agent coworker. Ed Donner shows how a rough-and-ready Gradio app becomes polished by adding CSS and JavaScript, work that coding agents like Cursor Agent or Claude Code excel at; he even used Claude Code with the Fable model to generate the styling, stored in styles.py. The result is a fresh Sidekick browser UI with a chat window, a success-criteria input, and a live plan panel on the top right.

You'll walk through a full run inside the app. After entering a mission, find the best round-trip flight from New York to London, with success criteria demanding a markdown file of specific options plus a recommendation, you press Go. A plan immediately appears, populated by the to-do middleware, and a Playwright browser launches. As the agent works, you watch to-do items highlight and check off in the styled UI, searching flights, comparing options by price, writing to flights.md, and preparing a push notification.

The run pauses for human approval: a tool execution requires your sign-off on the top pick, and once you approve and continue, the Sidekick finishes, the evaluator confirms the success criteria are met, and the recommendation lands in the sandbox. Ed notes that LangSmith records the run as three separate traces for the original call, the approval, and the evaluator. By the end, you'll know how to deliver a complete, autonomous AI coworker with a real UI, capping a week of building ai agents with LangChain and LangGraph, and you'll be ready to turn this open source-style Sidekick into your own daily assistant.

If you want to learn:

- What are the six agent frameworks covered in Week 5 of this agentic AI course?

- Why do all AI agent frameworks share the same five core steps?

- What is Google ADK, the Google Agent Development Kit?

- How does the A2A agent2agent protocol fit alongside Google ADK?

- Why does it not matter which AI agent framework you choose for your projects?

- What is the definition of an AI agent as an LLM in a loop with tools?

Then this lecture is for you!

In this hands-on lecture, you'll kick off a whirlwind tour of six-and-a-half AI agent frameworks, all squeezed into one fast-paced week. Ed Donner lays out the roadmap: Google ADK (the Google Agent Development Kit) and a sidebar on the A2A protocol today, then Strands and Pydantic AI, then the Microsoft Agent Framework and Agno, then the TypeScript framework Mastra, and finally a multi-agent agent loop project. The single big message that spans them all: once you know one framework, you basically know them all, because under the hood they share the same abstractions for calling tools in a loop to achieve a goal.

You'll anchor everything on the community definition of an AI agent as an LLM in a loop with tools to achieve a goal, and you'll learn the exact same five steps you will repeat for every framework: create an agent from a model and system prompt, run it, add simple function tools, plug in an MCP server, and finally put it in a loop with a goal so you can say you have built true agentic AI. You'll also get the lay of the land for Google ADK itself, a developer-first framework loved by coders that shipped in April 2025 after the OpenAI Agents SDK, now on its second generation with Python and TypeScript versions.

You'll learn why Google ADK feels code-centric, why a plain function becomes a tool with no decorator, and what makes ADK Web a standout local observability playground. You'll also see why two famous standards, MCP and A2A (agent2agent), are first-class citizens of this AI agents ecosystem, and how ADK stays flexible with Gemini by default plus any model through LiteLLM. By the end, you'll understand exactly what to expect from this multi-agent week and why building a multi-agent system with any of these tools comes down to the same satisfying pattern, deployable wherever your team works, including Google Cloud.

If you want to learn:

- How do you build an AI agent with the Google Agent Development Kit?

- What is an LLM agent in Google ADK and how is it different from an OpenAI agent?

- How do you run a Google ADK agent with the in-memory runner and run_debug?

- How do you add Python function tools to an ADK agent with no decorator?

- How do you give a Google ADK agent a shared SQLite to-do board?

- Why does ADK use instruction singular instead of instructions?

Then this lecture is for you!

In this hands-on lecture, you'll get started with Google ADK by opening the day-one lab in Cursor and working through the first three of the five repeatable steps. You'll confirm Node is installed, set your Google API key in the .env so Gemini is the default model, and pre-install the file-system MCP server with a quick npx command so the rest of the lab runs smoothly. This is a true developer walkthrough of the Google Agent Development Kit, the framework that turns plain Python into agentic behavior.

You'll learn step one, creating an agent: you pick a Gemini model and build an LLM agent (Google ADK's name for what the OpenAI Agents SDK simply calls agent), passing a model, a name, and instruction singular as the system prompt. Step two is running it with the in-memory runner and run_debug, awaiting an async call and getting back "hola" to prove the AI agent works, even if it is still an agent in name only. Then step three adds tools: in Google ADK a tool is just a Python function with type hints and a docstring, no decorator required, so you wire up show_todos, plan_steps, and complete_tasks that read and write a persistent SQLite to-do board.

You'll learn how that shared board, cribbed from week one with a Claude-Code-style printout, lets the ADK agent track goals and steps as it ticks them off, and you'll add a Pushover push-notification tool to see another tool fire with a fun chime. By the end, you'll have a working Google ADK agent equipped with real tools and a managed to-do board, ready to add MCP and a goal loop, and a clear feel for how this developer-first agent development kit compares to every other framework this week.

If you want to learn:

- How do you equip a Google ADK agent with MCP tools?

- How do you use the Anthropic server-filesystem MCP server to read and write files?

- How do you set up StdioServerParameters and an MCPToolset in Google ADK?

- How do you put a Google ADK agent in a loop with a goal?

- How do you run an ADK agent from a Python module with uv run worker.py?

- What is the ADK Web local observability dashboard?

Then this lecture is for you!

In this hands-on lecture, you'll complete the final two of the five steps for Google ADK by giving your AI agent real-world capabilities through MCP. You'll equip the ADK agent with the server-filesystem MCP server from Anthropic, one of their reference implementations, so it can read and write files in a sandboxed workspace directory. You'll learn how to describe that server with StdioServerParameters, wrap it in standard stdio connection parameters, and pass it to your agent through an MCPToolset object, then prove it works by having the agent read notes.txt and summarize it in a single sentence.

You'll learn why this is the whole point of MCP: instead of hand-writing file-system tools with method signatures and prompts, someone else has packaged reusable tools into a server you connect with one line. Then comes step five, putting the Google Agent Development Kit agent in a loop with a goal. You'll see why run_debug is no longer enough and learn the real plumbing: create an in-memory runner with the agent, create a session with a user ID, and iterate over events with runner.run_async. With a goal on its SQLite board, your agent reads notes.txt, translates the contents into Spanish, writes spanish.txt, and sends a push notification, all in one autonomous run.

You'll learn how the board organizes goals with steps rolling up underneath, how the agent invents its own steps and crosses them off, and how to package the lab into a clean worker.py module you launch with uv run worker.py and a --seed-only reset. Finally you'll bring up ADK Web with uv run adk web, a slick local dashboard on port 8000 that visualizes tools and tasks as the agent runs. By the end, you'll have a fully agentic Google ADK worker with MCP file-system tools and live observability.

If you want to learn:

- What is the A2A agent-to-agent protocol from Google?

- What is an A2A agent card and the well-known agent-card.json URL?

- How do you expose an ADK agent as an A2A server?

- How does A2A compare to MCP, and can MCP call another agent as a tool?

- Why might A2A adoption be more hype than reality right now?

- How do you run an A2A demo with adk web and a spanish-concierge agent?

Then this lecture is for you!

In this hands-on lecture, you'll explore A2A, the agent-to-agent protocol (agent2agent) originally announced by Google with a splashy press release and later handed to the Linux Foundation as an open standard. You'll learn what A2A actually is: a standard way for agents to discover each other, learn each other's capabilities, and call each other to collaborate. You'll see how easy this is inside the Google Agent Development Kit, where just a couple of calls expose one adk agent and let another consume it, and you'll meet the agent card, the business card for an AI agent published at a well-known agent-card.json URL.

You'll learn a balanced, real-world take on the A2A protocol. Ed Donner shares honest skepticism that the hype has outrun adoption, because most teams are still figuring out their own agent architectures before they need agents from different people on different hardware to collaborate remotely. You'll also learn the key catch in the "A2A complements MCP" story: MCP can itself expose an agent as a tool (Firecrawl does exactly this), so the line between the protocol for tools and the protocol for agents is blurrier than the marketing suggests.

Then you'll run a concrete A2A demo. You'll launch a translator exposed as an A2A server on port 8001, inspect its agent card JSON with curl and in a browser, then bring up adk web inside the a2a-demo directory and send a request to the spanish-concierge agent, watching it reach the translator over A2A to translate English into Spanish. By the end, you'll understand the agent-to-agent protocol, when it shines for building a multi-agent system, and why for now you can usually achieve the same collaborate-style results with plain calls or MCP.

If you want to learn:

- How do you build AI agents with Strands from AWS?

- What makes Strands Agents a lightweight production-ready framework?

- How do you swap from Amazon Bedrock to GPT-4o-mini in Strands?

- How do you add the @tool decorator and MCP servers in Strands Agents?

- How do you run a Strands agent loop with invoke_async?

- How does Strands handle observability with OpenTelemetry and Langfuse?

Then this lecture is for you!

In this hands-on lecture, you'll start building AI agents with Strands, the open-source framework from Amazon AWS whose full name is Strands Agents. You'll learn why Strands is interesting: although it is connected to Amazon Bedrock and is Bedrock-native by default, it is deliberately branded as a community open-source Python (and TypeScript) library for building production-ready AI agents. Generally released in July 2025 at a 1.0 version, it is a super lightweight, very idiomatic framework that makes it easy to build AI agents fast.

You'll learn the same five steps you'll repeat all week, adapted to Strands. Step one creates the agent: you define an OpenAIModel with an API key and model ID, swapping Bedrock for GPT-4o-mini, then build an agent with a model and a system_prompt (Strands keeps it lightweight, no instruction-versus-instructions debate). Step two runs it with a single invoke_async call, no runner needed, returning "hola". Step three adds tools using the @tool decorator (the same style as LangChain) with docstrings and type hints, wiring show_todos, plan_steps, and complete_task to your shared SQLite to-do board.

You'll learn step four, adding MCP: you set up StdioServerParameters, create an MCPClient for the file-system server, and pass it as tools so the AI agent can read notes.txt. Step five puts the worker in a loop with a goal, calling worker.invoke_async to read, translate to Spanish, and write the output file with almost no plumbing. You'll also run it from a Python module with uv run strands_worker.py. You'll hear how Strands offers a built-in agent loop, easy provider swapping, and observability via AWS or OpenTelemetry and platforms like Langfuse to debug at runtime. By the end, you'll have a working customer support-ready Strands agent and a feel for the simplest framework of the week.

If you want to learn:

- How do you build AI agents with Pydantic AI?

- Why was Pydantic AI an inspiration for the OpenAI Agents SDK?

- How do you create and run a Pydantic AI agent with agent.run?

- How do you add tools in Pydantic AI without decorators?

- How do you connect an MCP toolset to a Pydantic AI agent?

- How does Pydantic AI make structured output easy with type safety?

Then this lecture is for you!

In this hands-on lecture, you'll start building AI agents with Pydantic AI, the agents library from the team behind Pydantic and one of the most loved early frameworks among engineers. You'll learn its heritage: it was around in beta in 2024 and partly inspired the OpenAI Agents SDK, and it weaves Pydantic's Python type safety throughout. You'll use it with OpenAI's models (you can swap any LLM), note that a V2 beta exists while you stay on the stable V1, and see why it is a strong choice for production-ready AI agents.

You'll learn the same five steps, now in Pydantic AI syntax. Step one defines a model using the colon syntax, openai-chat:gpt-4o-mini, then builds an Agent with that model and instructions plural as the system prompt. Step two runs it with the wonderfully simple agent.run, perhaps the easiest runner of the week, returning "hola". Step three adds tools, and you'll learn that while Pydantic AI offers flexible decorator-based tools, you do not need them at all: plain functions like show_todos, plan_steps, and complete_task with docstrings are passed straight in as tools to manage the shared SQLite board.

You'll learn step four, adding MCP: you set up a stdio transport with the same parameters as before, wrap it in an MCPToolset with an init_timeout, and pass it via toolsets so the AI agent can read files. Step five loops the worker with a goal to read notes.txt, translate to Spanish, and write the file, calling worker.run. You'll also hear about Pydantic AI's Logfire observability platform and how its structured output into a Pydantic object (a dependency-aware, type-safe result) is a breeze, exactly what you'd expect from this team. By the end, you'll have a working agents with Pydantic AI worker and see how this beloved framework mirrors Strands, ADK, and the OpenAI Agents SDK.

If you want to learn:

- How do you run a Pydantic AI agent from a Python module?

- How do you launch a Pydantic AI worker with uv run pydantic_worker.py?

- How does a Pydantic AI agent persist its to-dos to a SQLite board?

- Why are Pydantic AI, Strands, ADK, and OpenAI Agents SDK so similar?

- Do you actually need decorators to add tools in Pydantic AI?

- What are the trade-offs of building AI agents with Pydantic AI?

Then this lecture is for you!

In this hands-on lecture, you'll finish your Pydantic AI walkthrough by running the agent not from a notebook but from a clean Python module, the way you would in a real production-ready project. You'll open a fresh terminal and run uv run pydantic_worker.py to launch the same worker you built step by step, watching it seed a goal, run it, and complete successfully. You'll learn the value of always checking the module code to see how the build AI workflow is assembled outside the lab, so you can lift it straight into your own applications.

You'll learn to watch the agent loop in action from the command line: the worker thinks, the board SQLite files change as it writes its to-dos, and then it crosses off every step plus the overarching goal, returning the Spanish translation it also wrote to spanish.txt. This is the same AI agent you assembled with agents with Pydantic AI, now proving it runs identically as a deployable module, an important pattern for moving from experimentation to a real runtime.

You'll learn the big recurring message reinforced here: Pydantic AI is strikingly similar to Strands, Google ADK, the OpenAI Agents SDK, and even LangGraph create_agent. They are all quite alike, and that is the point of this framework-comparison week. You'll also revisit the trade-offs, including the correction that Pydantic AI's flexible decorator tools are entirely optional (plain functions work just as well), plus its structured output strength and the V2-beta caveat. By the end, you'll have run a real Pydantic AI worker from a module, closing out day two's building AI agents tour of Strands and Pydantic AI and arriving 73% through the course.

If you want to learn:

- What is the Microsoft Agent Framework and why did Microsoft build it?

- How is the Microsoft Agent Framework the successor to AutoGen and AG2?

- How does Semantic Kernel fold into the Microsoft Agent Framework?

- What workflow and multi-agent workflows does the Microsoft Agent Framework support?

- How does the Microsoft Agent Framework handle MCP, tools, and observability?

- Does the Microsoft Agent Framework have a Python and a .NET SDK?

Then this lecture is for you!

In this hands-on lecture, you'll learn the full story behind the Microsoft Agent Framework, Microsoft's official open-source AI agent SDK and one of the most talked-about of the open-source AI agent frameworks. You'll learn Microsoft's complicated history with AutoGen: they built AutoGen with the community, re-engineered it, and triggered a community split that produced AG2 (really an evolution of the original), while Microsoft's own AutoGen became something more like a version two. After all that, Microsoft converged everything into the Microsoft Agent Framework.

You'll learn that the Microsoft Agent Framework is the natural successor to AutoGen, which is being sunsetted, and that it also folds in Semantic Kernel, Microsoft's lower-level LangChain-style framework. So the new platform brings together two prior products into one official SDK. You'll see why it is grounded in mature AutoGen ideas yet still very new and building a following, and why some developers worry about stability after so many rewrites, including renames in 2026 that forced code changes.

You'll learn the key features, all familiar by now: it supports tools as plain Python functions, MCP works out of the box by passing servers in as tools, and there is a simple agent.run for the agent loop. You'll also hear about its more sophisticated workflow engine for multi-agent workflows, a LangGraph-like nod to its Semantic Kernel roots, plus a .NET version popular with that crowd and strong telemetry and observability built in (tying into Microsoft Foundry and OpenTelemetry). By the end, you'll understand what the Microsoft Agent Framework is, how it relates to the OpenAI Agents SDK and other agents and multi-agent workflows tools, and be ready to start building AI agents with it in the lab.

If you want to learn:

- How do you build an agent with the Microsoft Agent Framework?

- How do you create an OpenAI chat client and agent in the Microsoft Agent Framework?

- How do you run an agent with await agent.run in the Microsoft Agent Framework?

- How do you add Python function tools and a tool call to a MAF agent?

- How do you connect an MCP stdio tool in the Microsoft Agent Framework?

- How do you run a Microsoft Agent Framework worker from a Python module?

Then this lecture is for you!

In this hands-on lecture, you'll go hands-on building AI agents with the Microsoft Agent Framework (MAF), working through the same five steps in the maf_lab. You'll import agent and the MCP stdio tool from agent_framework, then tackle step one: create an OpenAI chat client with gpt-4o-mini and build an agent with that client and instructions plural. Step two runs it with await agent.run, no runner needed, returning "hola" and proving your AI agent works using agents with Microsoft Agent Framework.

You'll learn step three, adding tools: define show_todos, plan_steps, and complete_tasks as plain Python functions with no decorator, pass them in via tools=, and watch the board agent make a tool call to report what is on the shared SQLite to-do board. Step four adds MCP: create a parameters object, wrap it in an MCP tool object, and pass it in as the agent's tools so it can read notes.txt with file-system tools written by Anthropic. You'll see the small notebook-only workaround needed so the stdio tool runs on Windows, while the clean worker implementation stays simple.

You'll learn step five, the loop with a goal: build an agent with the client, the three board tools, and the file-system MCP tools, then tell it to work the pending goal. It reads the notes, translates them into Spanish, writes the file, and crosses everything off, all driven by the Microsoft Agent Framework. Finally you'll run uv run maf_worker.py to prove the same thing works from a Python module at runtime, with the framework's telemetry and observability available throughout. By the end, you'll have a complete using Microsoft Agent Framework worker and see how closely it mirrors the OpenAI Agents SDK and every other framework this week.

If you want to learn:

- What is Agno, the fast open source agent framework?

- Why was Agno formerly known as Phi Data?

- How fast can Agno create a new agent and why does low overhead matter?

- What is Agno Agent OS, the runtime for deploying and scaling agents?

- How does Agno handle tools, MCP, and model swapping with OpenAI chat?

- How does Agno compare to the Microsoft Agent Framework and other frameworks?

Then this lecture is for you!

In this hands-on lecture, you'll meet Agno, a fast, lightweight, open-source AI agent framework and a genuinely fun one to round out the week's Python frameworks. You'll learn that Agno, formerly known as Phi Data, is prized for speed: it takes only a fraction of a millisecond (around three microseconds) to create a new agent because an Agno agent is a lean data object with almost no overhead. That low-overhead design is one of its biggest value propositions and a real differentiator among open-source AI agent frameworks.

You'll learn that Agno ships as part of a wider product offering that includes Agent OS, a popular runtime for deploying, running, and scaling agents built with Agno. So while Agno itself is the lean, mature, free framework, Agent OS is the companion (mostly paid) product that lets you deploy and scale your AI agents in production, recently revamped to make scaling straightforward. You'll hear the honest trade-offs too, including some V2 rename churn and the gentle sales pitch toward Agent OS as the monetization strategy.

You'll learn the now-familiar feature set, ready for the lab to follow: in Agno a tool is just a function with very little ceremony, MCP tools are passed in the same simple way as the other frameworks, and the agent loop runs through a clean agent.arun call (much like LangChain's invoke). You'll also see how easy it is to swap models using OpenAI chat. By the end, you'll understand exactly what makes Agno distinct from the Microsoft Agent Framework, Strands, Pydantic AI, and Google ADK, why its fast startup and Agent OS runtime stand out, and you'll be ready to build your first Agno agent.

If you want to learn:

- How do you build your first Agno agent step by step?

- How do you create an Agno agent with an OpenAI chat model and instructions?

- How do you run an Agno agent with await agent.arun?

- How do you add function tools and a tool call to an Agno agent?

- How do you connect an MCP server to an Agno agent with a context manager?

- How do you run an Agno worker from a Python module with uv run?

Then this lecture is for you!

In this hands-on lecture, you'll build your first Agno agent by working through the same five steps one last time for a Python framework. You'll import agent from agno.agent, then step one: set a gpt-4o-mini constant, define the model as OpenAI chat with that ID, and create an Agent with the model and instructions. Ed Donner jokes that by now the frameworks are so similar he could not tell which one he was looking at, which is exactly the point. Step two runs the AI agent with await agent.arun (not run, not invoke_async), returning "hola".

You'll learn step three, adding tools: with no decorators, define show_todos, plan_steps, and complete_task whose docstrings the framework turns into JSON, then create an agent with the model, instructions, and two tools and make a tool call via boardagent.arun to read the shared SQLite to-do board. Step four adds MCP: using a Windows-safe notebook hack, set up stdio server parameters and a context manager (with MCPTools and a 60-second timeout) to get a file-system object you pass as tools, so the agent can read notes.txt and summarize it.

You'll learn step five, the loop with a goal: build an agent with the file-system MCP tools plus the three board tools, then call arun to work the pending goal, watching it write spanish.txt and cross off its steps autonomously. Finally you'll run uv run agno_worker.py to prove the same agent runs from a Python module at runtime. The big takeaway lands here: across Agno, the Microsoft Agent Framework, Strands, Pydantic AI, and Google ADK, it is the same five steps and the same agent loop, so you never need to memorize which call is which. By the end, you'll have built a complete Agno agent and wrapped up day three.

If you want to learn:

- What is Mastra, the TypeScript agent framework?

- Why is Mastra called a TypeScript-native open-source framework?

- How does Mastra use Zod and the Vercel AI SDK?

- How do you run a Mastra agent loop with agent.generate?

- What is Mastra Studio and how is it like Google ADK Web?

- Why would you choose Mastra to build AI agents in TypeScript?

Then this lecture is for you!

In this hands-on lecture, you'll get a refreshing change of pace as you meet Mastra, the one TypeScript framework of the week and the course's only foray into build AI agents in TypeScript. You'll learn what sets Mastra apart from the others: while almost every framework so far started as a Python tool with a TypeScript variant bolted on, Mastra was created TypeScript-native from day one. It is built by the team behind Gatsby, the hugely popular React static-site generator, and its standout feature is an excellent local developer experience for building AI agents.

You'll learn the features that give this open-source TypeScript framework its identity. Tools are defined with a clean createTool function that uses Zod, the TypeScript equivalent of Pydantic, for schemas. It creates MCP clients as easily as every other framework. You run the agent loop with agent.generate, a familiar-feeling call under a different name. It ships with Mastra Studio, a local developer studio reminiscent of Google ADK Web. And because it builds on the Vercel AI SDK, the ferociously popular SDK from Vercel, it is thoroughly model-agnostic, so you can swap any model with ease.

You'll learn the honest trade-offs of this typescript agent framework too: there is a bit more plumbing and setup than some of the lighter options, and like most early agentic tools it has seen some rewrites, but these are minor against how popular and pleasant it is to use. By the end, you'll understand why Mastra is a top choice when you need to build AI agents and agents and workflows in TypeScript, how it maps onto the same five steps as the Python frameworks, and you'll be ready to deploy and build your first Mastra agent in the next lecture.

If you want to learn:

- How do you build a Mastra agent in TypeScript step by step?

- How do you set up a Mastra project with Node 24 and npm install?

- How do you define tools in Mastra with createTool and Zod schemas?

- How do you create and run a Mastra agent with agent.generate?

- How do you connect an MCP client in Mastra with MCPClient and npx?

- How do you run Mastra steps one through four with npm run?

Then this lecture is for you!

In this hands-on lecture, you'll build your first Mastra agent in TypeScript, working not in a Jupyter notebook but through lab.md and five standalone TypeScript programs you run one by one. You'll start with first-time setup: confirm you are on Node version 24 or later (using nvm if you like), then run npm install in the mastra directory to pull all dependencies into node_modules. This is the practical, developer-focused way to spin up an open-source TypeScript framework project.

You'll learn how Mastra's pieces fit together before the steps. You'll peek at board.ts, a lightweight SQLite to-do board wrapped in simple SQL queries, then tools.ts, where each tool is built with createTool, taking an id, a description, a Zod inputSchema, and an execute callback that runs TypeScript to read and write the board. You'll also see makeFilesystem, which returns a new MCPClient configured with npx and the server-filesystem name, defining the MCP tools your AI agent will use to read and write files.

You'll learn the steps by running them: step one creates a new Agent with an id, name, instructions, and a provider/model name and runs with npm run step1. Step two adds agent.generate ("Say hello in Spanish") and returns "Hola" via npm run step2. Step three gives the typescript agent its board tools and asks what is on the board. Step four wires in the MCP server by calling listTools on makeFilesystem, then has the agent read notes.txt and summarize it, all launched with npm run step4. By the end, you'll have a working Mastra agent built and run in TypeScript, ready for the final step that combines board and MCP tools in a full agent loop.

If you want to learn:

- How do you combine board and MCP tools in a Mastra agent?

- How do you spread two tool sets together in TypeScript with listTools?

- How do you run a full Mastra agent loop with worker.generate?

- How do you launch Mastra Studio with npm run dev on port 4111?

- How does Mastra compare to ADK Web and the Python frameworks?

- How do you build an end-to-end agent loop in TypeScript with Mastra?

Then this lecture is for you!

In this hands-on lecture, you'll complete your Mastra build by combining board and MCP tools into a single worker that runs a full agent loop in TypeScript. You'll put a goal on the SQLite board ("read notes.txt, translate its contents into Spanish"), write general worker instructions, then create a new Agent with a name, id, instructions, and model. The key move is merging two tool sets: you take the imported board tools and call listTools on the file-system MCP client, then spread them together so your AI agent has every tool it needs in one place.

You'll learn to run the whole thing with worker.generate ("Please work the pending goal on the board") launched via npm run step5. You'll watch the typescript agent seed the goal, run the loop, create spanish.txt, and print everything crossed off, producing output strikingly similar to the Python frameworks. This is the payoff of building AI agents in Mastra: the same five steps, the same agentic behavior, just with semicolons, Zod schemas, and createTool instead of decorators.

You'll learn how Mastra Studio gives you developer tooling much like Google ADK Web. Running npm run dev in the full Mastra directory starts the studio on localhost port 4111, where you open the agents page, click into your worker agent, chat with it ("Go ahead and work your board"), and watch it use its tools to produce Spanish. You'll close with a clean recap of how Mastra maps to every other framework: create an agent with a model, run with generate, define tools with createTool, add MCP the same way, and loop with a goal. By the end, you'll have built and deployed an end-to-end agent loop in TypeScript and be ready for the multi-framework agent loop project.

If you want to learn:

- What is the agent loop project where six frameworks work together?

- How do you build a multi-agent system with a nested outer and inner loop?

- How does an ADK orchestrator manage a team of agents from different frameworks?

- Why do you not need A2A when you control all the agent code yourself?

- What is the difference between orchestrating with code and orchestrating with LLMs?

- How does a shared to-do board enable autonomous multi-agent collaboration?

Then this lecture is for you!

In this hands-on lecture, you'll meet the week-five capstone: the agent loop project, where every framework you have learned collaborates on one product. You'll learn the design of this multi-agent system: the user names a language (like Spanish), and a team of agents builds a local website of games and puzzles to teach it, a Spanish arcade. Five builders, each from a different agent framework (Strands, Pydantic AI, Microsoft Agent Framework, Agno, and Mastra), write to one shared SQLite to-do board, while a Google ADK orchestrator runs the whole show.

You'll learn the core architecture: a nested agentic design with an outer loop and inner loops. The agent development kit orchestrator decides what to do, launches whatever builder agents it finds in the subdirectories (delete a folder and it simply will not spawn), runs them in parallel, judges them, and repairs bugs. Each builder runs its own inner agent loop, pulling goals and steps off the board. You'll see why the plumbing holding this together is nothing more than a to-do list tool: these are LLMs predicting likely tokens, and by equipping them with board tools you produce genuinely autonomous behavior.

You'll learn an important real-world lesson about multi-agent architecture: even though this looks like a perfect A2A use case, you do not need A2A here. When you wrote all the agent code yourself, you orchestrate with plain tool calls or Python, not a discovery protocol for remote agents. You'll also learn why this example deliberately orchestrates with LLMs rather than code, trading some reliability for flexibility so the orchestrator has freedom. You'll meet the browser QA agent that uses Playwright through an MCP server to test every game. By the end, you'll understand the whole framework for building this autonomous AI system and be ready to build it.

If you want to learn:

- How do you build a multi-framework agent loop with an ADK orchestrator?

- How does orchestrator.py create an LLM agent and call runner.run_async?

- How does the orchestrator spawn each agent framework as a separate process?

- How does a QA agent use the Playwright MCP server to test the site?

- Why split out a separate CSS agent as its own LLM call?

- How do you configure models in config.py and launch with uv run agent_loop.py?

Then this lecture is for you!

In this hands-on lecture, you'll build the multi-framework agent loop by walking through the orchestrator that ties every framework together. You'll open orchestrator.py and learn that beneath some cross-platform plumbing (it spawns and kills processes so it works on Mac and Windows), it comes down to the familiar pattern: create an LLM agent the Google ADK way with a name, model, instruction singular, and tools, then call runner.run_async inside a session to kick it off. The tools let it post goals to the shared board and launch team members to work on tasks.

You'll learn how the orchestrator's behavior is driven by a separated prompt file (good practice borrowed from CrewAI) that tells the agent to build a website of language-learning games, the one place you would edit to make your multi-agent ai team do something else. You'll learn why listing steps in a prompt is a red flag that sometimes signals code orchestration would be safer, but here it is intentional to give the agent agency. You'll also meet two more AI agent building blocks: a QA agent that gets the Playwright MCP tool so it can open a browser and test the site, and a sneaky CSS agent, each its own ADK LLM agent with its own runner.run_async, split out as separate well-defined LLM calls because that yields better outcomes.

You'll learn the final setup before launch: config.py is where you choose models (a pricier Gemini Flash for the orchestrator and a capable model for the workers, or cheaper ones if you prefer), and you start everything with uv run agent_loop.py, optionally choosing a different language or skipping frameworks. By the end, you'll understand the core architecture of this autonomous multi-agent system, how each agent framework plugs in as a spawned process, and how to deploy and run the full agentic framework for yourself.

If you want to learn:

- How do you run a team of agents from six frameworks at once?

- What happens when you launch the Spanish arcade with uv run agent_loop.py?

- How do five agent frameworks share one to-do board in parallel?

- How does the Playwright MCP QA agent test every game in the browser?

- Why does multi-agent collaboration work without A2A?

- How do you extend the agent loop with a measurable outcome and feedback loop?

Then this lecture is for you!

In this hands-on lecture, you'll run the full multi-agent system live and watch six frameworks build a product together. You'll launch uv run agent_loop.py and see the Google ADK orchestrator, led by Gemini Flash, assemble a Spanish arcade with five builders: AWS Strands, Pydantic AI, Microsoft Agent Framework, Agno, and Mastra. Five assignments go out in parallel, and faster than you can follow, each AI agent generates its own to-dos and crosses them off on one shared board, every agent framework managing its own steps that roll up to a high-level goal under the orchestrator's orchestration.

You'll learn how the QA stage works: once the builders finish, the ADK QA agent uses the Playwright MCP server to launch a real browser window and play each game one by one, reporting back with a tool call whether it works. You'll see honest, real-world behavior too, including the MCP server timing out occasionally and the autonomous agents working around it, a genuine taste of the challenge of making autonomous AI systems reliable, especially with smaller models. Then you'll explore the finished arcade: a color-match game, a numbers guessing game, a greetings game, a tapas-ordering match, and an action-verb arcade, each built independently by a different framework in vanilla HTML and each getting progressively harder.

You'll learn the two big payoffs: how similar all the agent frameworks really are when running side by side, and a concrete, tangible feel for a loop within a loop. You'll also revisit why none of this needs A2A, since you control all the code and can collaborate with plain calls and prompts. Finally, you'll get the end-of-week challenge: adapt this multi-agent architecture to a problem you care about, specialize each agent, and add a measurable outcome with an outer feedback loop to keep iterating toward a higher score. By the end, you'll have run a complete multi agent team and know how to build AI agents that work together on real goals.

If you want to learn:

- What is the Model Context Protocol (MCP) and why is it the finale of an agentic AI course?

- What is an AI agent and an agent harness, and how do they relate?

- How do agent frameworks sit on a continuum from raw LLM calls to full agent harnesses?

- Where do LangChain, LangGraph, Strands Agents, OpenAI Agents SDK and CrewAI fit on that spectrum?

- What is the Claude Agent SDK and how is it different from other agentic AI frameworks?

- How does MCP, the open standard for connecting AI, set up the rest of MCP week?

Then this lecture is for you!

In this hands-on lecture, you'll kick off week six, the MCP (Model Context Protocol) finale of this agentic AI course with instructor Ed Donner. Before diving into MCP, you'll recap exactly what an AI agent is: an LLM equipped with tools, running in a loop to achieve a goal. You'll also meet the increasingly popular idea of an agent harness, where an LLM plus a harness (the tools, the loop and the goal) becomes an AI agent, and you'll see how the earlier weeks built that foundation with native LLM calls and the OpenAI Agents SDK.

You'll then explore a nuanced continuum of agentic AI frameworks, laid out from low-level, lightweight options on the left through to batteries-included agent harnesses on the right. You'll place direct LLM calls, LangChain core components like ChatOpenAI, LangGraph, Strands Agents, the OpenAI Agents SDK, Google ADK, Agno, Mastra, Pydantic and LangChain Create Agents, plus the more opinionated CrewAI and the all-in LangChain Deep Agents. You'll understand the trade-off: more control and easier debugging on the left, less work but harder troubleshooting on the right.

Finally, you'll learn about the Claude Agent SDK as the odd one out, a way to programmatically drive Claude Code in Python or TypeScript using its query function, rather than a true agent framework. This sets the stage for MCP, the open standard for connecting AI assistants, LLMs and AI agents to a huge ecosystem of tools. By the end, you'll have the conceptual map you need to understand how MCP servers and the model context protocol slot into modern agentic workflows.

If you want to learn:

- What is the Model Context Protocol (MCP) and what is it not?

- How does MCP work as an open standard for connecting AI assistants and AI agents to tools?

- Why does Anthropic describe MCP as a "USB-C port for AI applications"?

- What are the three things MCP covers (tools, resources, prompts) and which one actually took off?

- What is the difference between an MCP host, MCP client and MCP server?

- How does MCP compare to the LangChain tools ecosystem, and why is an open standard such a big deal?

Then this lecture is for you!

In this hands-on lecture, you'll get a clear, grounded explanation of the Model Context Protocol (MCP) from Anthropic, starting with what it is not. You'll learn that MCP is not an agent framework and not a new way to code agents; it is simply a protocol, a standard, an open standard and agreed specification for how to integration of tools, resources and prompts into your AI agent. You'll see why an open standard for connecting AI assistants and LLMs is so powerful: any tool that follows the MCP standard can be reused, unlike the old days when LangChain tools were locked to LangChain.

You'll explore Anthropic's "USB-C port for AI applications" analogy, the plug-and-play idea behind connecting AI to content repositories and third-party tools, and a healthy dose of skepticism about the hype. You'll understand that MCP itself is only the spec, while the real innovation lives in tools like Microsoft's Playwright, and that MCP shines for connecting AI assistants such as ChatGPT and Claude to a massive open-source ecosystem of MCP servers, even if it can feel like a Wild West of choice.

Finally, you'll learn the three core terms that define MCP architecture: the MCP host (your agent, ChatGPT or Claude Desktop), the MCP client (code running inside the host, one per server), and the MCP server (the third-party tools, like Anthropic's Fetch server). By the end, you'll understand how MCP works, how it differs from approaches like MCP versus RAG, and why this agentic AI standard for connecting AI, now stewarded by the Agentic AI Foundation under the Linux Foundation, matters so much for connecting AI assistants and AI agents using real capabilities.

If you want to learn:

- How does the MCP architecture work with hosts, clients and servers?

- What are the three common MCP architectures (two local, one remote)?

- What is a local MCP server versus a remote MCP server?

- What do MCP servers actually do with list tools and call tool?

- How do MCP servers wrap an API request and describe it to an LLM in natural language?

- What are real examples like the filesystem MCP server, Fetch, weather, stock prices, Jira and Context7?

Then this lecture is for you!

In this hands-on lecture, you'll get the diagram that pulls the whole MCP architecture together. You'll start with a host running on your computer (Claude Desktop, Codex, Claude Code, or your own AI agent built on an agent framework) and see how it creates one MCP client for every MCP server it wants to use. You'll walk through the three common architectures: two where the MCP client spawns a local MCP server as a separate process on your machine, and one where the MCP client connects over a URL to a remote MCP server running on someone else's box.

You'll then reach the crux of the matter: what these MCP servers actually do. You'll learn that each server exposes two key functions, list tools and call tool, using the same JSON tool descriptions you met in week one to explain parameters and purpose in natural language an LLM can understand. The big insight is that calling a tool very often just means making an API request out to the internet, so the MCP server is really an integration interface that packages an API and describes it in natural language for the AI model.

Finally, you'll ground all of this with concrete examples of MCP servers used across the course: the filesystem MCP server (server filesystem) from Anthropic that works on local files, the Fetch server that requests web pages, and web-request servers for weather and stock prices. You'll also see remote MCP servers like the Atlassian Jira server and Context7. By the end, you'll understand how MCP work flows through host, client and server, and why connecting AI assistants and AI agents to this ecosystem of tools is so straightforward in agentic AI workflows.

If you want to learn:

- What are MCP transport mechanisms and why do they matter?

- What is the stdio (standard IO) transport and when do you use it?

- What is streamable HTTP, and how does it relate to the older SSE transport?

- How do you decide between stdio and streamable HTTP for local versus remote MCP servers?

- What do MCP server parameters look like, and how do command and arguments work?

- How do uvx and npx launch Python and JavaScript MCP servers in isolated environments?

Then this lecture is for you!

In this hands-on lecture, you'll layer the final concept onto the MCP architecture: the transport mechanism, which defines technically how an MCP client and MCP server actually communicate once the model context protocol has told them what to do. You'll learn the two transport mechanisms Anthropic provides. First, stdio (standard IO), the simplest and most common option when you build your own agents, where the MCP client launches a separate process and talks to it over standard input and standard output. Second, streamable HTTP, which uses an internet connection and can stream information back bit by bit, and which has replaced the older SSE transport.

You'll then learn the simple rule for choosing a transport: local MCP servers typically use stdio (though they can use streamable HTTP too), while remote MCP servers must use streamable HTTP or legacy SSE because you cannot spawn a process on someone else's computer. This maps cleanly onto the three architectures, making it easy to know which transport applies to which MCP server.

Finally, you'll demystify MCP server parameters, the dictionary of command and arguments that describes the server you want to connect to. You'll see real examples: the Fetch server using command uvx with mcp_server fetch, the Playwright server using npx with @playwright/mcp:latest, and Context7 described with a URL and timeout for streamable HTTP. You'll understand how uvx (a shortcut for uv tool run) and npx run Python and JavaScript MCP servers in clean, isolated, repeatable environments, plus the option of Dockerized open-source servers. By the end, you'll be ready to plug any MCP server into Claude Code, Claude Desktop, Codex or your own agent framework, ready for agentic integration in your AI workflow.

If you want to learn:

- How do you run your first MCP lab using the OpenAI Agents SDK?

- How do you use an MCP server's list tools function for the first time?

- How do you connect to the Fetch MCP server with stdio parameters and uvx?

- How do you use the Playwright MCP server and the filesystem MCP server in your agent?

- Why are MCP tool descriptions, written by experts at Anthropic and Microsoft, so important?

- How do you handle MCP servers on Windows without WSL?

Then this lecture is for you!

In this hands-on lecture, you'll finally move from theory to doing, starting your MCP journey with the OpenAI Agents SDK. You'll load environment variables, apply a small Windows-friendly hack so MCP servers writing to standard error don't crash your notebook, and then use an MCP server for the very first time. You'll describe the Fetch MCP server using stdio parameters (command uvx, package mcp_server fetch), open it with a context manager, set a generous 60-second timeout for the first uvx download, and call list tools to discover its single fetch tool, reading the expert-crafted description and JSON input schema that teach an LLM how to use it.

You'll then connect to two more MCP servers. You'll set up Node and Playwright, run the Playwright MCP server with npx and @playwright/mcp:latest, and list its rich set of browser-driving tools (navigate, click, fill forms, snapshot, upload). You'll also run the filesystem MCP server (server filesystem) from Anthropic, sandboxed to a subdirectory, and list its read file, list directory and create directory tools. Throughout, you'll see that the real innovation lives in tools like Playwright, while MCP contributes the natural-language prompting that makes those tools usable by an LLM.

By the end, you'll understand exactly how MCP work happens inside an agent framework: how to list tools, configure stdio parameters, and recognize which MCP servers run locally over standard input/output. You'll be ready to equip your own AI agents with these tools and connect AI assistants to a powerful open-source ecosystem of MCP servers in your agentic workflow.

If you want to learn:

- How do you identify the MCP host, MCP client and MCP server in a real agent?

- How does the OpenAI Agents SDK create MCP clients for you automatically?

- How do you give an AI agent multiple MCP servers (Playwright plus filesystem) at once?

- How do you build an agent that browses the web and writes files using MCP tools?

- How do you connect to a remote MCP server like Context7 over streamable HTTP?

- How do you read OpenAI traces to understand what your MCP agent actually did?

Then this lecture is for you!

In this hands-on lecture, you'll pin down exactly what the MCP host, MCP client and MCP server are in a working example. You'll learn that the host is the Jupyter notebook (really the Python kernel) running your agent framework, the MCP client is created for you automatically by the OpenAI Agents SDK whenever you open an MCP server, and the MCP server is the live process spawned by running an npx or uvx command. This makes the model context protocol architecture concrete and removes any lingering confusion about hosts, clients and servers.

You'll then bring it all together by giving an AI agent real capabilities. With a system prompt and a fun task (find a banoffee pie recipe and summarize it to a markdown file), you'll open both the filesystem MCP server and the Playwright MCP server inside a context manager, create an agent with name, instructions, model and the two mcp_servers, and run it with up to twenty turns. You'll watch the agent autonomously browse the internet, accept cookies, jump between websites, and write the recipe to your local sandbox, all powered by MCP tools.

Finally, you'll see how to connect to a remote MCP server using streamable HTTP, equipping an older AI model like GPT-4o mini with Context7 so it can look up the latest APIs and answer accurately. You'll learn to dig into the OpenAI traces to see every list tools call, tool invocation, browser snapshot and Context7 query. By the end, you'll confidently identify and use MCP hosts, clients and MCP servers for connecting AI assistants and AI agents in your own agentic AI workflows.

If you want to learn:

- What are the MCP core concepts, recapped clearly before you build your own MCP server?

- How do the MCP host, MCP client and MCP server fit together?

- What can an MCP server do with list tools and call tool?

- How do the stdio and streamable HTTP transport mechanisms differ?

- How do uvx and npx parameters spawn local MCP servers?

- Why do MCP servers usually run locally even though they wrap remote APIs?

Then this lecture is for you!

In this hands-on lecture, you'll get a focused recap of the Model Context Protocol (MCP) core concepts before you go on to build your own MCP server. You'll revisit the three components of MCP land: the MCP host (Claude Desktop, Claude Code, or your own agentic AI platform), the MCP client it creates for every server, and the MCP server that the client connects to. You'll re-confirm the two things every MCP server does, list tools and call tool, and remember that resources and prompts exist but tools dominate real-world usage.

You'll reinforce the mental picture with the Fetch server example, recalling how a framework like the OpenAI Agents SDK handles the MCP client for you so you only supply parameters. You'll review the two transport mechanisms, stdio (standard input-output) for local servers and streamable HTTP (which replaced SSE) for remote servers, and the rule for when each applies. You'll also revisit the crucial insight that an MCP server is often a wrapper around an API, turning it into natural-language tool descriptions an LLM can understand, even though the server itself usually runs locally on your box.

Finally, you'll decode the MCP server parameters once more: command uvx plus a package name for Python servers, command npx plus a package name for Node servers, and a simple endpoint URL for streamable HTTP. By the end, this recap will have everything fresh so that building an MCP server and using MCP in your AI agent workflow feels natural for any developer.

If you want to learn:

- Why would you build your own MCP server, and when should you not?

- How do you decide between building an MCP server and just writing a tool?

- Why is conflating building tools with building an MCP server a common mistake?

- How do enterprises use MCP servers to share a large library of tools across teams?

- Why does MCP add a process boundary and technical complexity you may not need?

- When is building an MCP server worthwhile for educational and plumbing reasons?

Then this lecture is for you!

In this hands-on lecture, you'll tackle the honest question behind the hype: why build your own MCP server? You'll learn the genuinely good reasons, contributing a useful set of tools so others can plug them straight into their agents, standardizing a large library of tools across an enterprise that uses multiple programming languages and teams, and the purely educational reason of understanding the plumbing. You'll see how publishing tools as MCP servers can make a sprawling toolset consistent and simple for every developer in a company to use.

Just as importantly, you'll learn the one strong reason not to build an MCP server. Many people, caught up in the MCP hype, conflate building tools with building an MCP server and reach for MCP when all they really need is a plain function. You'll be reminded how trivial it is to make a tool in Python: add docstrings, drop the @function_tool decorator on top if you are using the OpenAI Agents SDK, and pass it in. The innovation is the tool itself, not MCP.

You'll understand that MCP is the right choice for sharing somebody else's tools, but that wrapping your own tool in an MCP server needlessly adds a process boundary, moving parts and complexity. Then, with that caveat clearly stated, you'll see why this course deliberately breaks its own advice to build an MCP server anyway, as an educational exercise to learn how agentic ai plumbing really works. By the end, you'll know exactly when to use MCP and when to keep things simple for building AI agents.

If you want to learn:

- How do you browse MCP marketplaces like Glama and Smithery?

- How do you find popular MCP servers by weekly downloads and uses?

- How do you build your own MCP server with FastMCP from Anthropic?

- How do you wrap an Account Python module as an accounts MCP server?

- How do you turn a function into an MCP tool with natural-language descriptions?

- How do you reuse the account.py module written by your week-three engineering crew?

Then this lecture is for you!

In this hands-on lecture, you'll open Cursor and begin by browsing MCP marketplaces where you can discover MCP servers to plug into your AI agent. You'll tour Glama, an MCP directory you can browse and filter, and Smithery, another popular catalog, spotting familiar servers like Context7, Tavily and Google Sheets ranked by uses and weekly downloads. You'll see how to filter by category (such as searching), surface popular servers like Firecrawl, and copy the npx STDIO parameters you need to attach a server to your agent.

Then you'll build an MCP server of your own. You'll import the Account class from a backend account.py module, which was actually written by the crew engineering team back in week three, and exercise it: create an account, buy AMZN shares, run a report, and list transactions. With the tool logic in place, you'll create accountserver.py from scratch and use FastMCP from Anthropic (imported from mcp.server.fastmcp) to stand up an MCP server named accounts_server that runs over stdio transport, much like a FastAPI app but for MCP.

Finally, you'll define your first MCP tool, get_balance, delegating into the Account module while adding the all-important natural-language prompt description that tells an LLM how and when to call it. By the end, you'll understand how building an MCP server really works, how FastMCP exposes list tools and call tool using the model context protocol spec, and how a developer can wrap any Python code as reusable agentic ai tools.

If you want to learn:

- How do you use your own MCP server with an AI agent?

- How do you set parameters to run a local MCP server with uv run?

- How do you list the tools your custom accounts MCP server exposes?

- How do you connect an LLM to your MCP server and have it call a tool?

- How do you confirm tool calls by reading the OpenAI traces?

- How do you build a simple MCP server, like a Pushover push-notification server?

Then this lecture is for you!

In this hands-on lecture, you'll connect the dots and use your own MCP server with a real AI agent. After finishing the accounts MCP server with tools like get_balance, get_holdings, buy_shares, sell_shares and change_strategy (plus a couple of optional resources), you'll return to the lab and define the parameters to launch it. Because it is just Python code on your own machine, you skip uvx and simply use uv run with the backend account_server module. You'll then open it with the standard input output context manager, set a timeout, and call list tools to confirm your server exposes exactly the tools you wrote.

Next you'll prove the most important part of MCP, calling a tool. You'll write instructions for an agent that manages an account, pass in your MCP server, create the agent with a model, and run a request like "My name's Ed, what's my balance and holdings?" You'll watch the agent decide to call get_balance and get_holdings and return that it holds three Amazon shares, then verify everything by reading the OpenAI traces, where seeing your own MCP server listed and invoked is genuinely satisfying.

Finally, you'll get a fun challenge to build a simple MCP server of your own, one that sends a push notification via the Pushover app, with pushserver.py provided as a hint. By the end, you'll know the full workflow for building an MCP server and wiring it into agents using MCP, completing the picture of building AI agents that consume MCP tools through the model context protocol.

If you want to learn:

- What is context engineering and how does it relate to MCP servers?

- What are the four MCP configurations, including hosted/managed MCP tools?

- Why should you keep hosted MCP tools at arm's length to stay model-agnostic?

- How do short-term memory, long-term memory and RAG fit into the context?

- How does agentic RAG use tools to retrieve information by meaning?

- How do you choose an MCP integration and transport in the OpenAI Agents SDK?

Then this lecture is for you!

In this hands-on lecture, you'll open the big topic of context engineering with MCP servers, including a first look at agentic RAG. You'll start with a tight recap of the MCP architecture and its configurations: a local MCP server over stdio, a local server that calls out to an API, and a remote MCP server like Atlassian's Jira. Then you'll meet a fourth pattern, hosted or managed MCP tools, where OpenAI runs the MCP client and server during inference, and you'll learn why to keep it at arm's length since it ties you to OpenAI's proprietary API and LLMs.

You'll explore the OpenAI Agents SDK documentation's Model Context Protocol integration matrix, comparing hosted MCP tools, streamable HTTP servers, legacy SSE, and the very common stdio transport, and understand which to reach for. Then you'll dig into context engineering itself via Phil Schmid's seminal write-up: packing the best possible information, tools and prompt into the LLM context. You'll see how the system prompt, short-term memory (conversation history), long-term memory (databases), RAG retrieval, tools and structured outputs all overlap.

You'll learn how RAG uses semantic, vector-based retrieval to retrieve information whose meaning is close to the question, and how agentic RAG puts that retrieval into tools an AI agent can call. By the end, you'll understand the architecture of a modern AI system built around context engineering, how memory and RAG overlap, and why MCP servers are such a powerful way to integrate context into your agentic workflow.

If you want to learn:

- How do you give an AI agent long-term memory with an MCP server?

- How does Anthropic's memory MCP server store entities, relations and observations?

- What is the difference between short-term memory and long-term memory for agents?

- How do you add free web search to an agent with the Tavily MCP server?

- How do you limit an agent to a single tool with a static tool filter?

- How do you confirm memory storage and retrieval by reading the traces?

Then this lecture is for you!

In this hands-on lecture, you'll put context engineering into practice, starting with long-term memory for an AI agent built on an MCP server. You'll recall how week two added short-term memory with a session object to track conversation history, then go bigger by using Anthropic's reference memory MCP server (an npx node server) that persists to a memory.json file. You'll list its tools, createEntities, createRelations and addObservations, and see that it is effectively a lightweight graph database of entities, relationships and observations.

You'll then have an agent (using GPT-4o mini) store facts about you, your AI agents course and the MCP protocol, watch memory.json fill with JSONL objects, and prove retrieval works by starting a fresh conversation and asking "what do you know about me?" You'll read the traces to see createEntities, createRelations and a search of nodes, confirming the server genuinely stored and recalled long-term memory, a core piece of any context engineering architecture.

Next you'll add web search, swapping OpenAI's paid hosted tool for the free Tavily MCP server (npx tavily-mcp with a TAVILY_API_KEY). You'll list its tools (search, extract, crawl, map, research), then use create_static_tool_filter to allow only tavily_search so your agent stays focused. You'll research Amazon's stock outlook, passing the current date for context, and verify the Tavily search in the traces. By the end, you'll know how to integrate memory and search MCP servers to retrieve the right context for your AI system.

If you want to learn:

- What is agentic RAG and how does it differ from traditional RAG?

- How do you use the Qdrant vector MCP server (mcp-server-qdrant) for retrieval?

- How does the Qdrant MCP server run locally with no API key and store vectors?

- How do the qdrant-find and qdrant-store tools work?

- How do you build a researcher agent that stores facts and recalls them by meaning?

- Why does MCP make building a RAG pipeline so much easier?

Then this lecture is for you!

In this hands-on lecture, you'll build agentic RAG using the Qdrant vector MCP server. You'll first nail down the concept: traditional RAG turns a question into a vector and retrieves stored information whose meaning is closest, while agentic RAG puts that vector retrieval into tools an AI agent can call itself. You'll meet mcp-server-qdrant, an open-source vector data store (like Chroma) that runs locally with no API key, persisting to a memory/qdrant folder and using the popular Hugging Face all-MiniLM-L6-v2 encoder locally to vectorize text.

You'll configure the Qdrant MCP server parameters with uvx, a storage path and a collection name (knowledge), then list its two tools: qdrant-store to keep memories and qdrant-find to look them up. You'll create a researcher agent equipped with both the Tavily search server and the Qdrant vector server, instruct it to research the latest Nvidia news and store key facts, and run it so it writes vectorized takeaways into the data store.

Then you'll prove the rag system works by giving a second agent only the Qdrant vector store, no internet, and asking what it knows about Nvidia. You'll watch it retrieve semantically similar information and confirm it in the traces (Tavily search, then qdrant-store, then qdrant-find). You'll appreciate the big takeaway: building a full RAG pipeline is normally hard, but with the Qdrant MCP server you only need the parameters. By the end, you'll know how to integrate agentic RAG into an AI agent workflow with mcp servers.

If you want to learn:

- How do you get real-time market data with an MCP server?

- How do you use the Massive (formerly Polygon.io) market-data MCP server?

- How do you install an MCP server straight from a GitHub repo with uvx --from?

- What is the simulated market fallback when you have no Massive API key?

- What is progressive disclosure, and why expose meta-tools that explore an API?

- How do you read traces to see an agent search endpoints and call the right API?

Then this lecture is for you!

In this hands-on lecture, you'll wire up the juiciest MCP server of the week: a market data server from Massive (formerly Polygon.io) that streams real-time share prices into an AI agent. You'll learn it offers a free tier, and that the whole thing is optional, because if no MASSIVE_API_KEY is set, the project falls back to a simulated market server that generates fake but natural-moving prices. You'll see how to install Massive directly from its official GitHub repo using uvx --from, passing your API key to the MCP server.

You'll then explore an innovative pattern this server uses. Instead of exposing one tool per API endpoint (get_share_price, financials, technical indicators), Massive goes meta, giving the agent tools to search and explore the API itself, then call the right endpoint. This is progressive disclosure, the same thinking behind skills: don't pollute the agent's context with every option, let it discover the tool it needs. You'll understand how this keeps the context clean, makes the agent more coherent, and produces more predictable outcomes, with experimentation as the way to find the right balance.

You'll ask the agent for Apple's most recent traded price, see it return an accurate after-hours figure, and read the traces to watch it search endpoints, read the docs, and call the last-trade API. By the end, you'll know how to integrate a real-time market data MCP server (or its simulated fallback) into your agentic workflow, and you'll be ready for the Equity Traders capstone, where these mcp servers come together into an AI system.

If you want to learn:

- What is the Autonomous Traders capstone and how does it use MCP servers?

- How do you build a trading floor of autonomous AI agents?

- How many MCP servers and tools power this AI trading capstone?

- When do you orchestrate agents by code versus by LLMs?

- Why must you evaluate the decisions an autonomous AI agent makes?

- Why should AI trading agents only be used for educational purposes?

Then this lecture is for you!

In this hands-on lecture, you'll kick off the capstone final project: Autonomous Traders, an autonomous AI trading floor where a team of AI agents trade in a virtual market powered by a slew of MCP servers. You'll learn the six standout features of this capstone, starting with the fact that it is genuinely commercial, applied to a specific industry vertical, financial services, rather than being a general or purely technical agentic project. This makes it a template you can adapt to build ai agents for your own business vertical.

You'll see how the model context protocol enables this AI trading system: six different MCP servers representing seventeen tools, including the higher-level market data tools from Massive that keep the context efficient. You'll revisit a key distinction from earlier weeks, orchestrating by code versus orchestrating through LLMs, and learn that this project does both: LLM orchestration via the OpenAI Agents SDK as_tool pattern for autonomy, and Python code orchestration for reliable, repeated workflow steps. You'll understand the balance between autonomous decision-making and predictable outcomes.

Crucially, you'll learn the agentic trap this project highlights: just because an agent can generate believable trade ideas does not mean they are good trades, so you must evaluate and feed back results so the agent improves over time. By the end, you'll understand the architecture and ambitions of this autonomous AI capstone, and the firm caveat that, because neither you nor the LLMs are authorized financial professionals, this ai-powered trading system is strictly for educational purposes and never for real trading decisions.

If you want to learn:

- How do you build the Autonomous Traders using six MCP servers?

- How does the trader agent use accounts, push notification and market-data MCP servers?

- How does a researcher agent become a tool via the OpenAI Agents SDK as_tool pattern?

- How do four trader agents get orchestrated by Python code on a loop?

- How do you confirm 6 MCP servers and 17 tools, and read the trading traces?

- How do trader agents named after trading legends run different strategies?

Then this lecture is for you!

In this hands-on lecture, you'll start building the Autonomous Traders capstone with MCP servers. You'll assemble the cast: the homemade accounts MCP server (built on the week-three CrewAI account logic), a Pushover push-notification server, market data that uses Massive if you have an API key and a simulated fallback otherwise, plus Fetch, Tavily search and a memory knowledge-graph server. You'll walk through the agent architecture, a trading floor with four trader agents, each managing its own account, strategy, push notifications and market data, and collaborating with a researcher agent.

You'll learn why the trader and researcher are separate agents (different prompts, missions and tools, the result of context engineering rather than mimicking human roles) and how the trader uses the researcher as a tool via the OpenAI Agents SDK as_tool function, an example of LLM orchestration. You'll set up four traders named after trading legends (Warren, George Soros, Ray Dalio, Cathie Wood), each starting with $10,000 and a distinct strategy via reset_traders, and inspect Warren's balance and value-investing strategy.

You'll then list every tool, confirming six MCP servers with seventeen tools, run the researcher to fetch the latest Amazon news with Tavily, turn it into a tool, and let the trader decide whether to trade, receiving a real-time push notification with its reasoning. You'll dig into the traces to watch get_balance, the researcher call, Tavily searches, fetches, memory writes, Massive API calls and the final notification. By the end, you'll know how model context protocol enables a working autonomous AI trading team.

If you want to learn:

- How do you organize MCP servers cleanly in an agent project?

- How do you separate prompts, tools and MCP servers into modules like mcp_servers.py and templates.py?

- How do trader_mcp_servers and researcher_mcp_servers assemble their parameters?

- Why give each researcher agent its own libsql memory database?

- How do you restrict Tavily to search-only with a tool filter?

- How do you turn a researcher agent into a tool the trader can call?

Then this lecture is for you!

In this hands-on lecture, you'll learn how to organize MCP servers in a real agent project so the codebase stays clean and maintainable. You'll explore the mcp_servers.py module and the recommended practice of separating prompts (into templates.py), tools and MCP server definitions. You'll see how the code checks for a Massive API key to choose between the real market data server and the simulated fallback, then how two functions, trader_mcp_servers and researcher_mcp_servers, collect their parameters and create an MCP server over stdio for each with a generous 120-second timeout.

You'll understand the three MCP servers behind each trader (accounts, push notification, market data) and the three behind each researcher (Fetch, Tavily, and memory). For memory you'll learn why the project upgrades to a libsql-backed memory server instead of a JSON file, so multiple autonomous agents can run in parallel without file conflicts. You'll see why researcher_mcp_servers takes the agent's name: each of the four traders gets its own memory database so their research stays separate and their strategies remain in genuine competition.

Finally, you'll restrict Tavily to search-only with a tool filter, open all the MCP servers together with a clean Python context-management pattern, and run a researcher query on Amazon news. You'll then convert the researcher into a tool via get_researcher_tool and the OpenAI Agents SDK as_tool function, giving it a name and description so the trader agent can call it. By the end, you'll know how to structure mcp servers, prompts and tools for a maintainable autonomous AI trading project that uses MCP at its core.

If you want to learn:

- How do you orchestrate a whole trading floor of AI agents?

- How does the trading_floor module run four traders in parallel with asyncio.gather?

- How do .env settings control run interval, market-closed runs and model choice?

- How do you bring the autonomous traders to life in a Gradio UI dashboard?

- How was the Gradio front end built with help from Claude Code?

- How do you read each trader's performance, holdings and traces in the dashboard?

Then this lecture is for you!

In this hands-on lecture, you'll orchestrate a full trading floor of autonomous AI agents. You'll study traders.py and the short, prompt-driven trading_floor module, a clean example of orchestrating by Python. You'll see the infinite loop that, when the market is open (or when configured to run even when closed), uses asyncio.gather to run all four traders in parallel rather than one at a time, with each trader autonomously kicking off its researcher tool. You'll learn the three .env settings that control behavior: run every N minutes (default 60), run even when market is closed, and use many models, which switches between GPT-4o mini and a mix of top and middle-tier models configured in traders.py.

You'll then bring everything to life visually, because traces alone are not enough, you need real observability. You'll launch a Gradio front end with uv run app.py from the week-six folder. The Gradio UI lives in a demo folder (Gradio is a prototype-style UI) and was built half by the instructor and half by Claude Code, which polished the styling. You'll see the dashboard list all four traders, Warren, George Soros, Ray Dalio and Cathie Wood, with performance charts, generation and tool-use traces, holdings and recent transactions.

You'll review more than a year of real results, where Soros nearly tripled his $10,000, while noting honestly that a rising market (and heavy semiconductor positions like Nvidia) likely drove the gains. By the end, you'll know how to orchestrate AI agents on a trading floor, execute their autonomous decisions, and observe an AI-powered trading mcp server system in a live Gradio dashboard, ready to make the capstone your own with extra MCP servers.

If you want to learn:

- How do you finish the Autonomous Traders capstone with three key improvements?

- How do you add observability with a custom OpenAI Agents SDK trace processor?

- How do you log agent traces to a SQLite database with a LogTracer?

- How do you add evaluation and feedback so trading agents improve over time?

- How does the change_strategy tool let an agent evolve its own strategy?

- Where do the trader and researcher prompts live in templates.py?

Then this lecture is for you!

In this hands-on lecture, you'll finish the Autonomous Traders capstone by adding three improvements to the multi-agent AI trading system. First, you'll improve observability by customizing the OpenAI Agents SDK tracing. In traces.py you'll create a LogTracer subclass of TracingProcessor, implementing on_trace_start, on_trace_end, on_span_start and on_span_end to capture activity and write it to a SQLite database. You'll register it in trading_floor.py with add_trace_processor, so your AI workflow surfaces the right level of detail to a UI or admin dashboard instead of relying only on OpenAI's traces.

Second, you'll add evaluation and feedback, the idea that an LLM generating plausible trade ideas is not the same as accurate ones, so you measure against a real-world objective: portfolio returns. In account_server.py you'll see the change_strategy tool that lets each AI trading agent record a new investment strategy, and in templates.py you'll explore the trader, researcher and rebalance prompts. The rebalance message asks the agent to review how its holdings performed and fold those lessons into an evolving strategy.

You'll be encouraged to iterate hard on these prompts yourself, since experimentation is where you learn what moves the needle for different models. By the end, you'll understand how to wire observability, evaluation and a feedback loop into a multi-agent ai trading system built on mcp servers, completing the back-end logic that lets your autonomous traders use MCP tools and improve over time.

If you want to learn:

- How do you go from a Gradio demo to a production-ready full-stack AI app?

- How do you add a FastAPI back-end API (api.py) for the trading floor?

- How do you build a Vite and TypeScript front end with Claude Code?

- How do you run the API, the front end and the trading floor together?

- How do you launch the multi-agent trading system and watch agents make decisions live?

- How do agents evolve their own strategies based on real-world results?

Then this lecture is for you!

In this hands-on lecture, you'll take the capstone from a Gradio demo toward a production-ready, full-stack AI application. You'll learn that fully deploying such an app is largely DevOps (covered in a separate production track), but that a proper capstone deserves a real front end. So you'll add a third improvement: a lightweight back-end API in api.py, a FastAPI web server exposing routes for holdings, traders, market data, trader details and log messages. You'll run it with uv run uvicorn backend.api:app on port 8000, giving any front end a clean API to call into the trading system.

You'll then bring up a professional Vite and TypeScript front end that Claude Code wrote (with a Claude Design layout), since front-end work is exactly what claude code excels at. You'll launch it with npm run dev and see a polished dashboard: four traders, Warren, George, Ray and Cathy, each running a different model (GPT-5, DeepSeek, Gemini, Grok), with returns, an activity feed for observability, recent trades, and a holdings heat map.

Finally, you'll deploy the live experience by running the trading floor with uv run -m backend.trading_floor, watching the multi-agent ai team come to life, install MCP servers, run Tavily searches, call tools, make buy and sell decisions, and send Pushover notifications. By the end, you'll know how to wrap a multi-agent system in a FastAPI back end and a real front end, run the full trading workflows, and watch your AI trading agent team evolve their own strategies, all powered by mcp and the model context protocol.

If you want to learn:

- How do you read AI agent traces to understand a multi-agent trading system?

- What does observability reveal that a UI activity feed cannot?

- Why did one trader make 58 tool calls and use its researcher twice?

- How does orchestrating with LLMs produce richer, more autonomous behavior?

- How do you use traces to debug and verify what your agents actually did?

- How can you extend the capstone with more MCP servers or a new business area?

Then this lecture is for you!

In this hands-on lecture, you'll put a lid on the Autonomous Traders capstone by going deep on observability through traces. While the activity feed you surfaced to the front end gives end users a sense of what is happening, the real depth lives in the OpenAI traces. You'll open the four trader traces and see just how much work went on, in particular how George racked up 58 tool calls in total and chose to call its researcher tool twice, behavior that emerged precisely because the agent was autonomous rather than orchestrated by code.

You'll learn what this teaches about the trade-off between orchestrating with LLMs and orchestrating with code: LLM orchestration allows more interesting, flexible behavior and potentially better outcomes, while code orchestration would have pinned down a single researcher call. You'll scroll through pages of tool calls, queries and MCP tool use, pressing Load more repeatedly, and use the traces as the definitive way to understand and debug what your multi-agent AI trading agents actually did behind the scenes.

Finally, you'll receive your capstone challenge: make the project your own. You can extend the trading system with more mcp servers (Playwright, Qdrant, or anything from the MCP marketplaces), strengthen the feedback loop, and experiment for better virtual returns, or apply the same four-agents-with-researchers pattern to a completely different business area you know well, one with measurable real-world outcomes. By the end, you'll know how to use observability and traces to verify an agentic ai trading workflow and how to evolve this ai trading agent project into something uniquely yours.

If you want to learn:

- How do you choose the right agent framework for your project?

- Why does the choice of agent framework matter less than you think?

- What are the ten things that actually matter when building agentic AI?

- Why should you orchestrate with code first and add LLM autonomy later?

- Why start with one LLM call and a big model before scaling down?

- Why does iterating on prompts and reading traces matter so much?

Then this lecture is for you!

In this hands-on lecture, you'll get the answer to the question students ask most: which agent framework should I pick? The honest answer is that it does not matter that much, the frameworks can do broadly the same things, so choose the one that suits you and your team. You'll hear the instructor's own go-to (OpenAI Agents SDK with lots of MCP servers), along with appreciation for Google ADK and LangChain Create Agent, and the note that higher-level harnesses like LangChain Deep Agents and the Claude Agent SDK are a different beast reserved for specific problems.

You'll then learn the ten things that truly matter when building an AI system. Focus on the business problem, not the solution. Make sure you can measure success with a real-world outcome. Favor a workflow orchestrated with code as your baseline before adding multi-agent autonomy with LLMs, since most production agentic ai is more workflow than true autonomy. Work bottom-up, start simple with one LLM call, and begin with a big model before scaling down to cheaper ones to deploy affordably.

Finally, you'll learn to think broadly about context engineering rather than jumping straight to memory, to iterate relentlessly on your prompts, and to always read the traces so you catch agents inventing answers or skipping tools. You'll hear why success means being both engineer and scientist, doing the R&D, and enjoying the experimentation. By the end, you'll know how to choose a framework and, more importantly, how to build reliable AI systems and trading workflows that you can confidently take toward production.

If you want to learn:

- What does the full agentic AI journey across all six weeks look like?

- How did the course progress from native LLM calls to a multi-agent trading floor?

- How do the frameworks (OpenAI Agents SDK, CrewAI, LangGraph, Create Agent) fit together?

- How does MCP tie the whole agentic AI course together?

- What is your first mission after completing the course?

- How can you extend the Autonomous Traders capstone and share your work?

Then this lecture is for you!

In this hands-on lecture, you'll wrap up the entire agentic AI engineering track with a celebratory tour of your journey. You'll revisit week one, calling LLMs directly to build a digital twin career agent, week two with the OpenAI Agents SDK, an SDR and a deep research app deployed to Gradio, and week three with CrewAI and the engineering team that produced the very account logic reused in this capstone. You'll recall the LangGraph and LangChain Core abstractions, the Create Agent sidekick, and week five's whirlwind tour of agent frameworks that revealed how similar they all are.

You'll then look back on week six and MCP, recognizing how the model context protocol that once felt overwhelming, the two transport mechanisms, the three architectures, the host, client and server, now feels like old hat. You'll see how it all culminated in the multi-agent AI trading floor, an autonomous trading system built on many mcp servers, and feel the satisfaction of becoming an agentic engineer who can build real agentic ai systems.

Finally, you'll receive your first mission: extend the AI trading simulator with more MCP servers and agents for greater autonomy, or redirect the whole pattern to a different business vertical with measurable outcomes. You'll be encouraged to share your project and your certificate on LinkedIn, support fellow students, and rate the course. By the end, you'll have a clear map of everything you learned, from a single LLM call to a production-minded multi-agent system that uses MCP, and the confidence to go forth and build great AI systems.