Français

Slides — Session 7: Multi-agents & MCP

Program: Applied AI — Intermediate Level — Instructor: Yann Isola
Format: 29 slides. Each slide includes the projected content then the speaker notes.
Palette: #1A2230 ink, #0F7A6C teal, #B4612A copper, #E9F6F3 light teal, #F4F7F6 background.

Slide 1 — Title

Multi-agents & MCP

From lone agent to team — and the universal plug that plugs it all

Applied AI — Session 7 — Yann Isola

Slide 2 — Quick reminder: Session 6

  • An agent = a model in a loop: perceive → reflect → act → observe
  • The tools are his hands; he decides himself when the task is finished
  • Mandatory safeguards: max iterations, budget, human validation
  • Golden rule: if a prompt is enough, no agent

Slide 3 — Session Objectives

At the end of these 2 hours, you will know:

  1. Justify the division into specialized agents (separation of responsibilities)
  2. Recognize and choose from 4 patterns: pipeline, orchestrator, debate, supervisor
  3. List the 3 modes of communication between agents
  4. Explain MCP (Model Context Protocol): Host ↔ Client ↔ Server
  5. Distinguish the 3 primitives: Tools, Resources, Prompts

Slide 4 — The thought experiment: NewsRoom as ONE agent

Mission: “Every morning: summary of 500 words on stablecoins — sourced, verified, proofread, published.”

Monolithic version: one giant system prompt + all tools.

❓ What will go wrong?

Slide 5 — The 4 diseases of the monolithic agent

  1. 🧶 Prompt-monster: “be exhaustive” (research) vs “be concise” (editing) → contradictions
  2. 🔓 Over-exposed tools: the writing stage has access to the publication tool — unnecessary risk
  3. 🕵️ Indebuggable: poor summary… faulty research, writing or verification? Mystery
  4. 🌊 Drowned context: searches + drafts + proofreads in a single window

Slide 6 — The answer: separation of responsibilities

Each specialized agent has:| | |
|---|---|
| 🎯 System prompt sound | a unique mission, without contradictions |
| 🧰 His tools | only his own (least privilege) |
| 🚧 Its safeguards | targeted on its risks |

Analogy: the company. Accountant ≠ salesman ≠ lawyer. Everyone has their role, everyone has their keys.

Slide 7 — The NewsRoom team 📰

  • 🔍 Researcher — tools: web search, reading articles — “Find reliable sources, cite everything”
  • ✍️ Editor — no tools — “Write clearly, 500 words”
  • 🕵️ Checker — tool: web search — “Track errors, be ruthless”
  • 📣 Publisher — tool: publication (irreversible → human validation)

⚠️ Often the same model for all 4! Multi-agent ≠ multi-model.

Slide 8 — Pattern 1: the pipeline (the chain)

🔍 Researcher → ✍ Writer → 🕵 Fact-checker → 📣 Publisher
  • Each agent transforms the output of the previous one
  • linear flow, set in advance by the developer
  • ✅ Simple, predictable, debuggable (inspectable intermediate deliverables)
  • ❌ Rigid: what if the Verifier rejects?

Slide 9 — Pattern 2: orchestrator / performers

            ┌────────────────┐
            │ ORCHESTRATOR   │  decomposes · delegates · assembles
            └──┬─────┬────┬──┘
               ▼     ▼    ▼
           🔍       ✍      🕵
        (the workers do not talk to each other)
  • The decomposition is decided at execution, by an agent
  • ✅ Flexible, parallelizable
  • ❌ Bottleneck + single point of failure

Slide 10 — Pattern 3: debate / consensus

✍ Writer A ──┐
              ├──▶ ⚖ JUDGE ──▶ best version / synthesis
✍ Writer B ──┘
  • Independent answers → a judge decides (or a vote)
  • ✅ Cross-check reliability: two agents rarely hallucinate the same
  • ✅ Divergences = information (→ going back to humans)
  • ❌ Cost × number of debaters

Slide 11 — Boss 4: the supervisor

        ┌──────────────┐
        │ SUPERVISOR   │  observes · validates · interrupts · reassigns
        └──────┬───────┘
           surveille
   ┌───────────┼───────────┐
   ▼           ▼           ▼
 Agent 1     Agent 2     Agent 3

Orchestrator = distributes work · Supervisor = quality & safety control

Slide 12 — The 4 patterns in one table

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

