Français
Applied AI · Intermediate 🟡 · Session 7
📝 Teacher's Guide
← Return to program 📄 Source .md

Teacher Guide — Session 7: Multi-agents & MCP

Program : Applied AI — Intermediate Level Instructor: Yann Isola Duration : 2 hours (120 minutes) Module covered: Module 5 — Multi-agents & MCP (Model Context Protocol)

1. Session overview

Educational objectives

At the end of this session, each participant should be able to:

  1. Explain why split a monolithic agent into several specialized agents : separation of responsibilities — each agent has her system prompt, his tools, his guardrails.
  2. Name and recognize the 4 multi-agent patterns : orchestrator/worker, pipeline, debate/consensus, supervisor.
  3. Choosing the right boss for a given business case, and justify this choice in one sentence.
  4. Describe the 3 modes of communication between agents : shared memory, message passing, blackboard architecture.
  5. Define MCP (Model Context Protocol): a universal standard for connecting AI (artificial intelligence) models to tools and data sources.
  6. Draw the MCP architecture : Host (your application) ↔ Client (inside the host) ↔ Server (which provides tools and resources).
  7. Distinguish the 3 MCP primitives : Tools (actions invoked by the model), Resources (data controlled by the application), Prompts (reusable models).
  8. Mention the 2 MCP transports : stdio (standard input/output, standard input/output — for local) and HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, events sent by the server — for remote).
  9. Explain the “USB of AI” analogy : a single protocol to plug any model into any tool provider, instead of N×M custom integrations.
  10. Sketch a homemade MCP server : expose your business logic in the form of standardized tools.

Prerequisites

Necessary equipment

Central message of the session

“A single agent is an employee who does everything. A team of specialized agents is a company: each one has their role, their tools, their limits. And MCP is the USB port that allows any employee to plug in any tool — without rewiring each time. »

Repeat this double idea (team + universal socket) at least three times in different forms.

Narrative thread: NewsRoom 📰

The entire session is based on a threaded example: NewsRoom , a monitoring and writing system for a finance team. The typical mission:

“Every morning, produce a 500-word summary of stablecoin news: sourced, verified, proofread, and published on the internal channel. »

NewsRoom agents:

NewsRoom illustrates each boss: in pipeline (Researcher → Editor → Checker → Publisher), in orchestrator (a chief editor distributes), in debate (two Editors propose, a judge decides), in supervisor (a controller monitors and takes control). Then, in the second hour, MCP answers the question: “how do all these agents access their tools without me coding 12 integrations?” »

2. Rolled out minute by minute

Hourly Duration Sequence Support
0:00 – 0:05 5 mins Welcome, reminder Session 6 (the loop), objectives Slides 1–3
0:05 – 0:20 15 mins Sequence A — Why multiple agents? Separation of responsibilities Slides 4–7
0:20 – 0:40 20 mins Sequence B — The 4 bosses: orchestrator, pipeline, debate, supervisor Slides 8–13
0:40 – 0:55 15 mins Sequence C — Manipulation: architecture viewer (drag and drop + animated flows) Webpage (tab 1)
0:55 – 1:05 10 mins ☕ Break —
1:05 – 1:15 10 mins Sequence D — Communication between agents: shared memory, messages, blackboard Slides 14–16
1:15 – 1:35 20 mins Sequence E — MCP: the N×M problem, the Host/Client/Server architecture, the 3 primitives Slides 17–24 + webpage (tab 2)
1:35 – 1:45 10 mins Sequence F — Build your own MCP server + existing ecosystem Slides 25–27
1:45 – 1:55 10 mins Flash exercise in pairs (Exercise 1) Exercises
1:55 – 2:00 5 mins Express oral quiz, exit tickets, announcement Session 8 Quiz + slides 28–29

⏱️ Safety margin: Sequence F can be compressed to 5 minutes (the MCP server catalog is on the webpage). Don't sacrifice Never Sequence E: if the participants leave without understanding Host ↔ Client ↔ Server, the session has missed its second half. In the event of a serious delay, Exercise 1 becomes homework.

3. Detailed notes by sequence

Sequence A — Why multiple agents? (15 mins)

Objective : bring out the multi-agent need from the limits of a single agent.

Hook (3 min). Start from Session 6: “You know how to build an agent. So let's build NewsRoom in ONE agent: a giant prompt system that says “search, write, check, publish”, with the 4 families of tools. What will go wrong? » Let the room search. Expected (or expected) answers:

