CoursesProFirst lesson free34 min of video

Build a Multi-Agent System with MCP

One agent with every tool makes a good demo; a team of agents with one job each is what holds up at work. Most multi-agent setups break at the hand-off: context is lost, two agents repeat the work, or one calls a tool it should never touch. Live, I build a planner, an engineer and a reviewer with the OpenAI Agents SDK, each scoped through an MCP gateway, taking one issue from plan to pull request.

The lessons, in order

Each lesson is one idea from the live build, cut to a few minutes, with chapters and the full transcript. The first is free once you sign in; Pro opens the rest.

  1. 1

    When to use one AI agent or a team of agents

    One AI agent or a team of agents? An AI agent takes a purpose and works toward an output. This lesson shows when a linear workflow is enough, and when an open-ended task needs a coordinator agent with subagents. It then reads Anthropic's advice to stay with a single agent unless you need a separate context, because a team of agents costs more tokens.

    Free5:27
  2. 2

    What happens inside an AI agent loop, and where MCP fits

    The AI agent loop is simple: the model picks a tool, calls it, checks the result and goes again until the goal is met. Learn how tool calling works and why tool calling stops working well when your API has hundreds of endpoints. See how an MCP server (Model Context Protocol) lists only the tools your agent may call, and why max turns ends the loop with a hard stop.

    4:25
  3. 3

    Give each AI agent one job and only its tools

    Give each AI agent one job and only the tools that job needs. Using a travel booking desk as the example, this lesson splits one agent with every permission into a planner, a booker and a messenger. Then it enforces the split in an MCP gateway that checks permission on every tool call.

    6:32
  4. 4

    Your AI agent needs the same auth as a person

    AI agents need the same auth as the people they act for. Authentication, authorization and boundaries work the same whether a person clicks in a portal or an agent calls a tool. Learn to map who may approve what, check roles with RBAC or ABAC before an approval, and borrow escalation from ticket triage.

    8:15
  5. 5

    Ship an AI agent like an API with timeouts and traces

    Ship an AI agent like an API. Frameworks like LangGraph, Google ADK or the Claude SDK get you started, but you still own how the agent runs. That means timeouts, tracing, monitoring and evals. Learn to set a timeout per agent, read traces by hand, weigh token cost against quality and rerun evals on every release.

    4:36
  6. 6

    Long-running AI agents should wait, not run

    Long-running AI agents should wait, not run. When an agent needs a human approval that may take a weekend, it should stop, store its memory and context, and resume when an event arrives. It is the same async pattern you already use to send an email through Pub/Sub, applied to agents.

    4:29

What the course covers

Engineers whose single agent has outgrown one prompt and one tool list, and architects deciding whether a multi-agent design is worth its cost.

Split one agent into roles with one job each
A planner, an engineer and a reviewer, each with its own prompt and model.
Scope each agent's tools through an MCP gateway
Each agent calls only the tools its role needs, and every call is logged.
Decide when a second agent pays for itself
Compare the team with a single agent on quality, latency and token cost.