Slide 13 — And the golden rule, team version

“If one agent is enough, don’t use four.”

Multi-agent costs: ×N calls, latency, coordination, points of failure.

We choose it for robustness and mastery — never for fashion.

Slide 14 — It’s your turn: the architecture visualizer

Webpage, tab 1 — 15 minutes in pairs

  1. Choose a boss (pipeline / orchestrator / debate)
  2. Drag NewsRoom Agents into Locations
  3. Start the message animation and read the log
  4. 💥Inject error” button: watch the rollback

❓ To compare: the number of messages exchanged in pipeline vs orchestrator

Slide 15 — ☕ Break (10 min)

At the restart: how the agents talk to each other — then the AI's USB port.

Slide 16 — Communication between agents: 3 mechanisms

Mechanism Business analogy ✅ ❌
Passing messages Internal emails Traceable, decoupled Define who speaks to whom
Shared memory The common network folder Simple, everyone sees everything Swelling context, interference
Blackboard (blackboard) The crisis room whiteboard Everyone contributes when they can More complex (triggers)

Slide 17 — New problem: connecting the tools

Your agents talk to each other ✅ … but everyone must also talk to their tools:

database · web search · GitHub · Slack · files · internal CRM…

And there, historically: chaos.

Slide 18 — The N × M problem

  3 applications          4 outils
  ┌──────────┐           ┌──────────────┐
  │ Claude   │──┬──┬──┬──│ Database      │
  │ GPT      │──┼──┼──┼──│  data         │
  │ Your app │──┼──┼──┼──│ Web search    │
  └──────────┘  └──┴──┴──│ GitHub        │
                         │ Slack         │
                         └──────────────┘
      3 × 4 = 12 custom integrations 😱

+1 application → +4 integrations · +1 tool → +3 integrations

Slide 19 — The solution already exists: USB

Before USB (Universal Serial Bus): mouse port, printer port, keyboard port — one socket per device.

After: ONE socket, ONE protocol → any device on any computer.

MCP = Model Context Protocol = the USB of AI

Proposed at the end of 2024 ⚠ by Anthropic · standard open · widely adopted in the ecosystem ⚠

N × M integrations → N + M connectors

Slide 20 — MCP architecture: the Host · Client · Server trio

┌───────────────────────────────┐        ┌────────────────────────┐
│  HOST  = your application     │        │  MCP SERVER            │
│  (Claude Desktop, IDE,        │        │  = exposes capabilities│
│   votre app NewsRoom…)        │        │  · Tools               │
│   ┌───────────────────┐       │        │  · Resources           │
│   │  CLIENT MCP       │◀──────┼───────▶│  · Prompts             │
│   │  1 client ↔ 1 server      │        │  (e.g. GitHub server)  │
│   └───────────────────┘       │        └────────────────────────┘
└───────────────────────────────┘

Host = the computer · Client = the USB port · Server = the device

Slide 21 — Two pitfalls on the word “server”

  1. ❌ “Server = large machine in a data center”
    ✅ Often a small local program of a few hundred lines, launched on your computer. “Server” = a role (the one that provides), not an infrastructure.

  2. ❌ “MCP server contains AI”
    ✅ Server exposes capabilities. Intelligence remains on the host side.

Slide 22 — The two transports

Transportation Or ? How ? Typical case
stdio (standard input/output) Local Host-initiated process, dialog via I/O Filesystem server on your workstation
HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events) Remote Network ; the server can push events Shared Enterprise MCP Server

Mnemo: stdio = local · HTTP = remote ⚠ (remote transport is evolving — remember the idea)

Speaker's notes: Do not drag on: the mnemonic rule is sufficient at this level. The ⚠: the remote transport specification has variants ("streamable HTTP") — the stdio/local vs HTTP/remote idea remains stable.

Slide 23 — The 3 primitives: who has the hand?

Primitive Who decides? What Example (GitHub server)
Tools 🔧 The model Executable actions (= tool calling S5, standardized) create_issue(title, body)
Resources 📚 The application Read data injected into context content of README.md
Prompts 📋 The user Ready-to-use prompt templates “analyze this pull request”

Slide 24 — The full circle, with MCP

  1. The Seeker (host) needs to search
  2. Host → client: “list of web search server tools?”
  3. The model chooses web_search(query)
  4. Client → server: executes the call
  5. The server returns the result
  6. The result enters the loop: this is the “observe” step of Session 6!