The principle (5 min). State it separation of responsibilities (separation of concerns): each agent has…

  1. Its prompt system — a single, clear mission, without contradictions.
  2. His tools — only those he needs (reminder Session 5: principle of least privilege).
  3. Its safeguards — the Publisher has a human checkpoint; the Editor does not need it.

Threaded analogy: the company . We don’t hire a single person to do accounting + sales + legal + IT. Not because it’s impossible — because it is fragile . One specialist per field, each with their own access (the accountant has the key to the safe, not the marketing intern).

Important nuance (4 min). As in Session 6 (“agency is a property of the system”), insist: the 4 agents of NewsRoom can rotate on the same model (same Claude, same GPT). What changes between them: the system prompt, the list of tools, the safeguards. Multi-agent ≠ multi-model. (We can mix models — small, quick model for the Researcher, large model for the Editor — it’s a refinement, not the definition.)

Counterpoint to install early (3 min). Multi-agent is not free: more calls to the model (cost, latency), more coordination, more points of failure. Golden rule, symmetrical to Session 6: if one agent is enough, don’t use four. We'll come back to this at the end of the session.

Sequence B — The 4 multi-agent bosses (20 min)

Objective : that each participant knows how to draw the 4 patterns and cite a use case for each.

For each pattern: drawing on the board (or slide), carried out with NewsRoom, typical use case, main limit. About 5 minutes per boss, debate/consensus and supervisor can be grouped together if time runs out.

1. Pipeline/chain (simplest).

Chercheur → Rédacteur → Vérificateur → Publieur

2. Orchestrator/worker — the most common.

            ┌────────────────┐
            │ ORCHESTRATEUR  │  (décompose, distribue, assemble)
            └──┬────┬────┬───┘
               ▼    ▼    ▼
          Chercheur Rédacteur Vérificateur

3. Debate/consensus.

Rédacteur A ──┐
              ├──▶ JUGE ──▶ meilleure version (ou synthèse)
Rédacteur B ──┘

4. Supervisor.

        ┌──────────────┐
        │  SUPERVISEUR │  (observe, valide, interrompt, réassigne)
        └──────┬───────┘
          surveille
   ┌───────┼─────────┐
   ▼       ▼         ▼
 Agent 1  Agent 2  Agent 3   (qui travaillent, éventuellement en pipeline)

Summary (2 min). Summary table (slide 13):

Boss Who decides the flow? Strength Weakness
Pipeline The developer (fixed) Simple, predictable, debuggable Rigid
Orchestrator The orchestrator (dynamic) Flexible, parallelizable Central neck
Debate The judge / the vote Cross-check reliability Cost ×N
Supervisor Agents + continuous monitoring Security, compliance Complexity

Sequence C — Manipulation of the viewer (15 min)

Objective : anchor patterns through manipulation.

Open webpage/index.html , tab “Multi-agent architectures”. Participants (in pairs if mobile phones are available, otherwise you on the video projector with the room guiding):

  1. Choose a boss (pipeline, orchestrator, debate) — the board displays the boss's locations.
  2. The agents slip of NewsRoom (Researcher, Editor, Reviewer, Publisher, Judge, Orchestrator) in locations.
  3. Start the animation : messages flow along the arrows, with the content of each message displayed in the log (“Researcher → Editor: 5 sources found…”).
  4. Button “Inject an error” : The Reviewer rejects the draft — observe how each boss handles the rollback (the pipeline shows this explicitly).

Instructions to give: “Place agents for the pipeline boss, launch, then respond: When does the Publisher receive anything? What happens if the Verifier rejects? » Then do it again as an orchestrator and compare the number of messages exchanged.

Debrief (3 min): have a participant verbalize the pipeline/orchestrator difference. The correct wording expected: “in the pipeline, the path is fixed in advance; with the orchestrator, it is an agent who decides the path. »

Sequence D — Communication between agents (10 min)

Objective : know the 3 mechanisms by which agents exchange, with their compromises.

1. Message passing. Each agent explicitly sends messages to other agents (like internal emails). This is the natural mechanism of the pipeline and orchestrator.

2. Shared memory. All agents read and write in a common space (the complete history, a database, a shared document).

3. Blackboard (blackboard). Structured refinement of shared memory: a common space organized (sections, statuses) where each agent submits their contributions and is triggered when information that concerns them appears.