Nothing new in the loop — only the connection is standardized.

Slide 25 — The ecosystem: help yourself ⚠

MCP servers available off the shelf (list growing every week ⚠):

📁 filesystem · 🗄️ databases (PostgreSQL, SQLite…) · 🔍 web search
🐙 GitHub · 💬 Slack · 🌐 browser · 📅 calendars…

Reflex: before coding an integration, find out if the MCP server already exists.

Slide 26 — Build YOUR MCP server (pseudo-code)

server = new MCPServer("crm-internal")

server.tool("search_client",
  description: "Search for a client by name or e-mail",
  schema: { query: string },
  execution: (args) => crm.search(args.query))

server.resource("crm://clients/active",
  description: "List of active clients",
  read: () => crm.listActive())

server.start(transport: stdio)

Slide 27 — NewsRoom, final version 🏗️

              ┌─ SUPERVISOR (compliance) ──┐
              ▼             ▼              ▼
 🔍 Researcher → ✍ Writer → 🕵 Fact-checker → 📣 Publisher
     │                             │                │
  [MCP: web search]         [MCP: search]     [MCP: Slack]
                                                + human validation ✋

4 specialized agents · supervised pipeline · tools connected in MCP · human safeguard before publication

Slide 28 — What to remember

  1. Multi-agent = separation of responsibilities: each one has its own prompt, its own tools, its own safeguards
  2. 4 patterns: pipeline (fixed) · orchestrator (dynamic) · debate (overlapping) · supervisor (control)
  3. 3 communications: messages · shared memory · blackboard
  4. MCP = the AI USB: Host ↔ Client ↔ Server, N+M instead of N×M
  5. 3 primitives: Tools (the model) · Resources (the app) · Prompts (the user)
  6. If one agent is enough, don't use four.

Slide 29 — Next week

Session 8

You know how to build. Do we know if it really works?

Evaluation · observability · production

Challenge of the week: identify a task in your profession that deserves a team of agents. Which boss? Which MCP servers? We open the session with your cases.

Speaker notes: Welcome. Teasing: “Session 5: we gave the model hands. Session 6: we put it in a loop. Today, two leaps: we go from the employee to the company, and we invent the USB port for AI.” Announce the two halves of the session: multi-agent (1st hour), MCP (2nd hour).

Speaker notes: 2 minutes max. Have a participant recite the loop. The golden rule from line 4 will return in a multi-agent version: “if one agent is enough, no team”.

Speaker notes: Clear contract. Reassure: “No code to write today — but at the end, you will be able to draw the complete architecture of a professional multi-agent system, MCP included.”

Speaker notes: Common theme of the session: NewsRoom 📰. Let the room listen for 2 minutes before showing the next slide. Write their answers on the board — most of the 4 problems will emerge on their own.

Speaker Notes: Relate each point to past sessions: point 2 = violation of least privilege (S5); point 4 = working memory (S6) which overflows. Punchline: “It works…until the day it doesn’t work anymore, and when that day comes, you won’t know why.”

Speaker notes: THE conceptual slide of the 1st hour. The business analogy will carry the entire session: “you don't hire ONE person to do everything — not because it's impossible, because it's fragile.” The accountant has the key to the safe, not the intern.

Speaker notes: Trap No. 1 of the session to be defused immediately: the 4 agents can work on the same Claude/GPT. What's different: prompt, tools, safeguards. Agency was a property of the system (S6); specialization too. Note that the Editor has NO tools: an agent can be “naked”.

Speaker Notes: “The assembly line.” Use cases: document processing, content generation, intelligent ETL (Extract-Transform-Load). Ask the question of rejection: we need to go back to the Editor — and already the pure pipeline is cracking. Transition: “what if the steps were not known in advance?”

Speaker notes: “The project manager.” THE distinction with the pipeline (quiz question!): pipeline = path set by the developer; orchestrator = path decided by the model at runtime. Use case: “complete file on company X” — the breakdown depends on the case. Insist: everything goes through the boss, so if he breaks it down badly, everything fails.

Speaker notes: Use case for this audience: validation of a regulatory analysis before sending to the regulator. Convergences give confidence, divergences trigger human review — it is an uncertainty detector. To be reserved for decisions that merit the additional cost: “not for the morning summary, yes for the advice to the regulator”.