To say to summarize: “Messages = company emails. Shared memory = the common network folder. Blackboard = the whiteboard of the crisis room. All three exist in your human organizations — it’s exactly the same for agents. »

Transition to MCP (1 min, important): “We know how to do talk the agents to each other . There remains one problem: each agent must also speak to his tools — database, web search, GitHub, Slack. And there, historically, is chaos. Let's see why, and see the standard that puts an end to it. »

Sequence E — MCP: the universal standard (20 min) ⭐ heart of the second hour

Objective : Host ↔ Client ↔ Server architecture included and the 3 primitives distinguished.

1. The N×M problem (4 min). On the board: on the left, 3 models/applications (Claude, GPT, your internal app); on the right, 4 tools (database, web search, GitHub, Slack). Trace all the arrows: 3 × 4 = 12 integrations to code, maintain, secure — each with its format, its authentication, its bugs. Add a template: +4 integrations. Add a tool: +3. This is the N×M problem .

A telling historical reminder: before USB (Universal Serial Bus), each peripheral had its own socket — mouse port, printer port, keyboard port. USB imposed a socket, A protocol: any device on any computer. MCP (Model Context Protocol) is the USB of AI : proposed at the end of 2024 ⚠ by Anthropic, since adopted by the main players in the ecosystem ⚠. With MCP: N + M connectors instead of N × M.

2. The Host ↔ Client ↔ Server architecture (8 min). The trio to know by heart — project the diagram (slide 20) and open tab 2 of the page:

┌───────────────────────────────┐      ┌──────────────────────┐
│  HÔTE (host)                  │      │ SERVEUR MCP          │
│  = votre application          │      │ = fournit outils,    │
│  (Claude Desktop, IDE,        │      │   ressources, prompts│
│   votre app NewsRoom…)        │      │ (ex. serveur GitHub) │
│   ┌───────────────────┐       │      │                      │
│   │ CLIENT MCP        │◀─────▶│      │                      │
│   │ = connecteur dans │ 1 ↔ 1 │      │                      │
│   │   l'hôte          │       │      │                      │
│   └───────────────────┘       │      └──────────────────────┘
└───────────────────────────────┘

Complete analogy to give: the host is the computer , the customer is the USB port , the server is peripheral . Another wording that helps: the MCP server is a adapter placed in front of an existing service (GitHub, your database, etc.) which translates this service into the standard MCP language.

Trap No. 1 to defuse: “server” does NOT mean “large machine in a data center”. An MCP server is often a small local program of a few hundred lines, launched on your own computer. The word designates a role in the protocol (the one that provides), not an infrastructure.

Trap #2: the MCP server does not contain not of AI model. It exhibits capabilities; intelligence remains on the host side.

3. The two transports (2 min). How do client and server actually talk to each other?

4. The three primitives (6 min). What a server can expose — click the three cards in the page:

Primitive Who decides to use it? It's what Example (GitHub server)
Tools (tools) The model (model-invoked) Executable actions — standardized Session 5 tool calling créer_issue(titre, corps)
Resources (resources) The app (app-controlled) Read data that the host injects into the context the content of README.md
Prompts (prompts) The user (via host) Ready-to-use, configurable prompt templates “analyze this pull request”

The point that differentiates everything: who has the hand . Tools → the model decides to act (with the safeguards of Sessions 5–6). Resources → the application decides what to show to the model (like the RAG, Session 4: on give to read ). Prompts → the user chooses a prompt template from a menu. Three primitives, three different “triggers”.

Complete loop to unfold orally (with NewsRoom): the Searcher (in the host) wants to search → the host asks the client for the list of server tools “web search” → the model chooses recherche_web(requête) → the client forwards the call to the server → the server executes and returns the result → the result returns to the agent loop (the “observe” step of Session 6!). Nothing new in the loop — only the connection is standardized.

Sequence F — Ecosystem & build your server (10 min)

Objective : make MCP concrete and actionable tomorrow.

The existing ecosystem (4 min). MCP servers available off the shelf ⚠ (the ecosystem grows every week): file system (read/write local files), databases (PostgreSQL, SQLite…), web search , GitHub (issues, PR, code), Slack (read/post), browser, calendars… The reflex to install: Before coding an integration, find out if an MCP server already exists.

Build your own (5 min). When your business logic does not exist on the shelf (e.g.: your CRM - Customer Relationship Management, customer relationship management - internal), you write an MCP server which exposes it. Conceptual skeleton (no code to write in session, show the pseudo-code of slide 26):