Speaker notes: The orchestrator/supervisor confusion is THE pitfall of the quiz. Formula to repeat: “the project manager vs quality control + compliance manager”. The two are often combined — especially in finance, health, legal. The supervisor detects: infinite loops, off-topic, rule violations.

Speaker notes: Slide to photograph. The column “who decides the flow?” is the reading key. Specify that the bosses COMBINE: pipeline + supervisor, orchestrator + debate on a critical step, etc. These are bricks, not exclusive squares.

Speaker notes: Exact symmetry of the rule of Session 6 (“if a prompt is enough, no agent”). A credible trainer says when NOT to use their tech. Example: “rephrase this email” → a prompt. Point. Transition: “Let’s move on to manipulation.”

Speaker notes: Sequence C of the guide. Circulate around the room. Debrief question: “Who decides the path in each pattern?” The correct verbalization: pipeline = fixed in advance, orchestrator = decided by an agent. If not enough laptops: you control the video projector, the guide room.

Speaker notes: Launch the teaser before the break: “Question to ponder over coffee: your 4 agents must share their results. Like in a business, there is email, the network folder, and the meeting whiteboard. Guess: it's the same for agents.”

Speaker Notes: The business analogy does all the work.The blackboard: STRUCTURED common space (sections, statuses) where an agent “wakes up” when information that concerns them appears — NewsRoom: the Checker is triggered as soon as a draft is posted. Messages = natural mechanism of the pipeline and orchestrator.

Speaker notes: Pivotal of the session — take care of the transition. “First hour: the agents among themselves. But the Researcher has to talk to web search, the Publisher to Slack… Each connection was custom code. Let's see the extent of the problem.”

Speaker Notes: Draw the 12 arrows on the board if possible — the visual effect of the spaghetti dish is worth a thousand words. Each arrow = code, authentication, maintenance, bugs, redone each time. Question to the room: “Does this remind you of a problem that has already been solved in IT?” → next slide.

Speaker Notes: The official analogy — and it is apt. Explain the acronym (course rule): Model Context Protocol. Emphasize “open standard”: initiated by Anthropic but not owned by anyone in practice — this is the condition for a standard to work. ⚠: dates and adoption change quickly, check before each session.

Speaker notes: THE slide to know by heart — this is question 8 of the quiz. Expand: the host hosts the model and decides which servers to connect; the client manages ONE connection (3 servers = 3 clients in the host); the server exposes the capabilities. Open tab 2 of the parallel page: the diagram is clickable there.

Speaker notes: Defuse head-on: half the room imagines the cloud as soon as they hear “server”. Useful reformulation: “an MCP server is an ADAPTER placed in front of an existing service, which translates it into standard MCP language”.

Speaker notes: THE column that counts: “who decides”. Tool → the model acts (with guardrails S5–S6). Resource → the app chooses what to show (RAG spirit, S4). Prompt → the user draws from a menu. Trick question to ask: “a tool `lire_fichier` and a resource file, what’s the difference?” → the trigger. Same data, different control — and in production, control is the whole point.

Speaker notes: The slide that ties it all together. Insist on continuity: MCP does not replace tool calling, it STANDARDIZES it (analogy: USB has not replaced keyboards, it has standardized the socket).Participants should walk away feeling like they already knew 80% of MCP without knowing it.

Speaker notes: Message of pure economy: weeks of development avoided. ⚠ on the entire list: the ecosystem moves quickly, possibly show an up-to-date directory if you have a network (otherwise, the page contains a static catalog). Transition: “and when your business logic doesn’t exist on the shelf?”

Speaker Notes: Three messages: (1) each `tool` = exactly the S5 tool definition — name, description, diagram: “you already know how to do it”; (2) written ONCE → all your hosts benefit (the N+M gain); (3) security does not change — least privilege, human validation for the irreversible. No one should copy the code: it is conceptual pseudo-code.

Speaker Notes: The final photo that brings the ENTIRE session (and sessions 5–6) together. Have a participant comment on it: boss? communication ? MCP primitives used? guardrails? If he can explain everything, the session is won. “You now have all the pieces of a professional multi-agent system.”

Speaker notes: Quick reading, then express oral quiz (5 questions from the quiz file) and distribution of exit tickets. Point 6 last, voluntarily: it is the discernment which distinguishes a professional from a follower of fashion.

Speaker Notes: The weekly challenge creates continuity and provides real cases for the next opening session. Say thanks, stay 5 minutes for individual questions — that's often where the real business use cases come out.