serveur = nouveau ServeurMCP("crm-interne")

serveur.tool("chercher_client",
  description: "Recherche un client par nom ou e-mail",
  schéma: { requete: string },
  exécution: (args) => crm.chercher(args.requete))

serveur.resource("crm://clients/actifs",
  description: "Liste des clients actifs",
  lecture: () => crm.listeActifs())

serveur.démarrer(transport: stdio)

Three messages to hammer home:

  1. Each tool = exactly the tool definition from Session 5 (name, description, input schema) — you already know how to do .
  2. Write server once → all your hosts (Claude Desktop, your NewsRoom agents, the IDE) benefit from it. This is the N+M gain.
  3. Security does not change: least privilege, human validation for the irreversible — the standard does not exempt from any safeguards.

Complete the loop (1 min): “First hour: specialized agents who collaborate. Second hour: a universal socket for their tools. Complete NewsRoom is: 4 agents in a supervised pipeline, each connected to its MCP servers. You now have all the pieces of a professional multi-agent system. »

4. Frequently asked questions from participants (and answers)

“Multi-agent, is it several different models? » No — often the same model with different prompt systems, tools and safeguards. We can vary the models (economy: small model for simple tasks), but this is not the definition.

“Why not put everything in one big prompt?” » It works...to a point. Conflicting instructions, saturated context, impossible debugging, overexposed tools. Multi-agent is to a giant prompt what functions are to a 3,000-line script.

“Does MCP replace tool calling? » No, he standardize . Tool calling (Session 5) remains the mechanism; MCP standardizes how to discover and connect tools. Analogy: USB didn't replace keyboards — it standardized the socket.

“Is an MCP server a cloud service? » Not necessarily — it’s often even a small local process (stdio transport). “Server” refers to the role (capacity provider), not infrastructure.

“What is the difference between Resource and Read-only Tool?” » The trigger. A tool lire_fichier is invoked by the model when he deems it useful. A resource is injected by the application (or chosen by the user). Same data, different control — and control is the whole issue in production.

“The debate multiplies the costs by two or three – is it worth it? » Only for high-stakes decisions where the cost of an error far exceeds the cost of appeals. For a daily summary: no. To validate a regulatory analysis before sending it to a regulator: yes.

“Is MCP unique to Anthropic? » The protocol was initiated by Anthropic (end of 2024 ⚠) but published as standard open ; it is adopted beyond Anthropic ⚠. The point of a standard is precisely that it does not belong to anyone in practice.

5. Educational pitfalls to avoid

  1. Stack the 4 patterns without contrasting them. What remains in mind is the comparative table “which decides the flow”. Spend time there.
  2. Present MCP as another technology. It's a standard — the value is in the sharing (N+M), not in a functionality. Without the N×M problem first, MCP seems free.
  3. Let “server” conjure up a data center. Explicitly say: “an MCP server fits in a small local script”. Otherwise half the room imagines the cloud.
  4. Drown the room in the 3 primitives. The bottom line: Tools = the model decides, Resources = the app decides, Prompts = the user chooses. The rest is details.
  5. Sell ​​multi-agent everywhere. Symmetric of Session 6: an agent (or even a prompt) is often enough. A credible trainer says when NOT to multiply agents.
  6. Forget the bridge with Sessions 5–6. Each new feature must be hung up: tool MCP = S5 tool definition; tool result = “observe” S6. Participants should feel continuity, not a new world.

6. Exit tickets (5)

To be distributed in the last 5 minutes. One sentence response is enough.

  1. Why split a monolithic agent into several specialized agents? (one argument is enough) (Expected, one of: prompt systems without contradictions; tools limited to the needs of each person / least privilege; targeted safeguards; debugging by agent; controlled context.)

  2. Name the 4 multi-agent patterns seen today. (Expected: pipeline, orchestrator/performers, debate/consensus, supervisor.)

  3. What does MCP mean and what problem does it solve? (Expected: Model Context Protocol — a universal standard that avoids coding N×M integrations between models and tools: “the USB of AI”.)

  4. In MCP architecture, who are the Host, Client and Server? (Expected: Host = the application where the model lives; Client = the connector in the host, one per server; Server = the program that exposes tools/resources/prompts.)

  5. What is the difference between a Tool and an MCP Resource? (Expected: the Tool is invoked by the model (action); the Resource is controlled by the application (data injected for reading).)

7. Bridge to the sequel